ABCDEFGHIJKLMNOPQRSTUVWXYZAA
1
#RequirementSCVS LevelQuestion / Tooling Assumptionsbomqs supportNotesTracking Issue
2
2.1A structured, machine readable software bill of materials (SBOM) format is presentL1Assumption: Limiting to CycloneDX and SPDX formatsY
3
2.2SBOM creation is automated and reproducibleL2Assumption: Some params to the tool can provide information about automation.
Question: Does reporoducibility mean idempotency?
Revised Assumption: A description of Tool/Version is an indication of automated process (cannot be independently verified)		N
4
2.3Each SBOM has a unique identifier L1Assumption: check for unique ID across SBOMs if all SBOMs are providedY
5
2.4SBOM has been signed by publisher, supplier, or certifying authorityL2Assumption: Tool can check for the existence of signatures in the SBOM
Question: Does the signatures need to be part of the SBOM or can be provided separately? Supported formats?		Y
6
2.5SBOM signature verification existsL2Assumption: Tool is responsible for signature verificationN
7
2.6SBOM signature verification is performed L3Assumpiton: Tool is verifying the signature using the key provided in 2.5Nsbom-sig
8
2.7SBOM is timestampedL1Assumption: Creation TimestampY
9
2.8SBOM is analyzed for riskL1Question: Does this refer to organizational practice of risk assessment or inclusion of vulnerability / licenses in the SBOM itself?N
10
2.9SBOM contains a complete and accurate inventory of all components the SBOM describesL1Assumption: Check for the content of SBOM to be a complete set of dependencies.N
11
2.10SBOM contains an accurate inventory of all test components for the asset or application it describesL2Question: How can an SBOM indicate test vs non-test component??
12
2.11SBOM contains metadata about the asset or software the SBOM describesL2Question: Is there a list of metadata that will provide sufficiency? NTIA minimum elements?Y
13
2.12Component identifiers are derived from their native ecosystems (if applicable)L1How is this different from 2.13??Checks for bom-ref / SPDXID to be mapped to PURL/CPE
14
2.13Component point of origin is identified in a consistent, machine readable format (e.g. PURL)L3Existing of CPE / PURL for all components is sufficient?YChecks for component to include a PURL scheme
15
2.14Components defined in SBOM have accurate license informationL1Question: How can verification be implemented for commercial licenses not found in SPDX License list?Y
16
2.15Components defined in SBOM have valid SPDX license ID's or expressions (if applicable)L2-Y
17
2.16Components defined in SBOM have valid copyright statementsL3Assumption: CycloneDX: copyright, SPDX: PackageCopyrightTextYCheck for existencehttps://github.com/interlynk-io/sbomqs/issues/93
18
2.17Components defined in SBOM which have been modified from the original have detailed provenance and pedigree informationL3Question: Is it reasonable to assume that SBOM alone cannot confirm this requirement? For instance, the component might be modified by SBOM has no record of pedigree and therefore has no awareness of its own inaccuracy.N
19
2.18Components defined in SBOM have one or more file hashes (SHA-256, SHA-512, etc)L3-Y
20
21
22
23
sbomqs --filepath <File>
24
SBOM V2 Checkup // L1: (3/7 completed), L2 (1/4 completed), L3 (0/4 completed)
25
L1 : Requirement :
26
SCVSSCVS V2: SBOM
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100