A Shared Vision of SBOM Explained: The 2025 Multinational Guidance

"A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity" is a 10 page joint guidance document published on 3 September 2025 by CISA with the NSA and 16 cybersecurity organisations from 14 other countries. It sets no fields, formats or deadlines. Instead it records that governments on four continents agree SBOMs should be generated, shared and used for vulnerability, supply chain and licence risk, and it names harmonised technical implementations as the next step.

That next step has since arrived in pieces. CISA's 2026 Minimum Elements for an SBOM, published on 29 July 2026 with most of the same co-authors, replaced the 2021 NTIA baseline. Germany's BSI TR-03183-2 sets a stricter technical profile, Japan's METI guidance covers how to introduce SBOMs inside a company and its contracts, and the EU Cyber Resilience Act makes an SBOM a legal obligation for manufacturers from 11 December 2027. This post reads the Shared Vision itself, then lines it up against each of those documents so a supplier selling into several countries can build one SBOM process that satisfies all of them.

We read the Shared Vision PDF, the co-authors' statements of support, the 2025 draft and 2026 final minimum elements, the NTIA 2021 report, BSI TR-03183-2 2.1.0, METI's version 2.0 announcement and the Commission's CRA page. If you want the field by field history of the US baseline, our posts on the CISA minimum elements update and NTIA fields mapped to CycloneDX and SPDX go there; this one is about how the multinational picture fits together.

Key takeaways

• The Shared Vision was published on 3 September 2025, marked TLP:CLEAR, and runs to 10 pages. Its cover lists 18 organisations: CISA, the NSA, and agencies from Australia, Canada, the Czech Republic, France, Germany, India, Italy, Japan (two), the Netherlands, New Zealand, Poland, Singapore, Slovakia and South Korea (two). The European Commission's DG CONNECT contributed but is not an author.
• It is a statement of purpose, not a specification. It never names SPDX or CycloneDX, lists no data fields, and says plainly that "the use of SBOM does not pre-suppose any policy" and that policy is left to each country.
• It names three roles that benefit: producers, "choosers" (the document's word for procuring organisations) and operators. National cybersecurity organisations are a fourth audience.
• It lists four uses: vulnerability management, supply chain risk management, better development processes (including end of life planning) and licence management. Log4Shell is its worked example.
• It asks for automation in generation, management and consumption, points to VEX for prioritisation and to CSAF for advisories, and says SBOM data should flow into existing vulnerability, asset and supply chain risk tools.
• The 2026 Minimum Elements (CISA, NSA, FBI and international partners, 29 July 2026) are the technical follow through. They add SBOM author signature, tool name and version, generation context, component hash and licence, and they name SPDX and CycloneDX as the two widely used formats.
• BSI TR-03183-2 2.1.0 (20 August 2025) is stricter: JSON or XML only, CycloneDX 1.6 or SPDX 3.0.1 or later, SHA-512 hashes of each deployable component, filenames, and three file property flags.
• The CRA is the only one of these that is law. Its main obligations apply from 11 December 2027, with vulnerability reporting obligations already applying since 11 September 2026.
• A supplier selling into several markets can usually satisfy all of them with one build time SBOM per release, generated in CycloneDX 1.6 or later or SPDX 3.0.1 or later, with hashes, licences and identifiers filled in, signed, and delivered through a versioned URL or API.

What is "A Shared Vision of SBOM for Cybersecurity", and who published it?

CISA's publication page dates the document to 3 September 2025 and describes it as joint guidance from CISA and the NSA "in collaboration with" international cybersecurity organisations. The PDF's version history has a single entry for that date: "Initial version." It has not been revised since.

The introduction lists the authoring organisations. Apart from CISA, they are:

That is 18 organisations including CISA, from 15 countries. The counts in secondary descriptions vary. CISA's own web page says CISA and the NSA worked "in collaboration with 19 international cybersecurity organizations", while the 2026 Minimum Elements document, written a year later by CISA, refers to "Eighteen international cybersecurity organizations." The list printed in the PDF has 18 names in total, so we use that.

Two further details from the document matter for how you read it.

First, the European Commission's Directorate-General for Communications Networks, Content and Technology (DG CONNECT) is credited in the acknowledgements as a contributor. A footnote is careful about what that means: the document "does not interpret European Union law", does not bind the Commission, and "not all of its elements reflect Union law." Entities inside the scope of EU law may use it "for information purposes only." In other words, the EU took part in drafting, but the Cyber Resilience Act is still the thing an EU manufacturer must follow.

Second, the disclaimer says the document "does not bind the authoring organizations and is not intended to provide guidance on the implementation" of any legislation in their jurisdictions. It is a consensus statement, not a rule.

CISA published a companion page of statements from the co-authoring agencies. Most are short endorsements, but a few add context. METI's statement notes that Japan "released SBOM Guidance 2.0" the previous year, which ties the Shared Vision to the national document Japan already had. NCSC-NZ's director of regulatory and advisory wrote that New Zealand, as a buyer of offshore software, wants security built into products at origin rather than as an add on. Korea's NCSC pointed to recent attacks through software supply chains as the reason it joined.

What does the Shared Vision actually say?

The body of the document is short enough to summarise section by section.

What is an SBOM, in this document's words?

It defines an SBOM as "a formal record of the details and supply chain relationships of various components used in building software", the same wording NTIA used in 2021. It then sets three expectations that carry through every later document:

1. An SBOM "should be machine-processable in a widely used format."
2. It should carry enough information about open source and proprietary components "to correlate with other data sources, such as vulnerability databases and security advisories."
3. "Automation is a key goal for SBOM generation and use."

It also states the practical test: by analysing SBOM data, "a user should be able to determine whether a given component is present in a piece of software." That one sentence is the reason later documents insist on coverage of transitive dependencies and on explicit marking of unknowns. If an SBOM leaves things out without saying so, the absence of a component proves nothing.

What does it say SBOMs are for?

The document groups the value into four areas.

Vulnerability management. Producers and operators can map dependencies to lists of known vulnerabilities and monitor continuously for new ones. With supplier security advisories, "ideally, in an automation-friendly format like the Common Security Advisory Framework", an organisation can check whether a vulnerability in a component actually makes its software exploitable, and target mitigations instead of applying everything everywhere.

Supply chain risk management. Organisations may have organisation, industry or government policies that limit components by "where, how, by whom" they were developed. SBOM data lets a buyer apply those policies at purchase time, and gives suppliers an incentive to manage that risk earlier.

Improved software development processes. Teams save time by recognising components already approved under internal policy, catch known vulnerabilities and licence problems before release, and learn end of life or end of support dates early enough to plan replacements. After deployment, monitoring the SBOM shows which components "have become vulnerable over time."

Licence management. The document warns that violating an open source licence "can result in sale suspension or recall of software, fines, and reputational damage", with costs that can land on downstream organisations.

What is the Log4Shell example?

The document's only case study is Log4Shell, the December 2021 remote code execution flaw in Apache Log4j. It makes a narrow, accurate point: Log4j was "usually used as a transitive dependency", so organisations without SBOMs often had to search manually, while organisations with SBOMs "were able to report a relatively straightforward and efficient response." Its second figure shows response time along a supply chain: without SBOMs, each party waits for its upstream supplier to tell it whether it is affected, so delays add up at every hop. With SBOMs at every level, each party can check for itself.

If you want to see what that check looks like in practice, our post on using SBOMs during incident response walks through finding every affected product from SBOM data.

Who should care: producers, choosers and operators

The Shared Vision introduces a vocabulary that the 2026 Minimum Elements also uses for its intended audience (organisations that "produce software, procure software, or operate software"):

The document notes that one organisation, or one team, can hold several of these roles at once. A company that builds a product on open source and buys a commercial database is a producer and a chooser at the same time. It also names executive teams, legal and compliance, strategy and modernisation teams as interested parties.

How does it connect SBOMs to Secure by Design?

The longest section links SBOMs to the joint Secure by Design document "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security by Design and Default", whose second principle is "Embrace Radical Transparency and Accountability." Building and maintaining an SBOM for each product, requesting SBOM data from suppliers and making SBOMs available downstream are presented as ways for a producer to show due diligence. The conclusion goes further and calls SBOM adoption "an integral condition for software to be secure by design."

What does it say about generating, managing and consuming SBOMs?

This is the closest the document gets to technical guidance, and it is still high level:

• Generation should be automated and "ideally" part of the build, "using build-time tools", but SBOMs can also come from source repositories, and binary analysis can produce one for software that already exists.
• Management includes version control and knowing which metadata is current for which deployed systems.
• VEX and other "automation-ready data" can be used alongside SBOM data "to maximize effectiveness and assist in prioritization." The footnote points to NTIA's 2021 VEX overview.
• Consumption is where the value is. "An SBOM is only data, after all." It has to be mapped to vulnerability databases, security advisories, supply chain risk data, open source project details and end of life data, ideally inside tools the organisation already uses for supply chain risk, vulnerability and asset management.

What does it leave open?

Reading the Shared Vision for what it does not say is as useful as reading what it does. It does not:

• name any SBOM format. SPDX and CycloneDX never appear.
• list required data fields, or reference the NTIA minimum elements.
• say how deep an SBOM must go, how often it must be refreshed, or how it must be delivered.
• set deadlines, create obligations or refer to any national law, including the CRA, BSI TR-03183 or METI's guidance.
• address SaaS, AI systems, firmware or hardware specifically.
• say how a recipient should judge the quality or trustworthiness of an SBOM.

Its conclusion admits the gap directly. Further steps "could include the harmonization of technical implementations," because "divergent implementations could hinder widespread adoption." The rest of this post is about how far that harmonisation has gone since.

How does it relate to the NTIA 2021 minimum elements and CISA's 2026 update?

The 2021 baseline

NTIA published "The Minimum Elements For a Software Bill of Materials" on 12 July 2021, under Executive Order 14028. It defined three groups of elements:

• Data fields: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data, and timestamp.
• Automation support: machine readable formats, naming SPDX, CycloneDX and SWID tags.
• Practices and processes: frequency, depth, known unknowns, distribution and delivery, access control, and accommodation of mistakes.

On depth, NTIA asked for all top level components with their transitive dependencies, and at a minimum enough detail on top level dependencies to find the transitive ones.

The 2025 draft and the 2026 final

CISA published a draft "2025 Minimum Elements for a Software Bill of Materials" on 22 August 2025, with public comment through the Federal Register until 3 October 2025. That draft came out twelve days before the Shared Vision, which explains why the Shared Vision does not repeat any field list: the technical work was running in parallel.

The final version, renamed "2026 Minimum Elements for a Software Bill of Materials (SBOM)", was published on 29 July 2026. Its version history is explicit: 1.0 is the NTIA document of 12 July 2021, 2.0 is the August 2025 draft, and 2.1 is the July 2026 final, "updated document based on comments received." It "updates and replaces" the NTIA minimum elements.

Three things about the 2026 document link it directly to the Shared Vision.

1. Shared authorship. It is co-authored by CISA, the NSA, the FBI and the same group of international agencies, with one difference we noticed: the Cyber Security Agency of Singapore, a Shared Vision author, is not in the 2026 author list, while the FBI is new.
2. It cites the Shared Vision as evidence of international recognition, alongside METI's guidance, the CRA, BSI TR-03183-2 and CERT-In's Technical Guidelines on Bill of Materials.
3. It carries the same EU footnote. DG CONNECT again contributed, and again the document "does not interpret European Union law."

What the 2026 minimum elements require

The 2026 document splits data fields into SBOM metadata and component data, then lists practices.

The practices and processes are:

• Accommodation of Updates to SBOM Data: correct errors promptly.
• Coverage: all components "including transitive dependencies", with "no minimum depth." The stated test is that a recipient should be able to conclude a new vulnerability does not affect them if the component is not listed.
• Distribution and Delivery: available promptly to those who need it, for example with the installation, at a version specific URL, through an API or in a public repository. The old Access Control element was folded in here.
• Explicitly Identifying Unknown Information: say whether a missing value is unknown or withheld, and have a way for recipients to ask about redacted security information.
• Frequency: a new SBOM for every version, build or release, and a revised SBOM when new details are found or errors corrected.
• Machine-Processable Data: SPDX and CycloneDX are named as the "two data formats currently widely used." Recipients "should accept any widely used, interoperable, and machine-processable SBOM format" but should avoid SBOMs for new software in deprecated format versions.

The document also says what it does not do: the minimum elements "do not create new requirements" and its disclaimer says it is not compliance or legal advice. It flags four open areas for future work: SaaS and cloud, AI systems (pointing to the G7 "Software Bill of Materials for AI, Minimum Elements" guidance from May 2026), validation of SBOM quality beyond signatures, and correlation with security advisories such as VEX and CSAF.

How does it line up with national regimes?

The Shared Vision explicitly avoids prescribing policy, so the useful question is how the national documents its authors had already published compare with each other and with the 2026 baseline.

EU: the Cyber Resilience Act

The CRA, Regulation (EU) 2024/2847, was published in the Official Journal on 23 October 2024 and entered into force in December 2024. The European Commission's CRA page gives the application dates: the main obligations apply from 11 December 2027, and the reporting obligations have applied since 11 September 2026. The Commission also published practical guidance for manufacturers on 27 July 2026.

On SBOMs, the essential vulnerability handling requirements in Annex I, Part II require manufacturers to identify and document the components in their products, including by drawing up an SBOM in a commonly used, machine readable format that covers at least the top level dependencies. The SBOM forms part of the technical documentation, which CISA's 2026 document also notes. The CRA does not require manufacturers to publish the SBOM; it is made available to market surveillance authorities on request. The regulation also lets the Commission set the SBOM's format and elements through implementing acts.

Two contrasts with the US baseline stand out. The CRA's legal floor is "top level dependencies", while the 2026 minimum elements ask for full transitive coverage. And the CRA uses "manufacturer" as a legal term; the 2026 document adds a footnote saying its "producer" is not the same thing, since "all manufactures are producers, not all producers are manufacturers."

Germany: BSI TR-03183-2

BSI's Technical Guideline TR-03183 is described on BSI's site as its interpretation of the CRA requirements, written to help manufacturers prepare. It is "not binding or mandatory", "cannot be used as presumption of conformity", and will be replaced by harmonised European standards when those exist. Part 2 covers SBOMs. At the time of writing BSI's page names version 2.1.0 as the released version, dated 20 August 2025. Its document history shows how fast it has moved:

Version 2.1.0 requires:

• JSON or XML, valid against CycloneDX 1.6 or later or SPDX 3.0.1 or later.
• An SBOM built from the build process (a "Build SBOM"), with recursive dependency resolution for everything in the scope of delivery, at least up to and including the first component outside that scope.
• A new SBOM for every software version, and a new SBOM version only when information is added or errors are corrected.
• For the SBOM: creator (email address, or URL if there is none) and timestamp, with UTC recommended.
• For each component: creator, name, version, filename, dependencies (with completeness "clearly indicated"), distribution licences, a SHA-512 hash of the deployable component, and executable, archive and structured properties.
• If available: SBOM URI, source code URI, URI of the deployable form, other unique identifiers such as CPE or PURL, and original licences.

Its transitional rule is unusual. To comply you must use the most recent version on BSI's website; the immediately preceding version may still be used for six months after a new one appears. An SBOM that complied when it was delivered stays compliant. BSI's download area also lists a file named for a 2.2.0 version, so check the page for the current version before you build tooling around a specific field list.

Our BSI TR-03183 guide covers the guideline in more depth.

Japan: METI's SBOM guidance

METI published version 1.0 of its "Guidance on Introduction of Software Bill of Materials (SBOM) for Software Management" in July 2023 and version 2.0 on 29 August 2024, after a public comment period from 26 April to 27 May 2024. METI's announcement says version 2.0 added three things: concrete procedures for using SBOMs inside the vulnerability management process, a framework for deciding the range of software where introducing an SBOM is worth the cost, and items to set out in contracts with outsourcing partners, covering requirements, responsibilities, cost sharing and rights.

METI's document is aimed at both suppliers and buyers and is about adoption inside an organisation, not about a data schema. It sits closest to the Shared Vision in spirit: practical, voluntary and focused on value. The METI guidance post has the detail.

India and the others

The 2026 Minimum Elements also cites CERT-In's "Technical Guidelines on Bill of Materials", which covers SBOMs and other bills of materials. Several other Shared Vision authors (Australia, Canada, the Netherlands, New Zealand, Singapore, South Korea) do not appear in any of the documents we read with a separate SBOM data profile of their own. We have not attempted to catalogue procurement rules in each of those countries, so check locally if you sell to government buyers there.

What does it say about formats, VEX and sharing, and what does it leave open?

On formats, the Shared Vision says only "a widely used format." The specifics live elsewhere:

Both formats have also become formal standards. Ecma International's ECMA-424 page describes its current edition as defining CycloneDX v1.7, with a first edition in June 2024 and a second in December 2025. SPDX is published as ISO/IEC 5962:2021, which CISA's 2026 document cites, and SPDX 3.0.1 is the current specification on spdx.dev. Our post on whether SBOM formats are official standards has the history.

What remains open after all of these documents:

• Quality and validation. None of them sets a measurable quality bar beyond required fields. The 2026 document says accuracy, coverage and completeness are "out of the scope" and suggests comparing against repositories or binary analysis to find missing components.
• SaaS. The 2026 document says frequent changes and shared responsibility complicate SBOMs for SaaS and leaves additional elements for future work.
• AI. Left to the separate G7 guidance.
• Delivery protocol. Every document accepts several delivery routes and none mandates one.
• Identifiers. The 2026 document admits ambiguity around naming software producers will remain "until there is a consensus methodology."

Comparison table: status, scope and required fields

What changes in practice for a supplier selling into several countries?

The good news is that the documents converge more than they conflict. A single, well built SBOM can satisfy all of them if you design for the strictest field set. Here is the decision table we use.

Two practical cautions. The CISA "Component Producer" and the BSI "component creator" are close but not identical (BSI wants a contact address; CISA wants a name and warns against acronyms), so carry both rather than picking one. And BSI's filename and file property fields have no direct equivalent in the 2026 list, so a generic generator will usually leave them empty; you have to add them in the build.

Step by step: generate an SBOM for one release and record the gaps

This walkthrough uses a Node.js service, because the npm lockfile makes the steps easy to follow. The same pattern works for Python, Maven and Go with the generators shown in step 2. Every tool here is open source. The commands only read your project and write new files.

Step 1: Pin the release and its artifact

Generate the SBOM from the exact commit and lockfile you ship, not from a developer checkout.

git checkout v2.4.0
git status --porcelain   # should print nothing
npm ci --omit=dev        # install exactly what the lockfile says, production only
npm pack                 # produces the artifact you ship, e.g. orders-service-2.4.0.tgz
sha512sum orders-service-2.4.0.tgz

Step 2: Generate a CycloneDX 1.6 SBOM

The CycloneDX project publishes generators for most ecosystems.

# Node.js (npm)
npx @cyclonedx/cyclonedx-npm --spec-version 1.6 --output-format JSON \
  --omit dev --output-file sbom.cdx.json

# Python (requirements file)
pip install cyclonedx-bom
cyclonedx-py requirements --sv 1.6 --of JSON -o sbom.cdx.json requirements.txt

# Maven (writes target/bom.json and target/bom.xml)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Go module
go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod mod -json -licenses -output sbom.cdx.json

Check your generator's help output for the exact flag names in the version you install; they do change between major releases.

Step 3: Validate against the format schema

A file that does not validate fails BSI's rule and the 2026 machine processable element before anyone looks at fields.

# CycloneDX CLI (download a release binary from the CycloneDX GitHub organisation)
cyclonedx validate --input-file sbom.cdx.json --input-version v1_6 --fail-on-errors

For SPDX 3.0.1 output, validate with the SPDX project's own tools and JSON schema for that version.

Step 4: Check the SBOM level fields against the 2026 minimum elements

jq '{
  format_name: .bomFormat,
  format_version: .specVersion,
  sbom_serial: .serialNumber,
  sbom_version: .version,
  timestamp: .metadata.timestamp,
  authors: (.metadata.authors // []),
  tools: ((.metadata.tools.components // .metadata.tools // []) | map({name, version})),
  lifecycle: (.metadata.lifecycles // []),
  target: (.metadata.component | {name, version, purl})
}' sbom.cdx.json

Map the output to the 2026 elements:

Step 5: Count component level gaps

jq '[.components[]] as $c | {
  total: ($c | length),
  no_version: ($c | map(select((.version // "") == "")) | length),
  no_purl: ($c | map(select(.purl == null)) | length),
  no_hash: ($c | map(select((.hashes // []) == [])) | length),
  no_sha512: ($c | map(select(([.hashes[]?.alg] | index("SHA-512")) == null)) | length),
  no_license: ($c | map(select((.licenses // []) == [])) | length),
  no_producer: ($c | map(select(.supplier == null and .manufacturer == null
                 and .author == null and ((.authors // []) == []))) | length)
}' sbom.cdx.json

Then check that dependencies and completeness are stated:

jq '{dependency_entries: (.dependencies // [] | length),
     compositions: [.compositions[]?.aggregate]}' sbom.cdx.json

If compositions is empty, nothing in the file tells a recipient whether the graph is complete. Add a composition entry whose aggregate value says complete, incomplete or unknown, which covers both the 2026 unknowns element and BSI's completeness requirement.

Step 6: Check the BSI specific fields

BSI's mapping appendix records its extra fields in CycloneDX as properties named bsi:component:filename, bsi:component:executable, bsi:component:archive and bsi:component:structured, and uses SHA-512 hashes.

jq '[.components[] | {
  name, version,
  filename: ([.properties[]? | select(.name == "bsi:component:filename") | .value] | first),
  executable: ([.properties[]? | select(.name == "bsi:component:executable") | .value] | first),
  archive: ([.properties[]? | select(.name == "bsi:component:archive") | .value] | first),
  structured: ([.properties[]? | select(.name == "bsi:component:structured") | .value] | first)
} | select(.filename == null or .executable == null or .archive == null or .structured == null)]
| length' sbom.cdx.json

For an npm package almost every component will show up here, because ecosystem generators do not emit these properties. Closing the gap means a post processing step in your build that knows the actual files you ship, computes SHA-512 over each, and writes the properties. Treat that as build engineering, not a one off edit.

Step 7: Sign the SBOM

The 2026 document says the signature should "use existing software signing infrastructure." If you already sign releases with Sigstore's cosign, sign the SBOM the same way.

cosign sign-blob --yes --bundle sbom.cdx.json.sigstore.json sbom.cdx.json

# A recipient verifies it against the identity you publish
cosign verify-blob --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity-regexp '^https://github.com/example-org/orders-service/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  sbom.cdx.json

Step 8: Record the gaps

Write the results down per release. A short register is enough, and it doubles as evidence when a buyer or an authority asks how you handle unknowns.

The numbers in that table are illustrative; use your own counts from step 5.

Step 9: Automate it in CI

A GitHub Actions job that builds the SBOM on every tag and attaches it to the release looks like this:

name: release-sbom
on:
  push:
    tags: ["v*"]
permissions:
  contents: write
  id-token: write   # for keyless signing
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: npm ci --omit=dev
      - run: npx @cyclonedx/cyclonedx-npm --spec-version 1.6 --output-format JSON --omit dev --output-file sbom.cdx.json
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign-blob --yes --bundle sbom.cdx.json.sigstore.json sbom.cdx.json
      - run: gh release upload "${GITHUB_REF_NAME}" sbom.cdx.json sbom.cdx.json.sigstore.json
        env:
          GH_TOKEN: ${{ github.token }}

Pin actions to commit SHAs in production workflows, and add the validation and gap checks from steps 3 to 6 as failing steps once your gap list is short enough to enforce.

Step 10: Use the SBOM, not just publish it

The Shared Vision's sentence "An SBOM is only data, after all" is the step most teams skip. Feed the SBOM into whatever tracks vulnerabilities and assets for that product, re-check it when new advisories appear, and publish VEX or CSAF statements for vulnerabilities that do not affect you. With Safeguard, for example, safeguard scan --sbom sbom.cdx.json matches the components against vulnerability databases and writes the results as JSON under ./output.

Where Safeguard fits

Safeguard sits on the consumption side that the Shared Vision says is where the value is. It scans repositories, container images and SBOM files, matches components against vulnerability databases, shows which projects contain a given component and version, ranks findings with reachability analysis, and evaluates policies and gates. That turns a release SBOM into a list of things to fix.

It does not decide whether your SBOM meets the CRA, BSI TR-03183-2 or any other regime, and it is not legal advice. Field coverage such as BSI's file properties, producer contact addresses or a correct composition statement depends on your build and your generator, and the gap checks above are still your team's job.

Common mistakes

• Treating the Shared Vision as a specification. It has no fields or formats. Cite it in a policy for intent, then cite the 2026 Minimum Elements, BSI or the CRA for requirements.
• Building to the CRA floor only. "At least top level dependencies" is a legal minimum. The 2026 coverage element and BSI's recursion rule ask for more, and buyers will often ask for the full graph.
• Generating from a developer machine. A Build SBOM must reflect what was built. Locally generated files pick up dev dependencies and stale lockfiles.
• Leaving gaps silent. A missing licence or hash with no explanation reads as carelessness. Mark it unknown or withheld, as the 2026 document asks.
• Using deprecated format versions. BSI requires CycloneDX 1.6 or SPDX 3.0.1 or later; the 2026 document says to avoid deprecated versions for new software.
• Confusing producer, supplier, creator and manufacturer. Each document uses a different word with a slightly different meaning. Map them explicitly in your build configuration.
• Never versioning the SBOM itself. Correcting an SBOM without bumping its version and timestamp leaves recipients unable to tell which copy is current.
• Shipping an unsigned SBOM. Signature is now a minimum element in the US baseline.
• Publishing and forgetting. An SBOM that no one matches against advisories delivers none of the value the Shared Vision describes.
• Assuming BSI's field list is fixed. BSI's transitional rule gives six months after a new version; watch the page.

FAQ

What is A Shared Vision of SBOM for Cybersecurity?

A 10 page joint guidance document published on 3 September 2025 by CISA, the NSA and 16 cybersecurity organisations from 14 other countries. It explains why SBOMs matter for vulnerability, supply chain and licence risk, who benefits, and calls for harmonised technical implementation. It sets no requirements of its own.

Which countries signed the Shared Vision of SBOM?

Agencies from the United States, Australia, Canada, the Czech Republic, France, Germany, India, Italy, Japan, the Netherlands, New Zealand, Poland, Singapore, Slovakia and South Korea. Japan and South Korea each have two signing organisations. The European Commission's DG CONNECT contributed but is not an author.

Is the Shared Vision of SBOM mandatory?

No. Its disclaimer says it does not bind the authoring organisations and does not provide guidance on implementing any legislation. Obligations come from national or regional law, such as the EU Cyber Resilience Act, or from procurement contracts.

Does the Shared Vision require SPDX or CycloneDX?

It does not name any format; it asks for a "widely used", machine processable one. The 2026 Minimum Elements name SPDX and CycloneDX as the two widely used formats, and BSI TR-03183-2 2.1.0 requires CycloneDX 1.6 or later or SPDX 3.0.1 or later.

What replaced the NTIA minimum elements for an SBOM?

CISA's "2026 Minimum Elements for a Software Bill of Materials (SBOM)", published on 29 July 2026 after a draft in August 2025 and public comment that closed on 3 October 2025. It states that it "updates and replaces" the NTIA 2021 document.

What new fields did the 2026 minimum elements add?

SBOM author signature, SBOM data format name and version, SBOM generation context, SBOM tool name and version, SBOM version, component hash value, component hash algorithm and component licence. Supplier name was replaced by component producer, and the access control practice was folded into distribution and delivery.

Does the EU Cyber Resilience Act require an SBOM?

Yes. Manufacturers of products with digital elements must draw up an SBOM in a commonly used, machine readable format covering at least the top level dependencies, as part of the technical documentation. The main obligations apply from 11 December 2027. The SBOM does not have to be published, but authorities can request it.

Is BSI TR-03183-2 the same as CRA compliance?

No. BSI describes TR-03183 as its interpretation of the CRA and says it is not binding and cannot be used as a presumption of conformity. It is a useful, stricter technical profile, and it will be replaced by harmonised European standards when they exist.

Can one SBOM satisfy the US, German, Japanese and EU expectations?

Usually, if you build to the strictest field set: CycloneDX 1.6 or SPDX 3.0.1 or later, full transitive coverage with completeness stated, SHA-512 hashes, PURLs, SPDX licence expressions, creator email or URL plus producer name, the BSI file properties, a signature and a new SBOM per release.

Does an SBOM say whether my product is vulnerable?

No. BSI's guideline says it plainly: an SBOM contains no statement about vulnerabilities or exploitability. You match it against vulnerability data and publish VEX or CSAF advisories to say which vulnerabilities actually affect the product.

An SBOM programme built to these documents tells you, quickly and per release, which open source components and versions you ship. The point of knowing is to act on it: the same inventory that satisfies a buyer or a market surveillance authority is the list of dependencies you need to move to safe versions when an advisory lands.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, the engineer asks it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan .. The same flow applies when your release SBOM shows a vulnerable component: the fix lands in the manifest, the next build regenerates the SBOM, and the new SBOM version shows the change.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. Teams that keep build systems and SBOMs inside their own network can scan release SBOMs and repositories this way without moving the source elsewhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude can use. A product security engineer answering a buyer's SBOM question can then ask about known vulnerabilities in the projects behind a release, using only the tools the administrator allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• CISA: A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity (publication page)
• CISA: A Shared Vision of SBOM for Cybersecurity (PDF, 3 September 2025)
• CISA: Statements of Support on A Shared Vision of SBOM for Cybersecurity
• CISA: Software Bill of Materials (SBOM) hub
• CISA: 2025 Minimum Elements for an SBOM (draft and request for comment)
• CISA: 2026 Minimum Elements for an SBOM (publication page)
• CISA: 2026 Minimum Elements for an SBOM (PDF, 29 July 2026)
• NTIA: The Minimum Elements for a Software Bill of Materials (12 July 2021)
• NTIA: Minimum Elements report (PDF)
• BSI: TR-03183 Cyber Resilience Requirements for Manufacturers and Products
• BSI: TR-03183-2 Part 2: Software Bill of Materials, version 2.1.0 (PDF)
• METI: Announcement of SBOM guidance version 2.0 (Japanese, 29 August 2024)
• European Commission: Cyber Resilience Act
• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
• Ecma International: ECMA-424 CycloneDX Bill of Materials Specification
• SPDX: Specifications
• OASIS: Common Security Advisory Framework (CSAF) documentation

Last reviewed: 24 October 2026. BSI updates TR-03183-2 regularly and the Commission may set SBOM details for the CRA through implementing acts; check the linked pages for the current versions before you build tooling around a specific field list.