Skip to content
Merged
Show file tree
Hide file tree
Changes from 16 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 41 additions & 26 deletions baseline/OSPS-QA.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -62,38 +62,28 @@ 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 MUST 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
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 file that ennumerates all
direct dependencies such as package.json,
Gemfile, or go.mod.
control_mappings:
BPB: Q-S-9
CRA: 1.2b, 2.1
SSDF: PO4, PS1
BPB: Q-S-8, Q-S-9
CRA: 2.1, 2.3
SSDF: PO3.3, PS1, PS3.2
CSF: ID.AM-02
OC: 4.3.1
OCRE: 486-813, 124-564, 863-521
OC: 4.1.5, 4.3.1
OCRE: 486-813, 124-564, 673-475,863-521, 613-286
security_insights_value: # TODO

- id: OSPS-QA-04
Expand Down Expand Up @@ -237,3 +227,28 @@ criteria:
control_mappings:
BPB: B-G-3
security_insights_value: # TODO

- id: OSPS-QA-11
maturity_level: 3
criterion: |
All released built software assets MUST be
delivered with a software bill of materials.
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 auto-generate SBOMs at build time
using 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-8, A-S-1
CRA: 2.1
SSDF: PS3.2, PW4
CSF: ID.AM-01, ID.AM-02
OC: 4.3.1
OCRE: 486-813, 124-564, 863-521, 613-286
security_insights_value: # TODO
16 changes: 12 additions & 4 deletions baseline/lexicon.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -266,10 +266,18 @@
- https://csrc.nist.gov/pubs/sp/800/218/final
- term: Software Bill of Materials
definition: |
A manifest or list of all components that make up a given piece of software or hardware, preferably in a machine-readable/macine-parseable format.
synonyms:
- SBOM
references:
A list of all components that make up a given piece of software
or hardware, formatted as CycloneDX or SPDX. This list must include
the following data elements for the components included in the released
software asset: license, supplier name, filename of the component,
component name, component version, software identifiers, relationship
between the components, author of the SBOM data and timestamp. Additionally,
for deployable and executable components, the SBOM should record their
cryptographic hashes.
synonyms:
- SBOM
- SBOMs
references:
- https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf
- https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf
- https://spdx.dev
Expand Down