Aspect
Section: 3.5 Conformance & validation
Orientation relevance: both
A profile can be used in two directions. Read one way, it is a recipe: it tells a tool to produce a report (a CBOM) containing exactly the attributes the profile asks for. Read the other way, it is a checklist: it lets you verify that a report someone has already given you contains them. This issue focuses on that checking side what counts as "passing" a profile, and whether we publish profiles in a computer-readable form so software can do the check automatically. One useful consequence of everyone drawing on the same shared set of attributes: a single report can be built to satisfy several profiles at once, rather than a separate report being produced for each.
Example
Like a spell-checker that flags a missing required field on a form, a "validator" could take a vendor's cryptography report together with a profile and report back: "this meets the procurement profile," or "the key-length field is missing." And because one report can carry everything that several profiles ask for, the same file might pass the procurement profile and the vulnerability-response profile at the same time no need to generate a different report for each.
The same check can also run inside development, as a quality gate. Much as automated tests and spell-check run on every commit, a team can check its CBOM against a profile at each build — so a missing or malformed field shows up the day it is introduced, rather than being discovered at release or by a customer.
Objective
Decide what it means for a CBOM to conform to a profile, and whether the methodology defines a
machine-readable profile artifact that a validator can consume.
Background & links
Scoping document §3.5. This is the aspect that turns a profile from documentation into
something tooling and contracts can rely on. Depends on the obligation semantics in 3.4 and the
model in 3.3; informs tooling guidance in 3.13.
Options under consideration
- Machine-readable profile definition — a formal encoding (e.g. JSON Schema or an
equivalent constraint language) that validators consume, distinct from the human-readable
profile text. (Trade-off: enables automation; more to specify and maintain.)
- Human-readable profile only — conformance checked by convention or review.
(Trade-off: lower effort; weak automation story.)
- Conformance levels — e.g. core / full, versus a single pass/fail bar.
Open questions
Dependencies
Depends on attribute model (3.3 #1) and obligations (3.4 #6). Feeds tooling
(3.13 #13). Decide the machine-readable-artifact question early — it shapes the whole
effort.
Decision
Not yet decided.
Impact on the specification
Spec section "Conformance and validation."
Aspect
Section: 3.5 Conformance & validation
Orientation relevance: both
A profile can be used in two directions. Read one way, it is a recipe: it tells a tool to produce a report (a CBOM) containing exactly the attributes the profile asks for. Read the other way, it is a checklist: it lets you verify that a report someone has already given you contains them. This issue focuses on that checking side what counts as "passing" a profile, and whether we publish profiles in a computer-readable form so software can do the check automatically. One useful consequence of everyone drawing on the same shared set of attributes: a single report can be built to satisfy several profiles at once, rather than a separate report being produced for each.
Example
Like a spell-checker that flags a missing required field on a form, a "validator" could take a vendor's cryptography report together with a profile and report back: "this meets the procurement profile," or "the key-length field is missing." And because one report can carry everything that several profiles ask for, the same file might pass the procurement profile and the vulnerability-response profile at the same time no need to generate a different report for each.
The same check can also run inside development, as a quality gate. Much as automated tests and spell-check run on every commit, a team can check its CBOM against a profile at each build — so a missing or malformed field shows up the day it is introduced, rather than being discovered at release or by a customer.
Objective
Decide what it means for a CBOM to conform to a profile, and whether the methodology defines a
machine-readable profile artifact that a validator can consume.
Background & links
Scoping document §3.5. This is the aspect that turns a profile from documentation into
something tooling and contracts can rely on. Depends on the obligation semantics in 3.4 and the
model in 3.3; informs tooling guidance in 3.13.
Options under consideration
equivalent constraint language) that validators consume, distinct from the human-readable
profile text. (Trade-off: enables automation; more to specify and maintain.)
(Trade-off: lower effort; weak automation story.)
Open questions
Dependencies
Depends on attribute model (3.3 #1) and obligations (3.4 #6). Feeds tooling
(3.13 #13). Decide the machine-readable-artifact question early — it shapes the whole
effort.
Decision
Not yet decided.
Impact on the specification
Spec section "Conformance and validation."