The OpenChain Project released a Security Assurance Reference Guide in August 2021. Feedback from the community expanded this into its current form: a Security Assurance Reference Specification (Release Candidate 1 2022-03-28). At the end of June 2022 the OpenChain Steering Committee will decide if this Release Candidate:
- Becomes a sister standard to OpenChain ISO/IEC 5230
- Becomes an optional component of OpenChain ISO/IEC 5230
- Remains a reference specification
This is an important moment for the OpenChain Project, explicitly highlighting our work beyond open source license compliance. Your input is most welcome to help inform our steering committee.
Please open Issues on our GitHub here to provide feedback:
Alternatively, or in addition, please join our specification mailing list here:
More Information From The Introduction Of The Reference Specification Document:
The OpenChain Project is working towards a supply chain where open source is delivered with trusted and consistent compliance information. We maintain OpenChain ISO/IEC 5230:2020, the International Standard for open source license compliance. Adjacent to this the project maintains a large international community, extensive reference materials, and working groups addressing various domain issues. We support discussions around security, export control, M&A and other topics.
OpenChain ISO/IEC 5230:2020 is a process management specification that identifies inbound, internal and outbound inflection points where a process, policy or training should exist. The identification and tracking of software used and deployed is an inherent part of getting this right, and this also allows our standard to also be useful for security or export control.
The OpenChain Project community noticed that OpenChain ISO/IEC 5230:2020 was being used quite often in deployment discussions and we wanted to support our broader community around these use-cases. The reference specification you are now reading is focused on the security domain. It is intended to identify and describe the key requirements of a quality Security Assurance Program in the context of using Open Source Software. This early iteration of the document focuses on a narrow subset of primary concern: checking Open Source Software against publicly known security vulnerabilities like CVEs, GitHub/GitLab vulnerability reports, and so on.
This document focused on the “what” and “why” aspects of a quality Security Assurance Program rather than delving into to “how” and “when.” This is a conscious decision to ensure flexibility for companies of any size and in any market to use this reference specification. This approach, along with the types of processes identified, is built on more than half a decade of practical global feedback around the creation and management of such programs. The result is that a company can frame a program that precisely fits their supply chain requirements, scoped to a single product or a complete legal entity, and take this solution to market quickly and effectively.
The scope of this reference specification may expand over time based on community feedback.
This introduction describes the reference specification’s purpose. Section 2 defines key terms used throughout this document. Section 3 defines the requirements that a Program must satisfy to achieve a core level of Security Assurance. Each requirement consists of one or more verification materials (i.e., records) that must be produced to satisfy the requirement. Verification materials are not required to be made public, though an organization may choose to provide them to others, potentially under a Non-Disclosure Agreement (NDA).
This reference specification is licensed under Creative Commons Attribution License 4.0 (CC-BY-4.0). Because it takes the form of a Reference Specification and is therefore intended to fit into the mental model applied to specification creation, it is not designed to be modified outside of the formal editing track. You can take part in editing this document via the OpenChain Project bi-weekly calls. You can learn about joining these calls and our other activities here:
