Align rules with OWASP SCVS initiative

[surendrapathak]

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.

[surendrapathak]

Duplicates #93

[viveksahu26]

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:

• V1: Inventory
• V2: Software Bill of Materials (SBOM)
• V3: Build Environment
• V4: Package Management
• V5: Component Analysis
• V6: Pedigree and Provenance

Whereas L1, L2, L3 means:

• Level 1: Basic practices for low-assurance needs.
• Level 2: Enhanced practices for moderate assurance, involving more stakeholders.
• 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 ?

[viveksahu26]

Few question :

• Or we need to only check for V2: Software Bill of Materials (SBOM) level ?
• to implement in score command with a new category SVCS SBOM with other 5 categories i.e. ntia, quality, structural, semantic and sharing ?

[viveksahu26]

V2: Software Bill of Materials (SBOM) Requirements

Control Objective:

Create accurate, machine-readable SBOMs automatically in the build pipeline. Multiple formats might be necessary to meet different requirements.

Key Controls:

#	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)			✓

[viveksahu26]

I wanted to discuss few things related to features of scvs:

• 2.2: SBOM creation is automated and reproducible
  • In this case, If tool with version is provided will be enough to validate this above feature ? Or along with that we need to check from a list of pre-define tools which creates SBOM via automation such as anchor, fossa, trivy, etc
• 2.4: SBOM has been signed by publisher, supplier, or certifying authority
  • In this case, we need to check whether provided SBOM has field signature containing digital signatures. The SBOM format CycloneDX has such field but SPDX doesn't have ?
• 2.5 : SBOM signature verification exists
  • In this we need to check whether public key of signature is provided or not ?
• 2.6: SBOM signature verification is performed
  • In this case, we need to verify the signature using public key. And to verify it will need to use cosign tool for that ?
• 2.9: SBOM contains a complete and accurate inventory of all components the SBOM describes
  • In this case, do we need to check some important fields of components which is provided or not ? Such as "PackageName", "PackageVersion", "PackageDownloadLocation", "PackageSupplier", "ExternalRef", etc. or follow NTIA-minimum elements for components such as: "Component Name", "Supplier Name", "Version of Component", and "Other Uniq IDs" ?
• 2.11: SBOM contains metadata about the asset or software the SBOM describes
  • In this case we need to check whether NTIA-minimum elements is fulfilled or not ?
• 2.12: Component identifiers are derived from their native ecosystems (if applicable)
  • In thsi case, do we need to check whether "PackageName" or "bom-ref", and "External Reference" is provided or not ?
• 2.15: Components defined in SBOM have valid SPDX license ID's or expressions (if applicable)
  • In this case, how to validate licenses ? Is there some centralized license list, from which to chec whether provided license is present in that centralized license db or not ? Something like that ?
• 2.17: Components defined in SBOM which have been modified from the original have detailed provenance and pedigree information
  • For this case, we can first check whether calculated hash value of SBOM matches with provided hash of SBOM. If yes, then fine, otherwise we need to check the modifies components proof. For that CycloneDX has "Pedigree" fields wheread SPDX doesn't has such fields ?

[viveksahu26]

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 )