How to define a CBOM profile

This section states the procedure. The sections before it establish what a profile is and the vocabulary it is written in; the sections after it show the procedure applied. A sector body adopting this methodology follows the twelve steps below.

The shape of the work

The steps group into five stages. The order matters more than it might appear: each stage constrains the next, and the most common way to produce an unusable profile is to begin in the middle, at the point where attributes are chosen.

Stage 1 — Scope

Step 1. Name the consumer and the decision

Write down who will read a CBOM evaluated against this profile, and what they will do differently depending on what it says. Both halves are required. A named consumer with no decision produces a profile that collects data nobody acts on; a decision with no named consumer produces one that nobody is accountable for satisfying.

The test to apply: state the decision as a sentence containing a choice. "Whether to schedule this system for upgrade, replacement, or no action" passes. "To understand our cryptographic position" does not, and a profile written from it will grow until it demands everything.

Write the choices down as objective.decisionOptions rather than leaving them implied in the sentence. Two or more are required, which is what turns the test above from advice into something check_profile.py enforces under C1. A profile whose author cannot list a second option has not yet found the decision.

Step 2. Establish the subject and its boundary

Decide what the profile describes: a product, a deployed service, a component, or a bounded part of an estate (estate-subset). Then decide where the boundary sits, which means deciding what the producer can reasonably declare. A profile for a product a consumer cannot inspect is limited to what is observable or assertable at its interfaces. A profile for an operator's own service can ask for more.

The boundary is a feasibility constraint and setting it early prevents work on attributes nobody will supply. The test: for each thing you intend to ask for, could the producer answer without disclosing something it has a legitimate reason to protect? See the black-box discussion in PQC Migration for a worked instance.

Three further decisions belong here rather than later, because each bounds what the profile can ask for. Which relationship types the rules will constrain, from the vocabulary in Model. Which cryptographic purposes the profile requires in depth: a profile may address key establishment now and entity authentication later, and saying so here is what lets the rules be written once and quantified over the declared set rather than rewritten per stage. And which lifecycle stages the profile will accept: a procurement or migration profile has no use for cryptography a producer merely intended, while a disclosure baseline should record whatever the producer can report and leave the narrowing to profiles derived from it. Then state the profile's orientation: inventory if it reports what interfaces do, migration if it reports what they could do, both if it reports both. That declaration is not descriptive. Under C12 an inventory profile may require no forward-looking attribute, and a profile declaring both must require the present-state attribute behind every capability attribute it asks for, so that capability never arrives instead of present state. All four are recorded as the scope object required by C11, and the third is an acceptance constraint rather than a description — an interface reporting a stage the profile does not accept fails the rule that constrains the stage.

Also in stage 1: decide whether you are extending

Before deriving questions, establish whether an existing profile already covers part of the ground. If one does, the new profile can extend it, inheriting its rules and stating only additions and tightenings. If the new profile would need to relax anything the candidate base requires, it is an independent profile and should be written as one. That choice is made once, early, because it determines what the remaining steps produce: an extension states differences, while an independent profile states everything.

The rules governing extension, including why relaxation is excluded, are in Profile.

Stage 2 — Content

Step 3. Derive the questions

From the decision, enumerate the questions the consumer must answer to make it. Keep them as questions, phrased in the consumer's own language, and resist converting them to attributes yet. This is the step most often skipped, and omitting it produces profiles that mirror the fields a format happens to offer.

Expect between three and a dozen. If the list runs much longer, the decision in step 1 was probably too broad and should be split into separate profiles.

Step 4. Convert each question into a declarable attribute

Work through the questions and, for each, identify what would have to be disclosed to answer it. One question may need several attributes, and several questions may share one. Two properties are required of every attribute: it must be declarable at the boundary established in step 2, and it must be capable of being wrong in principle, which makes conformance meaningful.

Express attributes in format-independent terms. Use the vocabulary in the model, so that an attribute belongs clearly to a relationship, an endpoint, or an asset. Attributes that turn out to belong to none of those are usually judgements, which step 5 handles.

Naming conventions

Profiles written under this methodology are meant to be read together, and a reader should not have to work out that two names mean the same thing. Four conventions apply.

The fourth convention is a restatement of step 5 at the level of naming. A name that describes a conclusion tends to smuggle the conclusion back in even when the values beneath it are facts.

Where an existing profile has already published an attribute, later profiles reuse the name and its meaning without redefining it. Divergence here is the easiest way to make two profiles unusable together, and it is not always visible to whoever introduces it.

Step 5. Separate facts from judgements

Review the attribute list and remove anything that is a conclusion drawn against criteria that change over time. Post-quantum posture and cryptographic maturity are the two clearest cases. These belong to an external, versioned policy that reads the profile's facts and produces a dated verdict, and the reasoning is set out in Policy Evaluation.

The test: if the same disclosed values could yield a different answer next year without the product changing, it is a judgement. Keep the inputs, discard the conclusion.

Stage 3 — Rules

Step 6. Assign conformance levels and disclosure treatment

Give every attribute a level using BCP 14 keywords. Then decide, per attribute, what happens when a value is absent. Under the three-state model an attribute may be unknown to the producer or deliberately withheld, and a profile must say which attributes may be withheld and still conform. A procurement profile may permit none; a supply-chain disclosure profile will permit several.

The test for each attribute: what should a consumer conclude if this is missing? An attribute whose absence changes nothing does not need to be mandatory, and possibly does not need to be in the profile.

Step 7. Add the structural rules

Per-attribute rules catch misstatement. They do not catch omission, because a rule about interfaces says nothing about an interface that was never declared. Structural rules constrain the set: how many of a thing must be present, and of which kinds.

This is where a profile requires that a management interface exists at all, or that the producer states whether its list is complete. Structural rules are product-independent by construction, since they constrain kinds and counts and never name an instance.

Structural rules belong in the earliest version of a profile, and in the earliest stage of a family. Declaring that an interface exists is cheap for a producer; describing it in depth is what costs. A profile that defers the structural rules to a later stage in order to look undemanding lets a supplier conform while omitting an entire interface, which is the failure the worked example is built around. Depth is what a later stage adds; the shape of the answer is settled at the start.

Step 8. State the exclusions

Write down what the profile deliberately does not ask for, and why. This is not padding. It pre-empts the reasonable objection that something obvious was forgotten, it records the boundary decision from step 2 in a form a reader can check, and it makes later expansion a deliberate act.

Stage 4 — Realisation

Step 9. Define the format mapping

For each format the profile must support, state where every attribute lives. Because formats permit the same information to be encoded in more than one valid way, the mapping fixes a canonical location so consumers read from one place. Record the naming and encoding normalization the mapping assumes. The conventions and the reasoning are in Formats.

The profile itself stays format-independent. Adding support for a further format adds a mapping and changes no requirement.

Step 10. Declare the carrier acceptance range

State which format versions the profile accepts, using a minimum and a tested version, so that older documents are handled deliberately. The bands and the reasoning are in Versioning.

Step 11. Record the decisions and their revival triggers

Where a choice was made against a defensible alternative, record it with the condition that should cause it to be revisited. A decision without a trigger tends to be either re-argued from scratch or never re-examined. The working group's decision-record template applies, and Governance covers how profiles evolve after publication.

Stage 5 — Proof

Step 12. Build the examples and run them

Produce at least two documents: one that conforms and one that fails for a specific, stated reason. Implement the rules in machine-readable form and run a validator over both. A profile that has never been executed has not been tested, and the failures this step surfaces are usually in the attribute definitions rather than in the tooling.

Expect to return to stage 2. Attributes that read well in prose turn out to be ambiguous when something has to decide whether a document satisfies them, and conditional or list-valued attributes are where this happens most.

Staging a profile across releases

A profile that asks for everything a mature producer could supply will be satisfied by nobody at the start, and one pitched at what producers can supply today will still be pitched there in three years. Publishing a family in stages is the usual answer, and two rules keep it honest.

Every stage supports a decision of its own. A stage is a profile, so C1 applies to it: it names a consumer and a decision and states the options that consumer chooses between. The tempting alternative — making the first stage the attributes that are cheapest to produce — yields something a supplier can be certified against and a consumer can do nothing with. The first stage is not the easiest questions; it is the smallest set that answers a real one.

What a stage defers, it still asks about. Depth is what a stage withholds, not the subject. A profile requiring full detail for key establishment can require a one-word status for entity authentication, and should: it costs the producer a single enumerated value, it tells the consumer where the longest-lead work stands, and it gives the next stage something to have improved on. Without it the deferred subject is simply absent, and the first stage becomes the permanent answer — the pattern SBOM minimum elements fell into, described in Challenges.

Where the date by which a stage stops being acceptable belongs is a separate question, and not one a profile should answer. A profile cannot know a given consumer's risk position, and a standards body setting commercial deadlines for parties it has no relationship with tends to be ignored rather than followed. The profile makes the stages nameable and checkable; a contract makes one of them due.

When a profile is finished

The criteria for a first release, as opposed to a perfect one:

• The consumer and the decision are stated, and the decision contains a choice.
• Every attribute traces back to a question, and every question to the decision.
• No attribute encodes a judgement that policy should make.
• No rule names a product, a vendor, or an interface instance.
• Absence is defined for every attribute, including which may be withheld.
• Structural rules exist, so that omission is detectable.
• Exclusions are written down with reasons.
• A mapping exists for at least one format, with a stated acceptance range.
• A conforming and a non-conforming example exist, and a validator agrees with both.

Ways this goes wrong

Six failure modes, each observed while building the worked example in this documentation.

Worked application

The PQC Migration section applies this procedure end to end for a product treated as a black box, and is the reference example. The Profile section describes the resulting baseline profile in its finished form, and the Demo section runs stage 5 in the browser.