diff --git a/baseline/OSPS-QA.yaml b/baseline/OSPS-QA.yaml index 953dc4c..65e7a42 100644 --- a/baseline/OSPS-QA.yaml +++ b/baseline/OSPS-QA.yaml @@ -62,31 +62,21 @@ criteria: security_insights_value: # TODO - id: OSPS-QA-03 - maturity_level: 2 + maturity_level: 1 criterion: | - All released software assets MUST be - delivered with a machine-readable list of - all direct and transitive internal software - dependencies with their associated version - identifiers. + The code repository should contain a dependency + list that accounts for the direct language dependencies + when the package management system supports it. rationale: | Provide transparency and accountability for - the project's dependencies, enabling users - and contributors to understand the - software's dependencies and versions. + the project's dependencies by fixing the desired versions + while enabling users and contributors to understand the + software's direct dependencies. details: | - This may take the form of a software bill of - materials (SBOM) or a dependency file that - lists all direct and transitive dependencies - such as package.json, Gemfile.lock, or - go.sum. - - It is recommended to use a CycloneDX or SPDX - file that is auto-generated at build time by - a tool that has been vetted for accuracy. - This enables users to ingest this data in a - standardized approach alongside other - projects in their environment. + This may take the form a package manager or + language dependency lock file that ennumerates all + direct and transitive dependencies such as + package.json, Gemfile.lock, or go.sum. control_mappings: BPB: Q-S-9 CRA: 1.2b, 2.1 @@ -237,3 +227,60 @@ criteria: control_mappings: BPB: B-G-3 security_insights_value: # TODO + + - id: OSPS-QA-11 + maturity_level: 2 + criterion: | + All released software assets MUST be + delivered with a software bill of materials + (SBOM) in SPDX or CycloneDX format accounting + all direct software dependencies with their + associated version identifiers. + rationale: | + Provide transparency and accountability for + the project's dependencies in a standard format + allowing automated systems to understand the + software's dependencies and versions. + details: | + It is recommended to use a CycloneDX or SPDX + file that is auto-generated at build time by + a tool that has been vetted for accuracy. + This enables users to ingest this data in a + standardized approach alongside other + projects in their environment. + control_mappings: + BPB: Q-S-9 + CRA: 13.24, I.II.1, VII.2 + SSDF: PS3, PW4 + CSF: ID.AM-02 + OC: 4.3.1 + OCRE: 486-813, 124-564, 863-521 + security_insights_value: # TODO + + - id: OSPS-QA-12 + maturity_level: 3 + criterion: | + The software bill of materials describing the release assets + should provide the following data elements for the components + used in the build: license, supplier name, filename of the component, + component name, component version, software identifiers, + relationship between the components, author of the + SBOM data and timestamp. + + Assitionally, for deployable and executable components + the SBOM should record their cryptgraphic hashes. + rationale: | + Provide the minimal data elements required to validate, + verify the integrity of software components and assess risk. + details: | + SBOM generation tools can specialize on one kind of data element. + Supplying the required data in multiple software bills of materials + can be done although ideally should be combined into one. + control_mappings: + BPB: Q-S-9 + CRA: 13.24, I.II.1, II.2 + SSDF: PS3, PW4 + CSF: ID.AM-02 + OC: 4.3.1 + OCRE: 486-813, 124-564, 863-521 + security_insights_value: # TODO