SBOM Generation and Analysis in Safeguard: NTIA Elements to the CRA

Safeguard generates software bills of materials in SPDX and CycloneDX from a connected repository, a CLI scan, an uploaded manifest or a container image, then analyses each one for vulnerabilities, licenses, suppliers and provenance and rescans it as your code and the advisory feeds change. SBOM generation and analysis is generally available (GA). It gives you the machine-readable inventory that the NTIA minimum elements, CISA's 2026 update and the EU Cyber Resilience Act expect, but the accuracy of that inventory still depends on your lockfiles and on what you choose to scan.

This post walks through what those documents actually ask of an SBOM, then the real Safeguard flow from the product docs, step by step, and ends with the limits you should plan around.

Key takeaways

• SBOM generation and analysis (GA). Safeguard produces SPDX (JSON, XML, RDF) and CycloneDX (JSON, XML) SBOMs from source repositories, container images, uploaded manifests and local CLI scans, and it imports SPDX and CycloneDX files you already have.
• SCA and deep transitive dependency scanning (GA). The SBOM covers direct and transitive dependencies, resolved from manifests and lockfiles across the major package ecosystems and container layers.
• Deep Analysis with Griffin (GA). An optional generation setting that adds Safeguard's own model analysis to the scan. You can switch it off, and the platform also runs in Zero AI mode (GA).
• Vulnerability management with EPSS and KEV enrichment (GA) and reachability analysis (GA) turn the inventory into a ranked list rather than a raw CVE count.
• Portal (GA), in its sense as the SBOM publish and share product, stores SBOMs, compares versions and shares them with customers and auditors under access controls.
• License compliance (GA), attestation and signing (GA), CSAF and VEX upload (GA) and the Compliance and GRC suite (GA) sit next to the SBOM, including an EU CRA framework whose scan requirements read the SBOM.
• CLI, local runner and MCP server (GA) let you generate SBOMs without granting repository access and query results from an assistant.
• What it does not do: produce a hardware bill of materials, describe runtime configuration, see components you never scanned, or turn an SBOM into a vulnerability verdict by itself.

Why SBOMs became a requirement, not a nice to have

An SBOM is a list of the components inside a piece of software and how they relate. Without one, three questions take days instead of minutes. Are we shipping the library in today's advisory? Which of our products contain it, and in which versions? What do we tell the customer who just asked?

Teams that skip SBOMs usually find out the cost during an incident. Someone greps repositories, someone else asks the container team, and a third person tries to remember which vendor appliance bundles which runtime. The answers arrive late and partial. The same gap shows up in procurement: a customer's security questionnaire asks for an SBOM, and the team produces a one-off export that is stale by the next release.

Regulators and large buyers have turned that gap into an obligation. Three documents set the shape of what "a good SBOM" means today.

What the NTIA, CISA and the CRA require of an SBOM

The NTIA minimum elements (2021)

The U.S. National Telecommunications and Information Administration published "The Minimum Elements For a Software Bill of Materials (SBOM)" in July 2021, following Executive Order 14028. The report groups the minimum into three areas.

Data fields. Seven baseline fields for each component:

Automation support. The SBOM must be machine-readable and generated in a format that tools can produce and consume. The report names SPDX, CycloneDX and SWID tags as the formats that qualify.

Practices and processes. How SBOMs are requested and delivered: Frequency (a new build or release means a new SBOM), Depth (all top-level components plus enough transitive detail to find dependencies), Known Unknowns (state explicitly where the graph is incomplete), Distribution and Delivery, Access Control, and Accommodation of Mistakes.

The NTIA report is careful to call these a floor. It says outright that the minimum is a starting point and that richer data, such as hashes and license information, would improve the picture over time.

CISA's 2026 minimum elements update

CISA put a draft update out for public comment on 22 August 2025, with comments closing on 3 October 2025. The final document, "2026 Minimum Elements for a Software Bill of Materials (SBOM)", was published on 29 July 2026 and is co-signed by a long list of agencies, including the NSA, the FBI, Germany's BSI, France's ANSSI, India's CERT-In and the national cyber agencies of several other countries.

The 2026 document keeps the NTIA structure of data fields plus practices, but the data field table grows. Its Appendix A lists these fields:

On practices, the 2026 document covers Coverage, Frequency, Distribution and Delivery, Accommodation of Updates to SBOM Data, and Explicitly Identifying Unknown Information. It also states its own limits: the minimum elements apply to SBOMs for all software, including open source, AI software and SaaS, and they "do not create new requirements" on their own. They refine how SBOMs are generated and requested. Contracts, procurement rules and regulations are what make them binding for a given supplier.

Two additions matter most for tooling. Component hashes let a consumer check that the component in the SBOM is the one they received. The generation context field makes the author say whether the SBOM came from source, a build or a deployed artifact, which changes how much a consumer should trust it.

The EU Cyber Resilience Act

The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements placed on the EU market. According to the European Commission, the CRA entered into force on 10 December 2024, its reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and its main obligations apply from 11 December 2027. On 27 July 2026 the Commission also published practical guidance for manufacturers.

The SBOM requirement sits in Annex I, Part II, point 1, the vulnerability handling requirements. Manufacturers must identify and document the vulnerabilities and components in their products, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the product's top-level dependencies. The same Part II goes on to require that vulnerabilities are addressed and remediated without delay, including through security updates, and that the manufacturer runs coordinated vulnerability disclosure with a contact address for reports.

Three practical consequences follow for anyone preparing for 2027:

1. Machine-readable is not optional. A PDF table of components does not meet the format test. SPDX or CycloneDX does.
2. Top-level is the legal floor, not the operational one. Most vulnerabilities that matter sit in transitive dependencies, so an SBOM that stops at the top level satisfies the wording and fails the purpose.
3. The SBOM is part of the technical documentation. Under the CRA, technical documentation has to be drawn up before the product goes on the market and kept available to market surveillance authorities. Treat each release's SBOM as a retained record, not a throwaway export.

Germany's BSI has published Technical Guideline TR-03183 to help manufacturers prepare for the CRA. Its Part 2 sets formal and technical requirements for SBOMs. The BSI is explicit that the guideline is not binding, cannot be used as a presumption of conformity, and will be replaced by harmonised European standards once those exist. It is still a useful checklist when a German customer asks what "good" looks like.

How the three compare

SPDX or CycloneDX: which formats Safeguard produces and imports

Both formats are open standards. SPDX is maintained by the Linux Foundation's SPDX project and is published as an international standard, ISO/IEC 5962:2021; the SPDX site lists versions 2.3 and 3.0 as current specifications. CycloneDX is an OWASP Foundation project, standardised by Ecma International as ECMA-424. The CycloneDX site lists 1.7, released on 21 October 2025, as the current version, and describes an object model that covers components, services, dependencies, compositions (including whether an inventory is complete or incomplete), vulnerabilities and more.

What Safeguard does with each, per its docs:

The safeguard validate command also checks VEX documents in CSAF and OpenVEX form against their specifications. Safeguard's EO 14028 docs recommend CycloneDX 1.5 or later or SPDX 2.3 or later as a best practice. The docs do not state which specification version each export targets, so check the specVersion or spdxVersion field in a sample export before you promise a customer a specific version.

When each format fits

• Choose CycloneDX when the SBOM feeds vulnerability workflows. Its vulnerability and VEX support, dependency graph and composition completeness markers line up well with "what is affected and what is not". Many security tools ingest it first.
• Choose SPDX when the audience is legal, licensing or procurement, or when a contract names ISO/IEC 5962. SPDX grew out of license compliance and its license expression syntax is the reference that other formats borrow.
• Produce both when you sell to a mix of buyers. Generating both from the same scan costs nothing extra in Safeguard, and the two then describe the same component set.

The CRA does not pick a format. It asks for a commonly used, machine-readable one, and both qualify.

How to generate an SBOM in Safeguard

Safeguard offers four entry points. They produce the same project view at the end, but they differ in who holds the code and how often the SBOM refreshes. If you are still choosing between connecting repositories and scanning locally, see repository connection, CLI or local runner.

Path 1: from a connected repository

This is the path for continuous coverage. Safeguard's docs walk through it with Bitbucket; GitHub, GitLab and generic Git URLs follow the same pattern.

1. Open Integrations from the sidebar. The page has tabs for Add Project/Product, Deployment, Configure Scanner and Notification, and filter buttons for Source Code (SCM), Container Image, Upload and other types.
2. Click Connect on the source control card you use.
3. For a public repository, choose the Public tab, name the configuration, paste the repository URL, wait for "Repository URL is valid", and click Add. For a private repository, choose Private, enter a username and an access token or app password, and click Verify Credentials.
4. On the review step, tick the repositories to include and set the Branch/Tag, Project Name (defaults to the repository name) and Version (defaults to 1.0.0) for each.
5. Click Connect. The configuration appears in the Project Configurations table, and the project appears under Projects.

The docs list these generation options:

Two of these choices affect compliance more than they look. Version becomes the version your SBOM claims, so tie it to release tags rather than leaving the 1.0.0 default. Include Dev Dependencies decides whether build and test tooling appears in the inventory. For a customer-facing SBOM, most teams leave it off; for an internal SBOM used to assess build pipeline risk, turn it on and record that choice in your SBOM policy.

The docs give rough generation times: under a minute for projects with fewer than 100 dependencies, two to five minutes for 100 to 500, and five to fifteen minutes for larger projects.

Path 2: from a CLI scan

The CLI (GA) builds the SBOM on your own machine or CI runner. Install and sign in exactly as the docs show:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the terminal, then type /login and /scan .
safeguard

# Or scan from the command line, writing results under ./output
safeguard scan --dir .

safeguard scan builds an SBOM for exactly one target, matches it against vulnerability databases, and writes JSON results under ./output by default. Results include vuln.json, license.json and collection.json, among others, in a folder per scan. Other targets the docs show:

# A container image
safeguard scan --image nginx:latest

# A Git repository
safeguard scan --repo https://github.com/org/repo

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

Flags worth knowing for SBOM work: --resolve-transitive resolves transitive dependencies, --org-namespace marks namespaces such as @mycompany as your own private packages, and --format auto|spdx|cyclonedx sets the format of an SBOM passed with --sbom. The deep dependency scanning docs show a depth setting for a local scan:

safeguard scan --dir . --resolve-transitive --transitive-depth 100

Two behaviours matter for compliance pipelines. First, a command line safeguard scan keeps results on the machine. To see the project in the platform, scan from the interactive terminal (/scan .) while signed in; the docs say the runner then uploads the SBOM and findings, never your source. Second, safeguard scan does not fail on findings. It exits 0 when the scan ran, 1 when the command itself failed, and 2 when results were written but the vulnerability scan did not actually run. Gating on findings is done by policy gates in the platform. The CLI relies on open source SBOM and matching tools that the interactive terminal downloads on first run; on a fresh CI container, the docs explain how to put them on the PATH or point TOOLS_DIR at them.

If you scan in CI, the GitHub Actions page shows a different command, safeguard ci scan, which waits for the platform result and can fail the job:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The secret comes from Settings → Developer with the scopes scans:trigger and scans:read. Drop --fail-on critical to report only, add --fail-on-gate all to fail on a policy gate, or add a checkout step and --local to scan on the runner rather than letting Safeguard clone the repository.

The CLI also produces SBOMs for some less common artifacts. safeguard wasm scan writes a CycloneDX 1.6 SBOM for dependencies embedded in a WebAssembly module at build time, and safeguard podman scan scans images in a Podman store with results kept on the machine.

Path 3: from an uploaded manifest

The Integrations page has an Upload Manifest File card for package manifests such as package.json or requirements.txt. This is the quickest way to get an inventory for a project you cannot connect, but it is also the least accurate path if you upload a manifest without its lockfile. A manifest declares version ranges; a lockfile records what actually installed. The SCA docs say Safeguard honours both manifests and lockfiles "so resolution matches what actually installs", which only works when the lockfile is there to read.

Path 4: from a container image

Container registries connect from the same Integrations page. The docs list Amazon ECR, Docker Hub, GCP Cloud Source and any OCI-compatible registry. From the CLI, safeguard scan --image reads public images, private registries (with --registry-username and --registry-password) and local images such as podman: references, docker-archive: files and oci-archive: files.

An image SBOM and a source SBOM answer different questions. The source SBOM shows what your code declares. The image SBOM shows what actually ships, including operating system packages and anything a base image brings along. For CRA purposes, the image is usually closer to "the product placed on the market", so generate both and keep them linked by version.

Path 5: import an SBOM you already have

If another tool or a supplier already produced an SBOM, safeguard scan --sbom reads SPDX or CycloneDX and runs the same analysis on it. Supplier SBOMs requested through TPRM (GA) also land in the platform and are rescanned on upload. Validate first with safeguard validate sbom.json --strict so a malformed file fails loudly instead of producing a silently thin inventory.

What the SBOM explorer shows per project

Once a project is scanned, clicking it in Projects opens the Project Overview. The tabs most useful for SBOM work, as the docs describe them:

Under the hood, the deep dependency scanning docs say Safeguard walks the resolved graph up to 100 levels, and at each node resolves the package URL and version against its vulnerability knowledge graph, computes license and provenance, feeds the node into reachability analysis, and records the full path from root to leaf. Clicking a finding shows that path, so you can see which direct dependency pulled in the vulnerable package and what the safe version would change.

The vulnerability data behind the explorer comes from vulnerability management (GA): advisories from sources such as NVD, GHSA, OSV and the CISA KEV catalog, enriched with EPSS scores. Reachability analysis (GA) then ranks findings by whether your code actually calls the vulnerable function. Safeguard's docs describe this as cutting 60 to 80% of CVE noise; treat that as Safeguard's stated figure, not a guaranteed result for your code. Reachability support varies by language. The reachability docs list static reachability as Preview for Ruby, PHP, and Swift and Objective-C, and dynamic reachability as Preview for Swift and Objective-C; the JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, and C# and .NET are GA for both. For how that ranking works and how to defend it, see prioritising with reachability, EPSS and KEV.

Checking an SBOM against the NTIA elements

Safeguard's EO 14028 compliance checks validate an SBOM against the seven NTIA data fields (supplier name, component name, version, other unique identifiers, dependency relationship, author and timestamp) and the automation support requirements (machine-readable SPDX or CycloneDX, automated generation and consumption). Each project gets a compliance score built from data completeness, format compliance, component coverage and SBOM freshness, with a status of compliant, partially compliant or non-compliant.

To see it:

1. Open a project from the Projects page.
2. Go to the Compliance tab for the per-project status.
3. For the organization view, open the Dashboard and look at the EO 14028 Compliance widget.
4. To produce a report, click Export → EO 14028 Compliance Report and choose PDF, HTML or JSON.

The docs state there is no CLI command for this report yet. The report covers an executive summary, SBOM details (format, timestamp, author), per-component completeness, a gap analysis and remediation steps.

Note what this check is built on: the 2021 NTIA elements. The docs do not describe a check against CISA's 2026 fields such as SBOM tool version, generation context or author signature. If a buyer asks for 2026 alignment, map the fields yourself using the table later in this post.

The EU CRA framework in Compliance

The Compliance and GRC suite (GA) includes an EU Cyber Resilience Act framework, switched on by default and managed under Compliance › Manage. Its scan requirements are evaluated against what each scan finds, including the product's SBOM. According to the docs, they check that an SBOM of top-level dependencies exists in a machine-readable format (Annex I Part II(1)), that it actually enumerates components, that exact component versions are present so advisories can be matched (Part II(2)), that composition documents carry a reachable creator contact for coordinated disclosure, that components carry integrity hashes, that each component has supplier attribution (Article 13 due diligence), and that documents are identifiable and timestamped for technical documentation (Article 31 and Annex VII).

The framework also lists controls from Safeguard's control catalog, such as providing an SBOM for third-party components and reporting actively exploited vulnerabilities, plus policy templates written for the CRA, including an SBOM management policy and a coordinated vulnerability disclosure policy. Controls that are not decided by a scan have to be evidenced with tests, uploaded evidence, policies or an attestation. For how evidence and tests fit together, see continuous compliance in Safeguard.

How continuous scanning keeps an SBOM current

An SBOM is a snapshot. The day after you generate it, a new advisory can make a clean component vulnerable, and the next merge can add a dependency. Both NTIA's Frequency practice and the CRA's vulnerability handling duties assume you keep up.

Safeguard's generate SBOM docs say the platform runs a daily continuous scan of all projects to catch newly disclosed vulnerabilities, and that you can add three triggers:

• On Push: scan on every commit to monitored branches.
• Scheduled: daily, weekly or a custom schedule.
• On Release: scan when new tags are created.

The continuous scanning docs add the mechanism. Rescans are driven by three signals: vulnerability feed updates (a new CVE, GHSA or OSV entry, a CISA KEV addition, or an EPSS change affecting a component you use), Safeguard's own advisory publications, and asset changes such as a new commit, a new image tag or a new vendor SBOM. Rather than re-traversing every SBOM, components are stored as searchable nodes, new advisories are matched by package URL, version range and CPE, and only affected assets are rescored. Uploaded SBOMs, your own and vendors', are rescored as feeds update.

Each asset keeps a Timeline of scans showing when each ran, what triggered it, and the diff of findings from the previous scan: added, resolved and changed in severity. That timeline is often the evidence an auditor wants when they ask "when did you know".

A practical cadence that maps to the requirements:

1. On Release for every tag you ship, so each released version has its own SBOM and the SBOM version matches the product version.
2. On Push for the default branch, so problems show up before release.
3. Leave the daily feed-driven rescan on, so a shipped version's findings stay current after release.

How to compare two SBOMs or versions

There are three places to see what changed between two SBOMs.

Portal version comparison. In the Portal (GA), open a product SBOM, click Compare Versions, and choose the versions. The comparison view lists added components, removed components, version changes, newly introduced vulnerabilities and fixed vulnerabilities. A Compare Products option shows several products side by side. This is the view to use before a release ("what does 2.4 add over 2.3?") and when a supplier sends a new SBOM.

The scan Timeline. Each project's Timeline shows the findings diff between consecutive scans. It answers "what changed in our risk" rather than "what changed in the component list", and the two are different: a component list can stay the same while a new advisory changes the findings.

Your own diff of CLI output. The CLI writes JSON results per scan under ./output. The docs do not describe a CLI diff command, so if you want a diff in a pull request, compare the exported SPDX or CycloneDX files with your own tooling. Sort components by package URL first, or every reordering will show up as noise.

The Portal Find & Review page also shows a Quality tab per SBOM with a completeness score and the fields that are missing. Run that against a supplier's SBOM before you accept it as evidence.

Export formats: what goes to a customer and what goes to an auditor

The explore SBOM docs say project data exports in more than 30 formats. The SBOM-relevant ones are SPDX (JSON, XML, RDF), CycloneDX (JSON, XML), CSV, an Excel workbook with multiple sheets, a formatted PDF report and raw JSON. The Portal adds an "Original" download (as the supplier provided it) and bulk export of several SBOMs into one archive.

How you hand it over matters as much as the format. Portal sharing (GA) lets you share with named recipients at View, Download or Full permission, create links with an expiry date, download limit, password and format restrictions, require NDA acceptance per SBOM, track who accessed what, and revoke access immediately. For the differences between publishing and sharing, see publish versus share in Safeguard Portal. For VEX, see ingesting and sharing VEX and CSAF in Safeguard.

A rule of thumb: send people a PDF, send systems JSON, and never send a PDF alone to anyone who has to meet a machine-readable requirement.

Requirement by requirement: what Safeguard covers and what you own

Autonomous remediation (GA) can open tested fix pull requests for findings in the SBOM, one at a time or in bulk, but it ships switched off with every category set to Manual. Nothing changes in your repositories until someone turns it on. For how the categories and strategies work, see autonomous remediation in Safeguard.

What an SBOM from Safeguard does not tell you

An SBOM describes software components found in what you scanned. It is silent on a lot that matters to security.

Hardware. Safeguard produces software bills of materials. It does not produce a hardware bill of materials (HBOM) for chips, boards or firmware you buy from a manufacturer, even though CycloneDX can represent hardware.

Runtime configuration. An SBOM lists the version of a web server, not whether it runs with a debug endpoint open, which feature flags are on, or what network policy surrounds it. Two deployments with identical SBOMs can have very different exposure.

Components you never scanned. If a service, a script directory or a vendor binary was not connected, uploaded or scanned, it is not in the inventory. The SBOM is complete only relative to its inputs, which is why both NTIA and CISA ask you to state unknowns explicitly.

Components without metadata. Code copied into your repository without a manifest entry, statically linked libraries with stripped symbols and vendored source trees may not be identified. Package metadata and lockfiles drive accuracy; when they are missing, the SBOM is thinner than the product.

A vulnerability verdict. A component in the SBOM with a matching CVE is a lead, not a conclusion. Whether you are affected depends on reachability, configuration and compensating controls, which is what reachability analysis and VEX statements are for.

What Safeguard does not do

Be specific about the edges before you plan a compliance programme around any tool.

1. It does not make you CRA compliant. The EU CRA framework checks SBOM-related requirements decided by a scan and gives you controls and policy templates. Conformity assessment, the EU declaration of conformity, CE marking, the support period decision and your vulnerability disclosure process are the manufacturer's obligations.
2. It does not file your CRA reports. From 11 September 2026, manufacturers must report actively exploited vulnerabilities. Safeguard can track the control; the report to the authorities is yours to submit.
3. It does not check the CISA 2026 elements as a named standard. The documented EO 14028 check is built on the 2021 NTIA fields. Map the 2026 fields yourself until the docs say otherwise.
4. It does not produce hardware or firmware bills of materials, and it cannot inventory software it was never pointed at.
5. It does not sign the exported SBOM document as documented behaviour. Attestation and signing (GA) covers provenance and artifacts; if a buyer asks for a signed SBOM file, add a signing step in your pipeline and confirm the approach with Safeguard.
6. It does not fix inaccurate inputs. Without lockfiles, with version ranges, or with vendored code lacking metadata, the inventory will be less exact. The docs' own guidance is to commit lockfiles and pin versions.
7. Its REST API for these flows is not live yet. Several SBOM-related docs pages carry a banner that the /v1 endpoints return 404 today. Use the web app, the CLI and CI integrations shown above.
8. It does not replace legal review. License compliance (GA) shows license types, compatibility and attribution requirements; deciding whether you can ship under them is a legal call.

Common mistakes

• Generating from the manifest alone. Without the lockfile, the SBOM records what was allowed, not what was installed. Commit lockfiles and scan the repository or image, not a lone package.json.
• Leaving the default version. A project left at version 1.0.0 produces SBOMs that cannot be matched to releases. Tie the Version field to git tags.
• One SBOM per year. The NTIA Frequency practice and the CRA's vulnerability handling both expect an SBOM per release and continuous monitoring after it. Turn on the On Release trigger.
• Sending a PDF to a machine-readable requirement. The PDF report is for people. Send SPDX or CycloneDX as well.
• Scanning source but shipping images. The container image includes operating system packages and base image layers that the source SBOM never sees. Scan the image you ship.
• Treating the CLI exit code as a gate. safeguard scan exits 0 even when it finds critical issues. Use safeguard ci scan --fail-on or a policy gate.
• Ignoring exit code 2. It means results were written but the vulnerability scan did not run. A script that treats it as success will report a clean result that never happened.
• Accepting supplier SBOMs without checking them. Run safeguard validate --strict and look at the Portal Quality tab before you rely on a vendor's SBOM in an audit.
• Hiding unknowns. If part of the product was not scanned, say so in the SBOM or the cover note. Both NTIA and CISA treat unstated gaps as a defect.

FAQ

Does Safeguard generate SBOMs in SPDX and CycloneDX?

Yes. SBOM generation and analysis is GA. Projects export SPDX in JSON, XML and RDF and CycloneDX in JSON and XML, alongside CSV, Excel and PDF. The CLI imports either format with safeguard scan --sbom and detects which one it is.

Can I generate an SBOM without giving Safeguard access to my repository?

Yes. Run the CLI or the local runner on your own machine. safeguard scan --dir . keeps results local, and scanning from the signed-in interactive terminal uploads the SBOM and findings but, per the docs, never your source code.

Does a Safeguard SBOM meet the NTIA minimum elements?

Safeguard checks SBOMs against the seven NTIA data fields and the automation support requirements, and reports gaps per component. Whether a given SBOM passes depends on your inputs: missing supplier data for proprietary components or unpinned versions will show up as gaps you need to fix.

What does the CRA require in an SBOM?

Annex I Part II(1) requires manufacturers to identify and document components and vulnerabilities, including an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. The main obligations apply from 11 December 2027, according to the European Commission.

What changed in CISA's 2026 SBOM minimum elements?

The July 2026 document adds component hash, component license, SBOM author signature, SBOM tool name and version, SBOM format name and version, SBOM version and generation context, and updates several 2021 fields. It is guidance and does not create requirements on its own.

How often does Safeguard rescan an SBOM?

The docs describe a daily continuous scan of all projects plus optional On Push, Scheduled and On Release triggers. Uploaded SBOMs are also rescored when vulnerability feeds change, so a released version's findings stay current.

How do I compare two SBOM versions in Safeguard?

In Portal, open a product SBOM and click Compare Versions. The view lists added and removed components, version changes, and new and fixed vulnerabilities. A project's Timeline also shows the findings diff between consecutive scans.

Which SBOM format should I send to a customer?

Send CycloneDX JSON to a security team that will load it into tools, SPDX JSON to legal or procurement teams or when a contract names ISO/IEC 5962, and both when you are unsure. Add VEX statements for findings you have assessed as not affecting the product.

Does Safeguard create a hardware bill of materials?

No. Safeguard produces software bills of materials for code, packages and container images. Hardware and firmware you buy need a bill of materials from their manufacturer.

Is the Safeguard SBOM API available?

Not yet for these flows. Docs pages that show /v1 REST calls carry a banner that those endpoints return 404 today. Use the web app, the CLI, or the CI integrations.

An SBOM tells you which components carry a known vulnerability; it does not remove one. The block below covers how Safeguard turns a finding in the inventory into a fixed dependency, and the honest limits that come with each route.

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 demos below are recorded product sessions. None of them is an SBOM compliance walkthrough, but each shows a flow you would use in the steps above.

The first is a real CLI session: install, open the interactive terminal, ask it to fix a lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, edit package.json, run the install and tests with approval, print a summary and push nothing. It ends with /permissions, /model and /scan ., which is the same /scan . that generates and uploads an SBOM from your machine.

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

The second shows setting up the local runner on your own machine, approving it with its device code, and then scanning from the terminal. This is the route for teams that want SBOMs in the platform without granting Safeguard access to their repositories.

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

The third connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask an assistant which projects contain a component, or what changed in a project's findings, instead of clicking through the explorer. Safeguard is listed in the Claude connector directory as a community connector.

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

To try SBOM generation on your own code, download Safeguard and follow the Safeguard docs. For more on the formats and the CLI, see how Safeguard generates and imports SBOMs, CycloneDX and SPDX dual support, generating and reading an SBOM with the Safeguard CLI, enterprise SBOM management in ESSCM and supported file formats.

Quick check

Sources

• NTIA, The Minimum Elements For a Software Bill of Materials (SBOM), report PDF
• NTIA, Minimum Elements for a Software Bill of Materials, report page
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA, 2026 Minimum Elements PDF
• CISA, 2025 Minimum Elements draft for public comment
• CISA, Software Bill of Materials
• European Commission, Cyber Resilience Act
• BSI, Technical Guideline TR-03183
• CycloneDX, Specification Overview
• SPDX, Specifications
• Safeguard docs, Generate SBOM
• Safeguard docs, Explore SBOM
• Safeguard docs, EO 14028 Compliance Checks
• Safeguard docs, Software Composition Analysis
• Safeguard docs, Deep Dependency Scanning
• Safeguard docs, Continuous Scanning
• Safeguard docs, CLI Usage
• Safeguard docs, Safeguard CLI
• Safeguard docs, GitHub Actions
• Safeguard docs, EU Cyber Resilience Act framework
• Safeguard docs, Portal Find and Review SBOMs
• Safeguard docs, Portal Sharing
• Safeguard docs, Portal SBOM Repository
• Safeguard download page

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.