Profiles

A profile is one file that says what “good” means for one regulation, program, or use case.

  1. The catalog
    1. Regulations and programs
    2. License use cases
    3. Which minimum-elements profile to use
  2. How much of a standard a profile actually covers
    1. cert-in-v2.0 covers 8 of 21 fields
    2. openchain-telco-v1.1 cannot reject a non-SPDX document
  3. Regional coverage, and what is missing
  4. Picking one
  5. Rule severity
  6. Composing and overriding

The catalog

Thirteen usable profiles ship with the tool, plus one withdrawn id that refuses to run. Run ossbomer profiles to see them locally.

Regulations and programs

Profile Standard
cisa-2026-min CISA 2026 SBOM Minimum Elements
ntia-min-elements NTIA Minimum Elements for an SBOM (2021, superseded)
cisa-2025-min CISA 2025 Draft SBOM Minimum Elements (superseded)
eu-cra-annex-i EU Cyber Resilience Act, Annex I Part II(1)
bsi-tr-03183-v2.1 BSI TR-03183 Part 2 v2.1
cert-in-v2.0 India CERT-In SBOM Guidelines v2.0
openchain-telco-v1.1 OpenChain Telco SBOM Quality v1.1
fedramp-sbom FedRAMP SBOM expectations, via EO 14028 and the CISA minimum elements
aibom-v0.1 AI Bill of Materials (net-new, advisory)
eu-cra-annex-vii Withdrawn. Cited clauses that do not exist; refuses to run and exits 2. Use eu-cra-annex-i.

License use cases

Profile Use case
license-distribution Distributed commercial product
license-mobile Mobile application
license-saas Network service
license-internal Internal use only

aibom-v0.1 is advisory. It is our own construction rather than a published standard, and its rules sit at SHOULD until the IR carries model, weights, and training-data entities.

Which minimum-elements profile to use

Use cisa-2026-min. CISA published the 2026 Minimum Elements on 2026-07-29, and it “updates and replaces” the 2021 NTIA document that ntia-min-elements encodes. It adds ten data fields, renames four, and is co-sealed by seventeen international cybersecurity bodies.

The two older profiles still ship and still work:

Profile Why it is still here
ntia-min-elements Contracts and procurement language written against the 2021 document need a check that still means 2021. It is not retrofitted for that reason.
cisa-2025-min The August 2025 draft, whose comment period closed 2025-10-03. Kept so a validation run from the comment window stays reproducible.

Neither is a moving target. If you want the current baseline, name cisa-2026-min explicitly rather than expecting the older ids to track it.

How much of a standard a profile actually covers

A PASS means every rule in the profile passed. It does not always mean the document meets the whole standard, because some standards ask for data an SBOM does not carry. Where that is true it is stated here rather than left for you to discover from a customer.

cert-in-v2.0 covers 8 of 21 fields

CERT-In’s Table 5 lists twenty-one minimum data fields per component. This profile checks eight: Component Name, Component Version, Component Supplier, Component License, Component Dependencies, Author of SBOM Data, Timestamp and Unique Identifier.

Thirteen are unchecked, and they fall into two groups.

Not expressible in an SBOM. Patch Status, Criticality, End-of-Life Date, Usage Restrictions, Vulnerabilities, Component Origin and Component Description are judgements your organisation makes about a component, not facts the component ships with. Neither SPDX nor CycloneDX has a native field for most of them. CERT-In is asking for something wider than an SBOM: a component register, of which the SBOM is one input. No tool reading only an SBOM can verify them.

Expressible, not yet checked. Checksums or Hashes is the notable one. Both formats carry it, every other profile here checks it, and it is simply missing. Executable Property, Archive Property, Structured Property and Comments or Notes are also representable with some work.

So treat a cert-in-v2.0 PASS as “the SBOM-verifiable subset of CERT-In is satisfied”, not as CERT-In conformance. The remaining thirteen need evidence from outside the document.

openchain-telco-v1.1 cannot reject a non-SPDX document

§3.1 of the Telco Guide requires SPDX, version 2.2 or 2.3. Nothing else conforms. This profile sets an SPDX version floor but cannot express “SPDX and nothing else”, so a CycloneDX document runs through the element checks and can report PASS while being non-conformant on format alone.

Until that is fixed, confirm your document is SPDX before trusting a Telco verdict. The profile also checks six of the seventeen items §3.2 requires; most of the rest are guaranteed by any valid SPDX file, but CreatorComment, PackageLicenseDeclared, PackageCopyrightText and the Relationship requirement are genuinely unchecked.

Regional coverage, and what is missing

By jurisdiction, what ships today:

Region Covered by Status
United States cisa-2026-min, ntia-min-elements, fedramp-sbom Yes
European Union eu-cra-annex-i Yes
Germany bsi-tr-03183-v2.1 Yes
India cert-in-v2.0 Yes
Telecom sector openchain-telco-v1.1 Yes, sector rather than region
Japan none Not covered
United Kingdom none Not covered
South Korea, China, Australia none Not covered

Japan’s METI SBOM guidance is a real and known gap. It is not shipped because writing a profile means transcribing the actual clauses and citing them, and a profile with invented rules is worse than no profile: it would report a confident verdict against requirements nobody published. The same holds for the other uncovered jurisdictions.

If you need one of these now, write it as an overlay. See Writing your own profile. Contributions of a properly cited regional profile are very welcome.

Picking one

Match the profile to the obligation you actually have. If you sell into the EU, eu-cra-annex-i. If you are answering a US federal procurement question, ntia-min-elements or fedramp-sbom. If a customer sent you a questionnaire citing BSI, bsi-tr-03183-v2.1.

Run several at once when you have several obligations. Each answers separately:

ossbomer validate \
  --profile eu-cra-annex-i \
  --profile ntia-min-elements \
  --file sbom.json

License profiles are orthogonal to the regulation ones, so pairing a regulation profile with the license profile matching how you ship is a common combination:

ossbomer validate --profile eu-cra-annex-i --profile license-mobile --file sbom.json

Rule severity

Every rule in a profile carries a severity, which is what turns a list of findings into a verdict:

Severity Meaning
MUST Required. Failing it fails the profile.
MUST_WHERE_AVAILABLE Required when the document carries the field at all. Absent field warns; present but wrong fails.
SHOULD Recommended. Failing it warns.
MAY Informational. Reported, never changes the verdict.

Rules also carry a citation naming the clause they come from, so a finding can be traced back to the source text rather than taken on faith.

Composing and overriding

Profiles compose with extends and subtract with excludes. That is how you keep an internal standard without copying the public catalog into your repo:

id: acme-shipping-bar
extends: [eu-cra-annex-i, fedramp-sbom]
excludes: [cra-top-level-dependencies]
rules:
  - id: acme-namespace-tag
    scope: component
    severity: MUST
    category: Provenance
    citation: "Internal ACME Engineering Standard 7.4"
    field: purl
    validators: [present]

Put that file in a directory of your own and point at it:

ossbomer validate \
  --profile acme-shipping-bar \
  --file sbom.json \
  --profile-path ./private-profiles

Your overlay refers to public rule IDs by name, so catalog updates reach you without a merge. --profile-path takes several directories separated by the platform path separator (: on Linux and macOS).

For the full set of keys a profile file accepts, see Profile format.