Ship an SBOM With Every Release When a Logistics RFP Demands One

When a shipper's or an agency's RFP asks for a software bill of materials, it is asking for one per release, not one per year. The workable answer for a logistics platform is to make the SBOM a build artifact: generate it in CI for every deliverable you ship (SaaS images, mobile apps, customer-hosted packages, edge agents), check it against CISA's 2026 minimum elements, attach exploitability statements, and publish it per version through a controlled channel. Done that way, it adds minutes to a release, not a quarter to your roadmap.

This post is for the VP of Engineering who owns the answer. Most of it works with any tooling; Safeguard comes in at "How Safeguard does this".

Key takeaways

• An RFP SBOM clause usually asks for three things: an SBOM per release in SPDX or CycloneDX, a way to receive it on request or on a schedule, and some promise about how you handle the vulnerabilities it reveals. Answer all three, not only the first.
• The current US baseline is CISA's 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026, which replaces the 2021 NTIA list. It adds fields such as SBOM Tool Name, SBOM Generation Context, Component License and Component Hash, and it says each software version or update should have an associated SBOM.
• OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Federal agencies may now write contract terms that require a current SBOM on request, and for a cloud platform, an SBOM of the runtime production environment. Commercial shippers copy that language.
• "Every release" means something different for SaaS, mobile, customer-hosted and edge software. Decide the unit per deliverable before you promise a frequency.
• A logistics platform usually has four or five deliverables. Each needs its own SBOM, tied to a version and an artifact hash.
• In Safeguard, the relevant capabilities are all GA: SBOM generation and analysis (GA), SCA and vulnerability management with EPSS and KEV (GA), the CLI and local runner (GA), policies and gates (GA) with Block, Warn and Notify actions, license compliance (GA), CSAF and VEX upload (GA), attestation and signing (GA), and Portal, the SBOM publish and share product (GA). Autonomous remediation (GA) ships switched off.
• Signing, legal review of the clause, and the decision on what to disclose stay with you.

The situation: the RFP landed and the SBOM question is in it

You run engineering at a logistics software company. The platform might be a transportation management system, a warehouse management system, a yard and dock scheduler, a visibility and tracking API, or all of them sold as one suite. Your customers are shippers, third-party logistics providers, carriers and, sometimes, government buyers that move freight.

A large prospect's security questionnaire or RFP arrives. Somewhere between the insurance requirements and the uptime SLA there is a clause that reads, in substance: provide an SBOM in an industry standard format for each release delivered under this agreement, keep it current, and tell us within a set window when a critical vulnerability affects a delivered release.

Procurement forwards the clause, but the real reader is the customer's security or third-party risk team. They want to load your SBOM into their tooling and answer one question fast when a widely used library has a bad week: are we exposed through this vendor?

What a bad week looks like for you:

• Sales needs the RFP answer in two weeks, and nobody can say how many deployable artifacts the company ships.
• The driver app, the handheld scanner app and the dock-door edge agent are built by different teams with different pipelines.
• The SaaS platform deploys many times a week, so "one SBOM per release" sounds like a promise to email a file every afternoon.
• Someone runs a scanner once and exports a file listing hundreds of untriaged vulnerabilities. Sending that to a prospect is worse than sending nothing.

The job is to give an answer that is true today, that engineering can keep true at release speed, and that does not hand a prospect an untriaged vulnerability list.

What the RFP is really asking for: the rules behind the clause

This section interprets public guidance. It is not legal advice, and your counsel should read the actual clause in your contract. What follows is the usual shape of the requirement, from primary sources.

EO 14028 started it

Executive Order 14028 (May 2021), Section 4(e)(vii), asked for guidance that includes "providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website." Two ideas from that line still drive RFP language: the SBOM is per product, and it can be delivered directly or published. Section 10(j) defines the SBOM as a formal record of the details and supply chain relationships of the components used in building software.

OMB M-26-05 changed the federal mechanism, not the expectation

OMB Memorandum M-26-05, dated 23 January 2026, rescinded M-22-18 and its companion M-23-16, which had driven the federal self-attestation process. The memo keeps the inventory duty: agencies "shall continue to maintain a complete inventory of software and hardware." It also says agencies may adopt contract terms that require a software producer to provide a current SBOM upon request. Footnote 1 adds the part that matters to SaaS logistics vendors: for a cloud platform, such a term should require an SBOM of the runtime production environment upon request.

For a logistics vendor that sells to agencies or to the contractors that serve them, the practical reading is that the SBOM obligation moved from a form into the contract. Commercial shippers tend to copy that contract language.

CISA's 2026 Minimum Elements set the content baseline

On 29 July 2026, CISA, with the NSA, the FBI and a long list of international partner agencies, published the 2026 Minimum Elements for a Software Bill of Materials (SBOM). CISA says it updates and replaces the 2021 NTIA minimum elements. If an RFP says "NTIA minimum elements", it is citing the older list; the 2026 list is the one to build to, and it is a superset in practice.

The 2026 document splits the elements into data fields and practices. Appendix A lists the data fields:

New in 2026 compared with 2021: SBOM Author Signature, Data Format Name and Version, Generation Context, Tool Name and Version, SBOM Version, Component Hash Algorithm and Value, and Component License.

The practices section is where "every release" comes from:

• Frequency. Each software version or update should have an associated SBOM. When a producer issues a new build or release, it should generate a new SBOM, including builds that only change dependencies, and issue a revised SBOM when it corrects an error.
• Coverage. The SBOM should include all components, including transitive dependencies, with no minimum depth. CISA's test is useful: a recipient should be able to conclude that a newly reported vulnerability does not affect them if the component is not listed.
• Explicitly Identifying Unknown Information. If a field is missing, say whether it is unknown or withheld. CISA notes that a recipient may treat an SBOM as incomplete if essential component data is withheld.

Distribution and Delivery says SBOMs should be available promptly to those who need them, through options such as accompanying the installation, a version specific URL, an API or a public repository. Machine-Processable Data names SPDX and CycloneDX as the two widely used formats and asks recipients to accept either.

CISA also flags SaaS directly. In its discussion section it says high frequency SaaS changes make delivery at every change hard for both sides, and that API based snapshots captured in CI and CD processes can help. That is the honest framing for a TMS that deploys daily.

NIST SSDF PS.3.2 is the engineering practice

NIST SP 800-218 (the Secure Software Development Framework) task PS.3.2 reads: "Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM])." Its examples include making that data available to acquirers in standards based formats, making it available to your own operations and response teams, and protecting its integrity. The SSDF mapping table ties PS.3.2 to EO 14028 Section 4e(vii).

PS.3.2 is the line to quote in an RFP answer, because it describes a process, not a file.

VEX is how you answer "what about the vulnerabilities?"

An SBOM lists components. A customer's tools will match those components against vulnerability feeds and find matches, many of which do not affect your product. CISA's Minimum Requirements for Vulnerability Exploitability eXchange (VEX), published 21 April 2023, describes the minimum elements of a VEX document, which states whether a product is affected by a given vulnerability. VEX can be expressed in CSAF 2.0 (an OASIS standard), in CycloneDX, or in OpenVEX.

If your RFP answer promises SBOMs without VEX, expect a follow up call for every scanner hit the customer sees.

Formats: SPDX and CycloneDX are both standards

SPDX is an international standard, ISO/IEC 5962:2021. CycloneDX is standardized by Ecma International as ECMA-424. Both are machine-processable, both are named in CISA's 2026 guidance, and both carry the fields above. Pick one as your default, and be able to produce the other when a customer insists.

Why logistics customers care

CISA's Transportation Systems Sector page lists seven subsectors, including Freight Rail, Maritime Transportation System, and Postal and Shipping. Those operators run on vendor software. When a common library is compromised, their question is which vendors carry it and in which release, and your SBOM answers it without a ticket.

How logistics platforms do this today, and where it breaks

Most logistics software companies already have pieces of the answer. The common patterns and their failure points:

The pattern behind most of these failures is the same: the SBOM is treated as a document someone produces, not an artifact the pipeline produces. Fix that and most of the rest follows.

Step by step: an SBOM for every release, with or without Safeguard

These steps work with any SBOM generator and any CI system. They assume you have a few weeks; the first four are what you can finish before the RFP answer is due.

1. List your deliverables, not your repos

A customer receives deliverables. Write them down, one row each, with the team that owns the pipeline. A typical logistics suite looks like this:

If a row has no owner, that is your first finding.

2. Decide what "every release" means for each deliverable

This is the decision that makes the promise keepable. A decision table you can adapt:

Write this table into your RFP answer. Customers accept a defined SaaS cadence far more readily than a vague "per release" that they later discover you could not meet.

3. Generate the SBOM in the pipeline that builds the artifact

Put SBOM generation in the CI job that produces the artifact, after the build, and store the SBOM next to the artifact with the same version and digest. Rules that keep it honest:

• Pin the generator version, so Tool Name and Tool Version are stable.
• Generate from the built image or package for anything you ship, so OS packages and bundled libraries appear; add source scans where they add dependency relationships.
• Include transitive dependencies and record the generation context ("before build" for source, "after build" for an image).
• Fail the job if SBOM generation fails. A release without its SBOM is incomplete.

4. Check field quality before you ship it

Run a validator against the spec, then check the 2026 fields that generators often leave blank: SBOM Author, Component Producer, Component Hash, Component License and Generation Context. Use this checklist on every release SBOM:

• Format is SPDX or CycloneDX, in a non deprecated version.
• SBOM Author, Timestamp, Tool Name, Tool Version and SBOM Version are set.
• Every component has a name, version and at least one identifier (PURL or CPE).
• Component Producer is set, or explicitly marked unknown.
• Component License is set with SPDX identifiers, or explicitly marked unknown.
• Component hashes are present for artifacts you can hash.
• Dependency relationships are present, including transitive ones.
• Missing data is marked unknown or withheld, never left silently empty.
• The SBOM names the artifact version and digest it describes.

5. Decide what blocks a release

An SBOM will surface known exploited vulnerabilities and license problems. Decide in advance which findings stop a release and which only warn. A reasonable starting policy for a logistics platform:

Every exception gets a written reason, an approver and an expiry. That record is what a customer's auditor will ask for.

6. Write VEX for the matches that do not affect you

For each scanner match on a shipped component, decide its status: not affected (with a justification such as vulnerable code not present), affected, fixed, or under investigation. Publish that as VEX alongside the SBOM. Start with critical and high matches on your most deployed deliverable.

7. Sign and store it

CISA's 2026 list includes SBOM Author Signature. Sign the SBOM with the key management you use for release artifacts, store it immutably with the artifact, and issue a new version for any correction.

8. Share it through a channel you control

Use a channel with per customer access, expiring links, a download log and revocation. CISA's Distribution and Delivery practice allows access controls that do not block authorized parties.

9. Diff releases, and tell customers what changed

Customers rarely read a full SBOM twice. With each release, give them the change: components added, removed or upgraded, and vulnerabilities fixed or new.

10. Keep watching shipped versions

An SBOM is a snapshot, but vulnerabilities keep being disclosed. Re-match every supported version against new advisories daily, and decide in your contract how fast you notify customers about a new critical issue in a delivered release.

A template paragraph for the RFP answer

Adapt this to what is actually true for you. Do not promise steps you have not built.

We generate a software bill of materials for every versioned release of each deliverable (mobile applications, customer-hosted packages and edge agents) in SPDX or CycloneDX format, built in the same pipeline as the release artifact and aligned with CISA's 2026 Minimum Elements. For our hosted platform, we generate an SBOM for every production deployment and provide a current runtime SBOM on request and on a monthly schedule. Each SBOM includes transitive dependencies, component identifiers, licenses and hashes where available, and marks unknown information explicitly. We publish VEX statements for vulnerabilities that do not affect our product, and we notify customers of critical vulnerabilities affecting a delivered release within the period set out in our agreement. SBOMs are shared through an access controlled portal with per recipient access and download logging. Our process follows NIST SP 800-218 practice PS.3.2.

Clause points worth negotiating

• Define "release" per deliverable, as in step 2.
• Name both SPDX and CycloneDX as acceptable formats.
• Allow delivery through a portal or URL, not only by email.
• Set the notification window from when you confirm a vulnerability affects a delivered release, not from public disclosure.
• Allow VEX statements as the response to scanner matches.
• Limit redistribution of SBOMs to the customer's security and risk functions.

Illustrative scenario: a TMS vendor answers its first per-release SBOM clause

This is a composite example built for this post, not a customer story. The company, its numbers and its timeline are invented, and every number below is an example input you can replace with your own.

Example Logistics Co. (fictional) sells a TMS as SaaS, a customer-hosted WMS edition shipped as container images, an Android driver app and an edge agent that runs on dock-door hardware. As example inputs: the SaaS deploys about 30 times a week, the driver app releases every two weeks, the customer-hosted edition ships monthly, and the edge agent ships quarterly.

A national retailer's distribution arm (also fictional) sends an RFP. Its SBOM clause asks for an SBOM per release in SPDX or CycloneDX, VEX for known vulnerabilities, and notice of critical issues within a set number of days. The answer is due in 15 business days.

Days 1 and 2. The VP of Engineering lists deliverables (step 1) and finds five, not two: the mobile team also ships a handheld scanner app to warehouse devices. Each gets an owner.

Days 3 to 5. Engineering agrees the release units (step 2): every tag for the four versioned deliverables, and a per deploy internal SBOM for the SaaS with a monthly snapshot plus on request delivery.

Days 4 to 8. Each pipeline gets an SBOM step (step 3) and a validation step (step 4). The edge agent SBOM has no license data for a vendored C library and no producer for two internal packages; the team marks them unknown rather than guessing.

Days 6 to 10. The AppSec lead sets the gate policy (step 5). As an example input, three critical matches block the customer-hosted edition. Two are in a base image package with a fixed version, and are upgraded. The third is in a library function the product does not call; it gets a not affected VEX statement and an exception with a 90 day expiry.

Days 9 to 15. The team sets up controlled sharing (step 8), writes the answer from the template describing only steps now live, and submits it.

The lesson is sequencing: deliverables first, release units second, pipeline third, sharing last.

How Safeguard does this

Safeguard covers most of the steps above on one platform: generation, quality checks, gates, VEX, publishing, sharing and monitoring. Deciding release units and signing stay with you. Each step below links to the docs page it is built from. Commands and YAML are copied from those pages; they were not run for this post.

1. Connect each deliverable as a project. In the web app, open Integrations from the sidebar and filter by Source Code (SCM), Container Image or Upload. SCM sources include GitHub, GitLab, Bitbucket and any Git URL; container sources include Amazon ECR, Docker Hub, GCP and any OCI registry; uploads include Android APK files and package manifests. For each repository you set the branch or tag, project name and version, which is auto-detected from git tags. For the suite above, the SaaS and customer-hosted images connect as container image projects and the scanner app as an APK upload. This is SBOM generation and analysis (GA) with SCA (GA) for full transitive inventory. (Generate SBOM)

2. Turn on the release trigger. Safeguard rescans every project daily for newly disclosed vulnerabilities. You can add three triggers: On Push, Scheduled, and On Release, which scans when a new tag is created. On Release maps to CISA's Frequency practice. (Generate SBOM)

3. Bring in SBOMs you already generate. If a pipeline already produces SPDX or CycloneDX, upload it through the Upload SBOM card instead of regenerating. The docs list CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3, in JSON, XML, tag-value and RDF where the format allows. After upload, Safeguard validates format and schema, checks required fields, and enriches each component with CVE matches, EPSS scores, CISA KEV status, license data and supplier data. (Existing SBOM integration)

4. Add the scan to CI. The GitHub Actions page gives this workflow, saved as .github/workflows/safeguard.yml, with a secret key created under Settings, Developer with the scopes scans:trigger and scans:read, stored in GitHub as SAFEGUARD_API_KEY:

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 docs say no checkout step is needed because Safeguard clones the repository. Branch wildcards such as release/** work, so release branches can be scanned on push. To fail the job on a policy gate rather than a severity, add --fail-on-gate all; to pin the CLI version, set SAFEGUARD_VERSION in env. (GitHub Actions)

5. Generate and check SBOMs locally when source cannot leave the building. The Safeguard CLI (GA) builds an SBOM for a directory, image, repository or existing SBOM, and validates SBOM and VEX documents against their specifications. These commands are from the CLI usage page:

# Build an SBOM for a local directory and write results under ./output
safeguard scan --dir .

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

# Validate an SBOM against its specification; --strict treats warnings as errors
safeguard validate sbom.json --strict -o report.json

# Validate a whole folder of release SBOMs
safeguard validate ./sboms --recursive

The docs are clear that safeguard scan does not fail on findings; gating happens through policy gates in the platform. Run from the interactive terminal while signed in (safeguard, then /login and /scan .), the local runner (GA) uploads the SBOM and findings to the platform and the source never leaves the machine. For a customer-hosted edition built in an isolated environment, that is the path. (CLI usage, Generate SBOM)

6. Review the inventory per release. Each project has tabs including Info, Attestation, Dependencies, Provenance, Vulnerabilities, Mitigations, Suppliers and Licenses, and Findings. The Info tab records the generation method (SCM, container or manual) and the branch or tag scanned. The Suppliers and Licenses tab covers license compliance (GA), and the Attestation and Provenance tabs come from attestation and signing (GA). Export the SBOM as SPDX (JSON, XML, RDF) or CycloneDX (JSON, XML), or as CSV, Excel or PDF for a human reader. (Explore SBOM)

7. Set the release gate. Under Settings, Policies, create a policy with the visual builder or YAML. Conditions include vulnerability severity, CVSS score, EPSS score, license, component age and maintenance status, and templates include No Critical Vulnerabilities, License Compliance, EO 14028 Compliance and No Abandoned Packages. Each policy has one Action: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Gates link policies, and safeguard ci scan --wait --fail-on-gate with a gate name fails the CI job when the gate fails. Approval for a legitimate exception runs through the exception workflow: request, justification, expiry date, approver decision and an audit trail. This is policies, gates and guardrails (GA). One practical note from the docs: policy outcomes are turned on per workspace by Safeguard, so ask for them to be enabled before you rely on the Outcome column. (Policies and gates, Policy outcomes and actions)

8. Record exploitability with VEX. Under Integrations, filter by Upload and connect the Upload CSAF/VEX card. The docs list CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. Upload VEX to mark vulnerabilities as not affected for a product, record mitigation status and track exploitability assessments; upload a supplier's CSAF advisory to track issues in components you receive. This is CSAF and VEX upload (GA). Reachability analysis (GA), part of the enrichment in step 3, helps you decide which matches deserve a not affected statement, but the statement is still a human decision. (CSAF/VEX upload)

9. Create the product and its versions in Portal. Here Portal means the SBOM publish and share product (GA), not the free entry tier. Under Portal, My Products, create a product with a name and SKU, then set visibility, auto-publish for new versions, and whether publishing requires approval. Add a version with its version number, release date, release notes and status (Pre-release, Current, Deprecated or End of Life), and associate the SBOM from the matching ESSCM project or upload one. Publishing moves through Draft, Review, Published and Archived, and publishing creates an immutable copy, so the SBOM a customer received stays the SBOM you can show later. (My Products, Portal)

10. Check the SBOM before publishing. Portal's Compliance tab validates each SBOM for minimum fields, component identifiers, supplier, version, dependency relationships and hash values, gives it a compliance score and shows a gap analysis. Reports include an EO 14028 compliance report, an NTIA minimum elements report and a full audit package, as PDF or Excel. The docs describe these checks against the NTIA elements, so check the 2026 additions (tool name and version, generation context, license, hash algorithm, author signature) with the checklist in step 4. (Portal compliance)

11. Share per customer, with expiry and revocation. Share directly with named recipients at View, Download or Full permission, or create a link with an expiration date, download limit and password. You can require authentication, restrict sharing to approved domains, require NDA acceptance per SBOM, and set up a branded customer portal under Settings, Customer Portal. Access can be revoked immediately, and tracking shows who accessed which SBOM and when. (Sharing)

12. Give customers the release diff. The SBOM Repository keeps versions per product and compares two versions to show added and removed components, version changes, and new and resolved vulnerabilities. That comparison is the release note a customer's risk team reads. (SBOM Repository)

13. Keep watching shipped versions. Continuous daily scanning re-matches every project against new disclosures, with vulnerability management (GA) enriching matches with EPSS and KEV. Gates re-evaluate when new assessment data arrives, and Notify policies alert your configured channels when a policy starts failing. That is the trigger for the customer notification your contract promises. (Generate SBOM, Policy outcomes and actions)

For the full picture of the job, see the matching use case page: know what's in your software.

What maps to what

What to measure

Use these as a checklist for your own program. They are things to track, not results anyone has promised.

• Share of deliverables with an SBOM step in their release pipeline.
• Share of tagged releases last quarter with an associated SBOM, and time from tag to shareable SBOM.
• Share of release SBOMs that pass validation with no errors.
• Share of components with Producer, License and Hash populated, and share marked unknown.
• Open gate exceptions, and how many are past expiry.
• Share of critical and high matches on shipped versions with a VEX status.
• Time from a new critical disclosure to a customer notice for affected releases.
• Customer access grants past their intended end date.

What Safeguard does not do

• It does not decide what "release" means in your contract. The release unit per deliverable, the SaaS cadence and the notification window are commercial and legal decisions.
• It does not sign your SBOM documents with your key or manage your release keys. CISA's SBOM Author Signature element needs your signing process and key management.
• It does not write your VEX judgements. It ingests and tracks CSAF and VEX documents and helps prioritize with reachability, but whether a vulnerability is not affected in your product is your engineering call, and you are accountable for it.
• Its compliance checks are documented against the NTIA elements. The Portal docs list checks for minimum fields, identifiers, supplier, version, dependencies and hashes. The newer 2026 fields still need your own check.
• It does not cover every packaging format the same way. The docs list Android APK uploads, container images, source repositories and existing SBOMs. For an iOS app or a proprietary edge installer, generate from source or supply an SBOM from your build, and mark anything you cannot see as unknown.
• It does not notify your customers or judge license obligations for you. Notify actions alert your own channels; the customer notice is yours, and whether a license applies to how you distribute the driver app is a question for counsel.
• Its REST API for Portal is not available yet. The Portal docs carry a banner that the /v1 endpoints return 404 today, so automate through CI and the CLI rather than the API.

Common mistakes

• Answering for the repo instead of the deliverable. The customer installs the image or the app, not the repository. Generate from what ships.
• Promising per deploy SBOM delivery for SaaS. It sounds generous and it is unkeepable. Commit to per deploy generation and on request plus scheduled delivery.
• Sending a scanner report as an SBOM. An inventory and a vulnerability list are different documents. Send the inventory and the VEX.
• Leaving fields blank instead of marking them unknown. CISA's 2026 guidance asks you to say whether data is unknown or withheld. Silence reads as carelessness.
• Overwriting a corrected SBOM. Issue a new SBOM Version and keep the old one.
• Blocking every release on every critical match from day one. Start with KEV and high EPSS on Block, the rest on Warn, and tighten each quarter.
• Forgetting the handheld and edge software. Warehouse scanner apps and dock-door agents sit on customer networks too.
• Writing the RFP answer before the process exists. Describe what runs today, and put the rest in a dated plan.

FAQ

Does an RFP SBOM clause mean an SBOM for every SaaS deploy?

It depends on the wording, so ask. CISA's 2026 guidance says each version or update should have an SBOM, and it also acknowledges that per change delivery is hard for SaaS. A common, defensible answer is to generate an SBOM for every deploy internally and deliver a current runtime SBOM on request and on a fixed schedule.

Which format should a logistics platform use, SPDX or CycloneDX?

Either. CISA names both as widely used and asks recipients to accept either. SPDX is ISO/IEC 5962:2021 and CycloneDX is ECMA-424. Pick one default, keep the format version current, and be able to export the other on request.

Are the NTIA minimum elements still the standard?

No. CISA's 2026 Minimum Elements, published 29 July 2026, update and replace the 2021 NTIA document.

Do we have to share our SBOM publicly?

No. EO 14028 described delivery either directly or on a public website, and CISA's Distribution and Delivery practice allows access controls as long as authorized parties can get the data. Most vendors share per customer through a controlled portal.

How do we stop customers from flooding us with tickets about scanner hits?

Publish VEX with the SBOM. A not affected statement with a justification answers the question before it is asked. CISA's VEX minimum requirements describe what a VEX document should contain.

What about the mobile driver app?

Treat each app store version as a release with its own SBOM. Generate it from the built app where your tooling supports that, and from source manifests otherwise, and record which you used in Generation Context.

Should the SBOM include the base image's OS packages?

Yes, for anything you ship as an image. CISA's Coverage practice asks for all components with no minimum depth, and base image packages are part of what the customer runs.

Who should own the SBOM program at a logistics software company?

Engineering owns generation and quality, security owns gate policy and VEX, legal owns the clause, and customer success owns delivery.

Safeguard cannot change what a customer's contract asks for, but the SBOM it generates for each release is also the list of components you will need to fix when a gate blocks a shipment. The section below covers the remediation options for the open source dependencies and container images in those release SBOMs.

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. For a customer-hosted WMS edition or an edge agent built in an isolated environment, this is how the release SBOM gets generated without the source leaving that machine.

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

The second demo is a real CLI session: safeguard is asked to fix the lodash CVE in a repository, reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. When a release gate blocks a tag because of a vulnerable dependency, the same flow produces the upgrade, and the next tag gets a clean SBOM.

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

The third demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. For a VP of Engineering, that means asking in plain language which deliverables have a failing release gate or an exception expiring this month while drafting the RFP answer, with access limited to the tools you allow.

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

Quick check

Sources

• CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA: 2026 Minimum Elements for an SBOM, full document (PDF, 29 July 2026)
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security (PDF, 23 January 2026)
• Executive Order 14028, Improving the Nation's Cybersecurity, 86 FR 26633 (GovInfo PDF)
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• NIST SP 800-218 full text (PDF), practice PS.3.2
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• CISA: Software Bill of Materials (SBOM)
• CISA: Transportation Systems Sector
• SPDX specifications
• CycloneDX specification overview
• Ecma International: ECMA-424, CycloneDX Bill of Materials Specification
• RFC 9557: Date and Time on the Internet, Timestamps with Additional Information
• Safeguard docs: Generate SBOM
• Safeguard docs: Explore SBOM
• Safeguard docs: Existing SBOM integration
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: Policies and gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: GitHub Actions
• Safeguard docs: CLI usage
• Safeguard docs: Portal
• Safeguard docs: Portal, My Products
• Safeguard docs: Portal, SBOM Repository
• Safeguard docs: Portal, Sharing
• Safeguard docs: Portal, Compliance
• Safeguard use case: Know what's in your software
• Safeguard Gold Open Source

Related reading: the CISA 2026 minimum elements update, CycloneDX vs SPDX, VEX statements that cut SBOM noise, an SBOM drift detection playbook, SBOM automation in CI/CD pipelines and using SBOMs to find affected products fast.

Try it yourself: download Safeguard or read the Safeguard docs.

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