Repository navigation
[Improvement] Adding Security and/or Risk staff to supply-chain-education-leaflet-version-2-2024 #77
Description
Add Security and/or Risk stuff to "Let’s learn the basics of open source" section
Security personnel need to know the specificities of OSS security, e.g. known vulnerabilities, CVSS, is the vulnerability exploitable in the current setup, etc.
Risk personnel on the other hand need to know for example how deprecated or unsupported components increase the risks and what kind of mitigation strategies there are. Another risk factor could be a small number of contributors, the OSS project not having good security practices, etc.
Security and/or Risk personnel roles to be added to Different roles in a company have different responsibilities for open source compliance section too.
Activity
myagi2019 commentedon Sep 16, 2026
This has moved to https://github.com/OpenChain-Project/Reference-Material/tree/master/OpenChain-Supplier-Education/en/Supplier-Education-Leaflet-ISO-IEC-5230-(OpenChain%202.1)
Same comments as in #74
winterrocks commentedon Oct 20, 2026
Under
https://github.com/OpenChain-Project/Reference-Material/blob/master/OpenChain-Supplier-Education/en/Supplier-Education-Leaflet-ISO-IEC-5230-(OpenChain%202.1)/supply-chain-education-leaflet-version-2_en.md#different-roles-in-a-company-have-different-responsibilities-for-open-source-compliance
to add Security and/or Risk personnel chapter(s)
Security personnel
Security personnel should be aware of the specific characteristics of Open Source security issues, such as:
They should also have a policy for the organization, e.g. which level vulnerabilities are acceptable and what kind of mitigation/remediation must happen at what stages. There must also be policies and processes in place how to communicate new vulnerabilities to downstream customers.
Risk personnel
A short chapter that explains the main risks that Open Source projects can cause. It could be worth mentioning that an organization should have a policy about Open Source project risks, e.g. components/packages from projects that are deprecated or abandoned may not be used or there must be in-house developers that are able to mitigate any new vulnerabilities, components from projects that have no activities in past X years, needs to be replaced, etc.