On 22 August 2025 CISA published a draft update to the SBOM minimum elements for public comment, building on the 2021 NTIA baseline. The comment period closed on 3 October 2025. The draft adds four data fields (component hash, license, tool name and generation context) and tightens the definitions of several existing ones. CISA's document says these elements "do not create new federal requirements", but buyers use it as a yardstick, and it is the clearest public statement of what a good SBOM contains.
If a customer has asked for an SBOM in a security questionnaire or a contract, this is your checklist.
What's affected
Any company shipping software, SaaS or a self-hosted product to enterprise or regulated customers. The request usually arrives in one of three forms:
- A questionnaire line: "Can you provide an SBOM in CycloneDX or SPDX?"
- A contract clause that requires an SBOM for each release.
- A follow-up after a headline vulnerability: "Are you affected by this package?"
CISA names SPDX and CycloneDX as the two widely used formats and says organizations should accept any widely used, interoperable, machine-processable format.
How to check if you're exposed
Generate an SBOM for your main product and compare it against the draft's elements. The data fields in CISA's draft are: SBOM author, software producer, component name, component version, software identifiers (CPE or package URLs are preferred), component hash, license, dependency relationship, tool name, timestamp and generation context. The draft also describes practices that matter to a recipient:
- Frequency: each version or update should have its own SBOM, and a corrected SBOM should be issued when you find errors.
- Coverage: include all components, including transitive dependencies. There is no minimum depth.
- Known unknowns: if the SBOM does not list all dependencies, say so explicitly. The default interpretation is that the data is incomplete.
- Distribution: make SBOMs available promptly, for example at a version specific URL or through an API.
A minimal CycloneDX fragment showing the new fields:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"metadata": {
"timestamp": "2026-10-18T09:00:00Z",
"lifecycles": [{ "phase": "build" }],
"tools": { "components": [{ "type": "application", "name": "your-sbom-tool", "version": "1.2.3" }] }
},
"components": [
{
"type": "library",
"name": "example-lib",
"version": "2.4.1",
"purl": "pkg:npm/example-lib@2.4.1",
"hashes": [{ "alg": "SHA-256", "content": "<64 hex characters>" }],
"licenses": [{ "license": { "id": "MIT" } }]
}
]
}
Replace the placeholder hash with the real digest your tool computes. Do not edit values by hand.
If you only have a package.json or requirements.txt, you can run the free dependency scan in the browser. It accepts package.json, requirements.txt, CycloneDX or SPDX files, handles up to 100 dependencies per scan, and the file never leaves your machine.
What to do now
- Ask the customer what they need: one SBOM per release, per product, or on request. Ask which format and whether they have an intake portal.
- Generate the SBOM in your build pipeline, not from a laptop, so it matches the artifact you ship. Record the generation context honestly: source, build or post-build.
- Check completeness. Compare component counts against your lockfile. Mark known unknowns, for example vendored code or binary blobs.
- Decide how you deliver it: a gated download, a customer portal or an email under NDA. CISA notes access controls may limit sharing with outside parties.
- Prepare a short reply. A usable template:
Subject: SBOM for [product] version [x.y.z]
Attached is the CycloneDX SBOM for [product] [x.y.z], generated at build time on [date].
It covers direct and transitive dependencies. Items we could not enumerate are listed
under known unknowns. We issue a new SBOM with each release and will send a corrected
file if we find errors. Please tell us if you need SPDX instead.
- Write down who answers follow-up vulnerability questions and how fast.
Three levels of SBOM, three audiences
CISA's generation context element names three points at which an SBOM can be produced, and recipients read them differently:
| Context | Built from | What the recipient can trust |
|---|---|---|
| Before build | Source repositories and manifests | Declared dependencies, but not what the build actually pulled in |
| During build | The build process itself | The exact components that went into the release artifact |
| After build | Binary analysis of the shipped artifact | What is really in the file, including vendored code |
For a customer who will use the SBOM to check exposure after a disclosure, a build-time SBOM is the most useful starting point. If you can add a post-build analysis, the two together show the customer where declared and actual contents differ. Label each file with its context so the reader does not have to guess.
How to avoid this trap
- Do not send a pile of unlabelled JSON. A recipient needs context, such as version, date and how it was generated.
- Do not claim completeness you cannot show. The draft treats incomplete data as the default and asks you to say what is missing.
- Do not generate once and forget. An SBOM that describes version 1.8 when you shipped 2.1 is worse than none.
- Do not leak private package names or internal repositories. Redact deliberately, and say what was redacted, as the draft's known unknowns guidance describes.
- Do not mix formats across releases without telling the customer.
Why it matters
The ask has changed from "do you know what is in your software?" to "show me, and show me again every release." SBOMs are the cheapest way to answer the question that follows every major disclosure: are we affected?
CISA's draft also points at what comes next. It notes that discussions have begun about extra data for SaaS and for AI software. Building the habit now, with a pipeline that produces a clean SBOM per release, means those extensions will be an incremental change rather than a project.
Try it yourself
Generate an SBOM for one repository today and walk through the elements list above. For each field, mark present, absent or unreliable. Fix the absent ones in your generation settings.
Click through it at your own pace, or open it full screen.
Quick check
Name two data fields CISA's 2025 draft adds to the minimum elements.
Any two of: component hash, license, tool name, generation context.
If your SBOM cannot list every dependency, what should it do?
State the known unknowns explicitly. CISA's draft says the default reading of an SBOM is that the data is incomplete.
Which two formats does CISA name as widely used?
SPDX and CycloneDX.
