Skip to content

Commit

Permalink
Add dependency/SBOM critaria and leveling
Browse files Browse the repository at this point in the history
This commit updates the dependency criteria to add
increasing transparency requirements at each level.

Signed-off-by: Adolfo García Veytia (Puerco) <[email protected]>
  • Loading branch information
puerco committed Jan 24, 2025
1 parent 6adf8bb commit 9fa7fcc
Showing 1 changed file with 68 additions and 21 deletions.
89 changes: 68 additions & 21 deletions baseline/OSPS-QA.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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

0 comments on commit 9fa7fcc

Please sign in to comment.