Introduction
This section assumes no prior knowledge of bills of materials. It follows one product, one CBOM and one question the CBOM cannot answer, then shows what a profile does about it. Every other section expands on something that happens here.
The problem, in one example
A vendor supplies an nginx web server and, with it, a CBOM. From that document you learn that the product uses AES-256-GCM, X25519 and RSA-2048, that it holds a server certificate for example.com, and that OpenSSL 3.4.0 implements the cryptography. Every statement in it is true.
Document A, as supplied
────────────────────────────────────────────────────────────
subject nginx 1.27.0
interfaces 1 declared
[1] HTTPS service interface
protocol TLS 1.3
key exchange X25519
encryption AES-256-GCM
authentication RSA-2048
certificate example.com
implemented by OpenSSL 3.4.0
not declared the interface an administrator logs in to
(on this product, SSH via OpenSSH)Three months later a weakness is published against a key exchange that SSH uses. The question that lands on your desk is whether this product is affected, and if it is, which of the several hundred instances you operate.
Document A cannot answer. It describes the interface that serves web traffic and says nothing about the interface an administrator connects to. The vendor was not careless. It described the interface it declared accurately and in full, and nothing obliged it to declare the other one.
A CBOM format defines what a document may record. It does not define what a document must record. A vendor that answers a request for a CBOM with Document A has complied with the format and left the buyer no better off.
Document A is not an unusual document. It is the ordinary result of asking a supplier for a CBOM without saying what the CBOM is for.
Why asking for everything does not work
The obvious remedy makes matters worse. A large product performs thousands of cryptographic operations, and a document listing all of them buries the two or three facts any particular decision turns on. Exhaustive coverage is not useful coverage, and in practice no supplier would produce it.
There is no absolute standard of completeness for a CBOM. Completeness is relative to a purpose. So the question worth asking is not "does this document contain everything", which has no answer, but "does it contain what this decision needs", which does. That second question has an answer only if the decision has been written down first, in a form that something other than a person can check.
What a profile is
A profile is a short list of rules stating which attributes a CBOM must carry to support one stated decision, for one stated reader. It is a minimum reporting requirement. It is not a schema, and it is not a format.
The example used throughout: the Interface Disclosure Baseline
Every profile begins by naming who reads the document and what they are deciding. Without those two, there is no principled place for the list of rules to stop.
| The Interface Disclosure Baseline, v0.7 | |
|---|---|
| Reader | An operator or purchaser holding a product it did not build and cannot inspect, keeping a cryptographic inventory across an estate. |
| Decision | When a weakness is published against an algorithm, a protocol version or a library, which of the deployed interfaces are affected. And, set beside the record from last quarter, what has changed. |
| Actions | Record the interfaces and take no further action. Act on an affected interface by reconfiguring, upgrading or isolating it. Ask the producer for a fuller disclosure. Reject the submission as insufficient to inventory. |
Naming four actions is what makes the rest of the profile arguable. A reader with only one available action is not deciding anything, and a profile written from that has no test for whether it asks for the right things.
The baseline has thirteen rules, of two kinds.
Product rules: constraints on the set of interfaces
| # | The document must | Level | Because |
|---|---|---|---|
| P1 | declare at least one cryptographic interface | MUST | A CBOM describing no interface answers nothing. |
| P2 | declare at least one management interface, or state that there is none | MUST | This is the rule Document A fails. A hardware token with no configuration surface hides nothing by lacking one, so declared absence satisfies the rule and silence does not. |
| P3 | identify the subject it describes | MUST | An unidentified record cannot be matched to a deployment, or compared with the same product's record from last quarter. |
| P4 | state how complete its list of interfaces is | MUST | Otherwise a missing interface is uninterpretable. It could mean the interface does not exist, or that the producer chose not to list it. |
These four are the rules that catch omission, which no per-attribute rule can. A document can describe its service interface impeccably, pass every attribute rule, and still fail P2.
Interface rules: constraints on each one
These apply uniformly to every interface the document declares, however many that is.
| # | Attribute | Level | What it answers |
|---|---|---|---|
| I1 | protocol | MUST | TLS, SSH, IPsec, and similar |
| I2 | protocolVersion | MUST | Which version, since an advisory usually names one |
| I3 | keyExchange | MUST | How the session key is agreed |
| I4 | encryption | MUST | What protects the traffic once the key is agreed |
| I5 | authentication | MUST | How each end proves who it is |
| I6 | endpointRoles | MUST | Who is at each end, so the interface can be located in a topology |
| I7 | interfaceType | MUST | One of five values, among them service, management and interconnect. P2 is checked against this |
| I8 | lifecycleStage | MUST | Whether the value was intended, implemented, configured or observed, which is how much weight the reader should give it |
| I9 | implementationPurl | MUST | Which library implements it, so an advisory against that library can be matched. The one rule here a producer may answer by withholding |
Thirteen rules is the entire profile. It is short deliberately. It names the minimum that supports one decision and then stops, which is what makes it possible for a vendor to satisfy it and for a buyer to insist on it.
What the profile does not say
No rule asks whether the cryptography is any good. Whether a product is post-quantum ready is not a fact about the product. It is a judgement made against criteria that change over time, and it is kept outside the document, in versioned policy. The CBOM carries the facts. The policy reaches the verdict, and is dated so that a reader can tell which criteria produced it.
Evaluating two documents against the profile
Document A is the one above. Document B is the same product described by a supplier who declared both interfaces, the HTTPS service interface and the SSH management interface.
| Rule | Document A | Document B |
|---|---|---|
| P1 at least one cryptographic interface | passes | passes |
| P2 a management interface, or a statement that there is none | FAILS | passes |
| P3 the subject is identified | passes | passes |
| P4 the interface list states its completeness | passes | passes |
| I1 to I9 on every declared interface | passes (1 interface) | passes (2 interfaces) |
| Verdict | does not conform | conforms |
The Demo runs both of these in the browser, along with a third: a library with no administrative surface at all, which satisfies P2 by saying so.
The four disclosure outcomes
One refinement is worth meeting early, because it recurs throughout. In Document B the management interface does not name its implementing library. It carries a marker saying the value is withheld, and rule I9 accepts that, because I9 is the one rule in this profile marked withholdable.
The marker matters to whoever reads the document. A withheld value is a position the producer has taken and can be challenged on in a negotiation. An absent value could be anything. So the methodology separates four outcomes for any attribute, where the CBOM formats offer only present and absent.
| Outcome | What it says about the producer | Satisfies a MUST rule? |
|---|---|---|
| supplied | It knows the value and has published it | Yes |
| withheld | It knows the value and has decided not to publish it | Only where the rule is marked withholdable |
| unknown | It does not know the value | No, but it is reported separately from silence |
| undeclared | Nothing was said, and the reader cannot tell which of the other three applies | No |
The first three can be acted on. The fourth can only be guessed at, and a buyer who cannot tell a deliberate omission from an oversight has no basis for asking the supplier to fix it.
Where to go next
Nothing above depends on the rest of the documentation, and the rest of the documentation expands on it.
Demo
Run three documents against the profile and watch each rule resolve, including the four disclosure outcomes.
Overview
What each section covers, and two suggested routes through the material depending on why you are here.
Challenges
Why CBOMs behave the way Document A did, and what SBOM adoption already established about it.
Method
The twelve steps for defining a profile, if you are here to write one rather than to read one.
Terms is a glossary and sits in the Reference group. It is there for when a word is unfamiliar, not something to read first.
This documentation works a single example, an nginx web server expressed in CycloneDX 1.7, all the way through. The material is illustrative and demonstrates the methodology; it is not a normative deliverable of the PKIC CBOM Profiles Working Group.