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:

• 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 ?

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 ?

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:

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 ?