Open surendrapathak opened 1 year ago
Duplicates #93
Hey @surendrapathak , I went through official docs of SCVS. Just to give an overview it, Software Component Verification Standard is a group of controls and separated by control family. It has 6 control families and each control families has sub-control families with 3 levels: The control families are:
Whereas L1, L2, L3 means:
Level 3: Comprehensive practices for high-assurance, critical infrastructure, requiring auditability and transparency.
So, basically we need to check whether these different control families of SCVS i.e. from V1 to V6 adhere to SBOM or not using sbomqs
tool. Along with families, we need to check what level(L1, L2, L3) they are compliant with ?
Few question :
SVCS SBOM
with other 5 categories i.e. ntia
, quality
, structural
, semantic
and sharing
?Create accurate, machine-readable SBOMs automatically in the build pipeline. Multiple formats might be necessary to meet different requirements.
# | Description | L1 | L2 | L3 |
---|---|---|---|---|
2.1 | Structured, machine-readable SBOM format | ✓ | ✓ | ✓ |
2.2 | Automated and reproducible SBOM creation | ✓ | ✓ | |
2.3 | Unique identifier for each SBOM | ✓ | ✓ | ✓ |
2.4 | SBOM signed by publisher, supplier, or certifying authority | ✓ | ✓ | |
2.5 | SBOM signature verification exists | ✓ | ✓ | |
2.6 | SBOM signature verification performed | ✓ | ||
2.7 | SBOM timestamped | ✓ | ✓ | ✓ |
2.8 | SBOM analyzed for risk | ✓ | ✓ | ✓ |
2.9 | Complete and accurate inventory of components | ✓ | ✓ | ✓ |
2.10 | Accurate inventory of test components | ✓ | ✓ | |
2.11 | Metadata about the asset or software described in SBOM | ✓ | ✓ | |
2.12 | Component identifiers derived from native ecosystems | ✓ | ✓ | ✓ |
2.13 | Component point of origin identified in a consistent, machine-readable format (e.g. PURL) | ✓ | ||
2.14 | Accurate license information for components | ✓ | ✓ | ✓ |
2.15 | Valid SPDX license ID's or expressions for components | ✓ | ✓ | |
2.16 | Valid copyright statements for components | ✓ | ||
2.17 | Detailed provenance and pedigree information for modified components | ✓ | ||
2.18 | One or more file hashes for components (SHA-256, SHA-512, etc) | ✓ |
I wanted to discuss few things related to features of scvs:
SBOM creation is automated and reproducible
anchor
, fossa
, trivy
, etcSBOM has been signed by publisher, supplier, or certifying authority
SBOM signature verification exists
SBOM signature verification is performed
SBOM contains a complete and accurate inventory of all components the SBOM describes
SBOM contains metadata about the asset or software the SBOM describes
Component identifiers are derived from their native ecosystems (if applicable)
Components defined in SBOM have valid SPDX license ID's or expressions (if applicable)
Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information
sbomqs | features | L1 | L2 | L3 | CycloneDX | SPDX |
---|---|---|---|---|---|---|
OCT(Human Readable Data Format) | Structured, machine-readable SBOM format | ✓ | ✓ | ✓ | SBOM file format | SBOM file format |
OCT(SBOM Creator field) | SBOM creation is automated and reproducible | ✓ | ✓ | metadata.tools | CreationInfo: with tool and version | |
CRA(other uniq identifiers) | Each SBOM has a unique identifier | ✓ | ✓ | ✓ | (component->cpe, component->purl, component->omniborId, component->swhid, component->swid ) | (package->externalRef) |
Not supported | SBOM signed by publisher, supplier, or certifying authority | ✓ | ✓ | |||
Not supported | SBOM signature verification exists | ✓ | ✓ | |||
Not supported | SBOM signature verification performed | ✓ | ||||
OCT/CRA(SBOM Created field) | SBOM is timestamped | ✓ | ✓ | ✓ | (metadata->timestamp ) | (CreationInfo->created) |
Not supported | SBOM is analyzed for risk | ✓ | ✓ | ✓ | ||
NTIA Compliance | SBOM contains a complete and accurate inventory of all components the SBOM describes | ✓ | ✓ | ✓ | components and dependencies | packages and relationships |
Not supported | SBOM contains an accurate inventory of all test components for the asset or application it describes | ✓ | ✓ | |||
NTIA Category | SBOM contains metadata about the asset or software the SBOM describes | ✓ | ✓ | SBOM Timestamp(metadata->timestamp ), SBOM Author Name((metadata->tools, metadata->authors), metadata->manufacturer)) , SBOM primary component(metadata->component) | SBOM Timestamp(CreationInfo->created), SBOM Author Name(CreationInfo->Creator ) , SBOM primary component(Relationship->SPDXRef-DOCUMENT) | |
? | Component identifiers are derived from their native ecosystems (if applicable) | ✓ | ✓ | ✓ | ||
CRA(other uniq identifiers) | Component point of origin is identified in a consistent, machine readable format (e.g. PURL) | ✓ | (component->purl) | (package->externalRef ) | ||
CRA/OCT | Components defined in SBOM have accurate license information | ✓ | ✓ | ✓ | (component->licenses ) | (Package->licenseConcluded, Package->licenseDeclared ) |
license | Components defined in SBOM have valid SPDX license ID's or expressions (if applicable) | ✓ | ✓ | |||
OCT | Components defined in SBOM have valid copyright statements | ✓ | (component->copyright ) | (Package->copyrightText) | ||
? | Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information | ✓ | ||||
OCT/CRA | Components defined in SBOM have one or more file hashes (SHA-256, SHA-512, etc) | ✓ | (component->hashes ) | (package->checksum ) |
OWASP SCVS is formalizing verification requirements for SBOMs. sbomqs rules to test SBOM against as well output should be aligned to meet the proposed checks in SCVS.