Policy evaluation
A CBOM records facts. A judgement about those facts (for example, whether an interface is post-quantum-safe) is a separate matter. Such judgements should be produced by an external policy applied to the facts at evaluation time, rather than stored as attributes within the CBOM, because the criteria on which they depend change over time.
Facts versus evaluations
A CBOM states facts: the protocols, versions, algorithms, key material, and certificate signature algorithms an interface uses. These are primary data, observed or declared by the producer.
An evaluation is a judgement derived from those facts against a set of criteria. "Is this interface post-quantum-safe?" is not a fact recorded by the producer; it is a conclusion drawn from the algorithms the interface uses, assessed against current guidance. The conclusion depends on criteria that are external to the facts and that are revised as guidance develops.
Why the evaluation must be external to the data
If a derived value such as post-quantum posture is stored as an attribute within the CBOM, three problems follow:
- The value becomes stale. When the criteria change (for example, when an algorithm is reclassified), the stored value no longer reflects current guidance, yet the CBOM presents it as though it did.
- Producers evaluate inconsistently. Different producers, applying different or outdated criteria, record different verdicts for equivalent facts, which prevents comparison.
- The record and the judgement are conflated. A CBOM is intended to be a durable record of facts. Embedding a time-dependent judgement in it undermines that role.
Keeping the evaluation external avoids these problems. The CBOM remains a stable record of facts; a single, versioned policy evaluates all CBOMs consistently; and the same immutable facts can be re-evaluated at any time under the criteria then in force.
Examples of evaluations
| Evaluation | Derived from (facts) | Against (criteria, external) |
|---|---|---|
| Post-quantum posture | the key-exchange and authentication algorithms an interface uses, and whether they are classical, hybrid, or post-quantum | current guidance on which algorithms and combinations are considered quantum-safe, which is revised over time |
| Cryptographic maturity | algorithm strength, key sizes, deprecation status, library currency, and cryptographic agility | a maturity rubric that is revised as recommendations and deprecations change |
Both evaluations draw on the same kind of primary data and are subject to the same consideration: the criteria are not fixed, so the evaluation must be applied externally and dated, rather than frozen into the CBOM.
Vulnerability status is a third case and the one where the pressure to store a verdict is strongest, because the format offers a place to put it. It differs from the two above in that the criteria are not merely revisable but held by someone else entirely: whether an interface is affected depends on an advisory a third party publishes. The reasoning is the same and the consequences are developed in Vulnerabilities, which also sets out what a profile must require so that a CBOM and an advisory can be put together at all.
Consequence for this profile
For this reason, pqcPosture has been removed from the profile's attributes. It was carried in an early working draft, before v0.1, and no document was ever authored against that draft; the removal therefore appears in the profile specification's revision rationale rather than in its changelog, which records changes between published versions. Recorded as decision 0002. The profile requires disclosure of the facts from which posture is derived — the protocol, key exchange, encryption, and authentication algorithms, and the implementing library — while the posture itself is computed by an external policy at evaluation time. The same applies to any cryptographic maturity assessment.
Relationship to profiles and governance
An evaluation policy is versioned, dated, and governed in the same manner as a profile (see Versioning and Governance). Just as a conformance claim references the profile version, a posture or maturity determination references the policy version and the date on which it was applied, so that the determination is reproducible and its basis is auditable.