SBOM and SCA in Regulated Delivery Projects: A Systems Integrator Guide

If you are a systems integrator building software for a bank, a health system or a government agency, write SBOM and software composition analysis (SCA) into the statement of work before mobilisation: who authors the SBOM, in which format, for which deliverables, how often, and who signs it. Then run SCA on every build in the environment the client allows, hold releases with a policy gate, and hand over an SBOM per release with a clear statement of what is known, unknown and not affected. The client's regulator holds the client accountable for you, so the client will ask, and the cheapest time to agree the answers is before the first sprint.

This guide is for the delivery lead, solution architect or engagement security lead at an integrator or consultancy. It covers the rules behind the ask, a clause checklist for the SOW, a release-by-release routine that works with any tooling, the awkward questions (whose tenant, whose signature, what about the commercial products you only configure), and then how Safeguard handles the same routine.

Key takeaways

• Under CISA's 2026 Minimum Elements, the SBOM Author and the Component Producer are separate fields. When an integrator builds the software, the integrator is usually both, and the client should see the integrator's legal name in both.
• Federal agencies, under OMB M-26-05, may put a "current SBOM upon request" term in contracts; for a cloud platform, the SBOM must cover the runtime production environment. Plan for it at bid time.
• Banking regulators expect the bank's due diligence to look at your SDLC, your vulnerability results and your subcontractors. NYDFS 23 NYCRR 500.11 and HIPAA 45 CFR 164.314 push similar duties into contracts.
• Agree SBOM format, depth, cadence, signature, delivery channel and vulnerability statement format in the SOW. Retrofitting them at user acceptance testing costs weeks.
• Keep each client in its own organization (or its own tenant), scan where the client's data rules allow, and never let one client's findings appear in another client's report.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV enrichment, reachability analysis, policies and gates, license compliance, CSAF and VEX upload, Portal (the SBOM publish and share product), the CLI and local runner, attestation and signing, autonomous remediation (ships switched off), Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

The situation

The trigger is usually a document, not an incident. A bank's third-party risk team sends a due diligence questionnaire with a section on secure development. A health system's procurement lead attaches a business associate agreement and a security schedule. A federal contracting officer adds a clause that the contractor shall provide a current SBOM on request. Sometimes it is the client's own CISO, two weeks before go-live, asking for "the SBOM" for an application your team has been building for nine months.

The people asking differ by sector, but they all want the same four things:

1. A list of what is inside the software you are delivering, down to transitive dependencies.
2. Evidence that you checked those components for known vulnerabilities and license problems, on each release, not once.
3. A position on each serious finding: fixed, not affected, accepted with a reason, or being worked on with a date.
4. Proof that the process will continue through hypercare and, if you keep the support contract, through the life of the system.

A bad week looks like this. The client asks for an SBOM on Monday. Your build pipeline has no SBOM step, so an engineer generates one from a laptop against whatever branch was checked out. It lists four hundred components, sixty with known vulnerabilities, and nobody has a view on any of them. The client's risk team reads the file, sees a critical CVE in a logging library, and blocks the release until you explain it. The explanation takes a week because the person who chose that library has rolled off the project. Meanwhile the commercial integration platform you configured for the client has its own SBOM question, and you do not know whether you are meant to answer it or the platform vendor is.

None of that is a tooling failure. It is a scoping failure. The SOW never said who authors the SBOM, for which deliverables, at what point in the lifecycle, or what "explain the findings" means.

The rules behind the ask

This section summarises the primary texts. It is not legal advice, and your contract wins over any general reading. Read the clause your client actually wrote.

Federal: OMB M-26-05 and CISA's 2026 Minimum Elements

OMB Memorandum M-26-05, dated 23 January 2026, rescinded M-22-18 and its companion M-23-16. It keeps two things that matter to an integrator. Agencies "shall continue to maintain a complete inventory of software and hardware", and agencies may choose contract terms that require a software producer to provide a current SBOM on request. A footnote adds that for a cloud platform, the contract should specify an SBOM of the runtime production environment. The memo also says agencies may still use the Secure Software Development Attestation Form, which means some agencies will keep asking for it and some will not. Read your task order.

The memo points readers to CISA's minimum elements. CISA published the final 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, jointly with the NSA, the FBI and international partners, and it replaces the NTIA 2021 minimum elements. Several of its changes land squarely on integrators:

• SBOM Author is "the name of the entity that creates the SBOM data for the target component", meaning the entity operating the tool, not the tool. The guidance says it is distinct from Component Producer, the entity that created the component. If your team builds the application and generates the SBOM, your firm is both. If you generate an SBOM for software someone else built, the fields differ.
• SBOM Author Signature is new: a digital signature attributable to the SBOM author, using an approved algorithm.
• SBOM Generation Context is new: whether the SBOM was produced before build, at build or after build. An SBOM from a source scan is "before build"; one from binary analysis is "after build".
• Coverage asks for all components including transitive dependencies, with no minimum depth. Linking to another SBOM (for example a subcontractor's) is acceptable if the recipient can reach the linked SBOM.
• Frequency asks for an SBOM per software version or update, including builds that only change a dependency, and a revised SBOM when you correct an error.
• Explicitly Identifying Unknown Information asks the author to say whether a missing field is unknown or withheld, and to have a process for recipients to ask about redacted security-related information.
• Machine-Processable Data names SPDX and CycloneDX as the two widely used formats.
• Distribution and Delivery drops the old standalone access control element; access controls may limit sharing with unauthorized parties but should not block authorized ones.

The full data field list adds Component Hash Value and Algorithm, Component License, SBOM Tool Name and Version, SBOM Version, SBOM Data Format Name and Version, and SBOM Timestamp to the familiar name, version, identifiers and dependency relationships.

Banking: the interagency third-party guidance and NYDFS

The Federal Reserve, FDIC and OCC issued the Interagency Guidance on Third-Party Relationships: Risk Management, final as of 6 June 2023 and published at 88 FR 37920. It speaks to the bank, not to you, but it describes what the bank's team will ask you for. Under due diligence on information security, it says that assessing a third party's application security program, including its software development life cycle and the results of its vulnerability and penetration tests, can give the bank useful information. Under contract negotiation, it discusses the right to audit and require remediation, including periodic independent audits of the third party and its relevant subcontractors. Under subcontracting, it suggests the bank address when you must notify it of subcontractors, whether specific subcontractors are prohibited, and reporting on subcontractor conformance.

For an integrator, that translates into three practical expectations: show your SDLC including SCA, show findings and how you closed them, and be ready to account for the offshore delivery centre or specialist subcontractor that wrote part of the code.

New York's 23 NYCRR 500.11 requires covered entities to keep written policies for third-party service providers covering risk assessment, minimum cybersecurity practices, due diligence and periodic assessment, with contract guidelines on access controls, encryption, incident notice and representations about the provider's cybersecurity policies. Expect a New York regulated client to put those representations into your contract.

Health: HIPAA business associates and FDA section 524B

If your delivery touches electronic protected health information, you are probably a business associate. 45 CFR 164.314(a) requires business associate contracts in which the business associate agrees, among other things, to ensure that any subcontractors that handle ePHI agree to the same requirements and to report security incidents. SBOMs are not named in the HIPAA Security Rule, but your client's security schedule will often ask for component inventories and vulnerability handling as evidence of reasonable safeguards.

If you build software that is part of a medical device that meets the "cyber device" definition, section 524B of the FD&C Act (21 U.S.C. 360n-2) applies to the device sponsor. It requires a plan to monitor and address postmarket vulnerabilities, processes for updates and patches, and "a software bill of materials, including commercial, open-source, and off-the-shelf software components". The sponsor carries the duty, but the sponsor will pass it to the integrator who wrote the code.

The practice baseline: NIST SP 800-218

Most client security schedules borrow language from the Secure Software Development Framework, NIST SP 800-218 version 1.1. Four tasks map directly to integrator work:

• PO.1.3 communicate security requirements to all third parties who provide commercial software components. If you use subcontractors, you are the one communicating.
• PS.3.2 collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM.
• PW.4.4 verify that acquired commercial, open source and other third-party components comply with requirements throughout their life cycles, including by building automatic detection of known vulnerabilities into the toolchain.
• RV.1.1 gather information from acquirers, users and public sources on potential vulnerabilities in the software and the third-party components it uses.

The European Union's Cyber Resilience Act adds SBOM duties for products with digital elements sold in the EU. For a US-led engagement it is context, not the driver.

Step by step: SBOM and SCA across a delivery engagement

The routine below works with any SCA tool and any SBOM generator. It follows the engagement lifecycle, because that is how integrators staff and bill.

1. At bid: price the obligation, do not discover it

Read the RFP and the draft master services agreement for SBOM, software composition, open source, third-party component, vulnerability and secure development language. Note every place the client references M-26-05, the CISA minimum elements, SSDF, 500.11 or a business associate agreement. If the RFP is silent, assume the client's third-party risk team will ask anyway and price a light version.

2. In the SOW: agree eight things in writing

Use this table as the clause checklist. The right column is the reason you can give the client's procurement lead.

Add one sentence on unknowns: the integrator will mark missing data as unknown or withheld rather than leave it blank. That single line saves an argument later.

3. At mobilisation: decide where scanning runs and whose account holds the data

This decision is about data, not tooling. The client may forbid source code leaving its network, forbid third-party AI processing of its code, or require that all security records live in its own systems. Write down:

• where builds run (client CI, integrator CI, or both);
• where SCA runs and where its results are stored;
• whether the scanning account belongs to the client (preferred for long-lived systems) or to the integrator (common for short projects, with a handover clause);
• who on your team, and on the client's, can see findings.

If you deliver to several clients from one practice, never share a project, a dashboard or a report template that pulls from more than one client's data. Separate accounts or separate organizations, with access granted per engagement, are the minimum.

4. In the build: SCA on every merge, a gate on every release

Put SCA in the pipeline on pull requests and on the main branch. Report on pull requests, enforce on release branches. A gate that blocks every pull request on day one teaches developers to bypass it. A gate that only reports teaches nobody anything. A common pattern on regulated projects:

• pull requests: report all, fail on new critical findings that have a fixed version;
• release branch: fail on any critical or high finding without a recorded position, fail on denied licenses;
• nightly: rescan the last released build against fresh vulnerability data, because a component that was clean on release day may not be clean today.

5. At release: produce the SBOM pack

For each release, the pack is small and repeatable:

1. The SBOM, in the agreed format, generated by the release pipeline, with author, producer, tool name and version, generation context, timestamp and SBOM version filled in.
2. A container SBOM for each shipped image, generated after build.
3. The vulnerability position: a VEX or CSAF document, or an exception register extract, for every finding at or above the agreed severity.
4. The license summary, with any copyleft components and their obligations called out.
5. A short note listing what is out of scope (configured commercial products, client-supplied libraries) and where their SBOMs come from.
6. The signature, applied by whoever the SOW names.

6. During hypercare: keep rescanning

The SBOM does not change after release, but the vulnerability picture does. Rescan the released SBOM against current data at least weekly in hypercare, and send the client a delta: new findings, changed severities, new KEV entries. If a fix is needed, it becomes a hotfix with its own SBOM.

7. At handover: move the evidence, not just the code

Hand over the SBOM history, the exception register, the policy configuration and the pipeline steps that produce them. If the scanning account was yours, export the records and either transfer the account or help the client rebuild it. If you keep the support contract, the routine continues unchanged.

A worked example (illustrative numbers)

The numbers below are invented to show the arithmetic. Replace them with your own.

An integrator delivers a loan origination portal to a regional bank: three deployable services and one shared library, two container images, releases every two weeks, plus an average of one hotfix a month. That is four SBOMs for code and two for images per release, about 26 releases and hotfixes a year, so roughly 156 SBOM documents a year. If producing, checking and explaining each SBOM by hand takes two hours, that is over 300 hours a year. If the pipeline produces them and a person only reviews the vulnerability position, review time is the only real cost. The point of the example is the ratio, not the hours: manual SBOM production does not scale past the first few releases, so automate generation and spend people on judgment.

Who is the SBOM author when an integrator builds the software?

For code your team writes, your firm is normally both the SBOM Author and the Component Producer in CISA's terms. Use your firm's full legal name, not the delivery centre's name or an acronym, since the guidance asks for full names.

It gets less clear in three cases:

• Joint teams. If client developers and your developers commit to the same repository, agree in the SOW who generates the SBOM. The author is whoever operates the tool for the release. The producer may be both parties; most SBOM formats allow more than one supplier or author entry, but keep it simple and agree one name.
• Subcontracted modules. If a subcontractor builds a module, either ask for their SBOM and link to it (CISA allows linking if the recipient can access the linked SBOM), or generate the SBOM yourself and record the subcontractor as the producer of those components.
• Configured products. If you configure a commercial platform but do not write its code, you are not its author or producer. Ask the vendor for its SBOM, or tell the client it must come from the vendor. Do not author an SBOM for someone else's product unless the SOW says you will, and then say how you produced it and that it is "after build".

Whose environment should scanning run in?

Choose based on the client's data rules, in this order:

1. If the client forbids source code leaving its network, run SCA inside the client's network, on the client's CI or on a machine the client provides, and send out only results if anything leaves at all.
2. If the client forbids any external processing of results, run everything on premises or in an isolated environment, and keep findings in the client's systems.
3. If neither restriction applies, a hosted service is simplest, with access limited to the engagement team and the client's security contacts.

Whatever you choose, write it into the security schedule. A bank's third-party risk team will ask "where does our code go" before it asks about vulnerabilities.

How do you keep client data separate across engagements?

Integrators often run one AppSec practice for many clients. That practice is efficient until a report for Client A lists a component path from Client B. Rules that prevent it:

• one account, tenant or organization per client, never a shared project;
• engagement-scoped access, removed at roll-off;
• reporting templates that are parameterised per client, never cross-client dashboards;
• no reuse of a client's SBOM, finding or exception as an example in another client's proposal;
• a roll-off checklist that covers scanning accounts, CI secrets and local result files on engineers' machines.

What about commercial products and platforms you configure?

Most regulated delivery projects include products you did not build: an integration platform, a content management system, a core banking module, a managed database. Treat them as third-party components of the system:

• list them in the system-level SBOM as components with the vendor as producer, if the client wants a system view;
• ask each vendor for its SBOM and vulnerability statements, and pass them to the client with a note that they came from the vendor;
• validate vendor SBOMs before you forward them, because a malformed file reflects on the person who handed it over;
• never claim to have scanned inside a product you only have binary or hosted access to, unless you actually did and you say how.

What do you do with findings the client will not fund?

This is the commercial question nobody puts in the RFP. A finding needs a position, and a position needs an owner:

• Fixed in the release: if the fix is a version bump within your scope, it is part of the work.
• Not affected: if the vulnerable function is not reachable or the component is not in the shipped artifact, record a VEX statement with the justification.
• Accepted: if the client accepts the risk, record who accepted it, why and until when. The acceptance belongs to the client, not to you.
• Change request: if fixing needs work outside scope (a framework upgrade, a vendor product upgrade), raise a change request with the finding attached.

Put the agreed severity thresholds in the SOW so that "fix before release" has a defined meaning.

Banks, health and government: what changes

How Safeguard does this

Everything below comes from Safeguard's offering files and docs.safeguard.sh. Where the docs do not show a screen or command, this section describes the outcome only. The commands were not run for this post; copy them from the docs pages linked in Sources and check them against safeguard --help in your build.

1. Set up one organization per client

Safeguard's hierarchy is Tenant, then Organization, then Project, then Version (the Organization and User Management docs page). An organization is described there as a logical grouping and an access boundary. For an integrator, the practical layout is one organization per client engagement, or a separate tenant when the client should own the account outright.

• Create organizations under Settings › Organizations.
• Invite engagement members under Settings › Members with a role: Tenant Admin, Manager, User or Viewer. The docs matrix shows Managers manage only their assigned organizations, and Viewers have read-only access.
• Use Settings › Teams to group people and assign organizations, and the project Access tab for project-level Admin, Write or Read permissions.
• With SSO configured, the docs show group mappings that assign roles and organizations from your identity provider groups, which makes roll-off a group change.

2. Scan where the client allows

The Safeguard CLI (GA) and local runner (GA) cover the "code cannot leave our network" case.

On a machine inside the client's environment, install the CLI as the docs show:

curl -fsSL https://cli.safeguard.sh/install | bash

Then scan the working copy:

safeguard scan --dir .

Per the CLI Usage page, safeguard scan builds an SBOM, matches it against vulnerability databases and writes JSON results (including vuln.json, license.json and collection.json) under ./output. It also accepts --image for a container image, --repo for a Git repository, and --sbom for an SBOM you already have. The docs are explicit that safeguard scan does not fail on findings: it exits 0 when the scan ran, and gating is done by policy gates in the platform.

To see results in the platform, the docs say to scan from the interactive terminal while signed in (safeguard, then /login, then /scan .). The runner then uploads the SBOM and findings, never the source. The Local Runner page adds that all traffic is outbound HTTPS the runner opens, and nothing connects to it. On a network that forbids held connections, safeguard runner start takes --poll-wait 0 to poll at a fixed interval.

3. Put SCA and a gate in the client's pipeline

SCA (GA) and vulnerability management (GA) run on every scan, with EPSS and CISA KEV enrichment. Reachability analysis (GA) ranks the findings your code actually calls ahead of the rest. For GitHub Actions, the docs give this workflow, after you create a secret key under Settings › Developer with the scopes scans:trigger and scans:read and store it 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

Two options on that page matter to integrators. By default Safeguard clones the repository itself; to scan on the CI runner instead, add a checkout step and --local. To fail on a policy gate rather than a severity, add --fail-on-gate all. Similar pages exist for GitLab, Azure Pipelines, Bitbucket Pipelines and Jenkins.

4. Write the SOW thresholds as policies

Policies and gates (GA) turn the SOW's severity and license thresholds into checks. Per the Policies and Gates page, you create a policy under Settings › Policies with the visual builder or YAML, using conditions such as vulnerability severity, CVSS score, EPSS score, license, component age and maintenance. Templates include No Critical Vulnerabilities, License Compliance and EO 14028 Compliance.

Each policy has one Action, and the Policy Outcomes page defines them: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Approvals run through exceptions. In CI, safeguard ci scan --wait --fail-on-gate exits non-zero when the gate fails, errors or was not evaluated before the timeout, so a pipeline never mistakes a missing evaluation for a pass. The docs note that policy outcomes are turned on per workspace by Safeguard, so ask your Safeguard contact if the Outcome column is missing.

License compliance (GA) classifies each component's license as permissive, weak copyleft, strong copyleft, network copyleft, commercial or unknown, and the docs show a discrepancy finding when package metadata and the license file disagree. That gives the release pack its license summary.

5. Check SBOMs you receive before you pass them on

For subcontractor and vendor SBOMs, the CLI validates and scans them:

safeguard validate sbom.json --strict -o report.json
safeguard scan --sbom sbom.json

The docs say validate checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications, and --strict treats warnings as errors. A failed validation is a finding in its own right, and it is better found by you than by the client.

6. Record vulnerability positions with CSAF and VEX

CSAF and VEX upload (GA) is listed among the upload integrations on the Generate SBOM page. Uploading the VEX or CSAF documents you write (or receive from a vendor) keeps the "not affected" and "fixed" positions next to the findings they explain, so the release pack and the client's view say the same thing.

7. Publish each release in Portal and share it with the client

Portal (GA), meaning the SBOM publish and share product rather than the free entry tier, is where release SBOMs go to the client.

1. Under Portal › My Products, create a product for the system you deliver, then add a version per release. The docs separate a Project (an internal scanning unit) from a Product (an external-facing catalog item).
2. On the version, associate the SBOM from the scanned project, or upload a CycloneDX or SPDX file.
3. Open the SBOM's Compliance tab for the EO 14028 gap analysis. The Portal Compliance page lists checks for minimum fields, unique identifiers, supplier information, version, dependencies and hash values. Its field list still follows the NTIA 2021 set, so check the 2026 additions (generation context, tool name and version, SBOM version, author signature) yourself.
4. Share it. The Sharing page lists direct sharing by email with View, Download or Full permission, shareable links with expiration, download limits, password protection and format restrictions, a branded customer portal, NDA acceptance per SBOM, access tracking, and immediate revocation. Organization-level settings can require authentication and restrict sharing to approved domains.

That covers CISA's Distribution and Delivery element with access controls that do not block the authorized client.

8. Match the deployment to the client's data rules

For clients that will not accept a hosted service or third-party AI, Safeguard offers Zero AI mode (GA), where the platform runs with no LLM in the loop; bring your own model (GA); and on-prem and air-gapped deployment (GA), including models that run inside the customer's environment. Safeguard's own posture: designed for FedRAMP High, with a SOC 2 Type II audit in progress. Your client's assessment of Safeguard is still the client's to make.

9. Attestation and remediation

Attestation and signing (GA) records provenance for builds and components, and SBOM generation and analysis (GA) exports SPDX and CycloneDX. Autonomous remediation (GA) can open fix pull requests for dependency upgrades; it ships switched off, with every category set to Manual, which suits a delivery team that must route every change through the client's change process.

Requirement, Safeguard, and what you still own

What Safeguard does not do

• It does not decide authorship or sign for you. Safeguard generates the SBOM and provides attestation tooling, but whether your firm is the SBOM Author, and who holds the signing key, is a contract decision.
• It does not see inside products you only configure. If you deliver a hosted platform or a vendor binary, the vendor's SBOM is the source. Safeguard can validate and scan an SBOM the vendor supplies; it cannot make up components it never saw.
• It does not judge exploitability on your behalf. Reachability ranks findings, and VEX upload records positions, but the "not affected" statement is yours and the client's to stand behind.
• It does not interpret your contract or your client's regulator. The policy templates help you encode thresholds; mapping them to a specific SOW, examiner request or task order is your work, ideally with the client's counsel.
• The Portal compliance check follows the 2021 field list. Gap analysis on the Compliance tab references NTIA minimum fields, so the CISA 2026 additions need a manual check.
• It does not remove the need for the vendor's fix. When the vulnerable code is in a vendor appliance or hosted service, the fix comes from that vendor.
• Policy outcomes are enabled per workspace. If the Outcome column is missing, ask Safeguard to turn it on before you promise gate evidence to a client.

Common mistakes

1. Generating the first SBOM at user acceptance testing. By then nobody remembers why a component is there. Generate from the first pipeline run.
2. One SBOM for the whole programme. Clients want one per deployable and per release. A single document for ten services is hard to diff and hard to trust.
3. Leaving fields blank. CISA asks for missing data to be marked unknown or withheld. A blank looks like carelessness.
4. Using the delivery centre's short name as the author. Use the full legal name of the contracting entity.
5. Gating pull requests too hard on day one. Developers route around a gate that fails every build. Report first, then enforce on release branches.
6. Sharing a scanning account across clients. It is the fastest way to leak one client's component list into another client's report.
7. Treating vendor SBOMs as your own. Pass them through with attribution, after validating them.
8. Stopping at go-live. New vulnerabilities appear after release. Rescan through hypercare and say who pays for it after.
9. Accepting risk on the client's behalf. Record the client's acceptance with a name and date. Do not write it yourself.

FAQ

Do systems integrators have to provide an SBOM to federal agencies?

Not by default. Under OMB M-26-05, agencies may choose contract terms that require a current SBOM on request, and for a cloud platform, an SBOM of the runtime production environment. If your task order includes the term, you must provide it. Plan for it either way, since many agencies will.

Who is the SBOM author when an integrator builds the software?

Under CISA's 2026 Minimum Elements, the SBOM Author is the entity that creates the SBOM data, and the Component Producer is the entity that created the component. For code you write and scan, your firm is usually both.

Does a bank's regulator require SBOMs from its vendors?

The interagency third-party guidance does not name SBOMs. It says due diligence can assess the third party's application security program, SDLC and vulnerability test results, and it discusses audit rights and subcontractors. Many banks now ask for SBOMs as part of that diligence.

What SBOM format should we use in a regulated delivery project?

SPDX or CycloneDX, in a version the client's tools accept. CISA names both as the widely used, machine-processable formats. Agree the format and version in the SOW.

How often should an integrator regenerate the SBOM?

Once per release and per hotfix, including builds that only change a dependency, and again whenever you correct an error. That is CISA's Frequency element.

Should SCA run in the client's environment or ours?

Wherever the client's data rules allow. If source code cannot leave the client's network, run the scan there and send out only results, or nothing at all.

What goes in an SBOM pack at handover?

The SBOM history per release, container SBOMs, vulnerability positions (VEX, CSAF or exception records), the license summary, the scope note for configured products, and the pipeline and policy configuration that produced them.

Do we need to provide SBOMs for commercial products we configured?

Usually not as author. Ask the vendor for its SBOM and pass it to the client with attribution. Write that split into the SOW.

Is a VEX document required?

No rule cited here requires one by name. A VEX or CSAF statement is the clearest way to tell a client that a listed vulnerability does not affect the delivered software, and why.

Does HIPAA require SBOMs from business associates?

The Security Rule does not name SBOMs. 45 CFR 164.314 requires business associate contracts with safeguards and subcontractor flow-down, and many health clients ask for component inventories as evidence.

Integrators carry a particular version of the waiting problem: the client will ask why a known vulnerability is still in a release you shipped, and "upstream has not fixed it yet" is not an answer a bank or an agency accepts for long. The options below are how a delivery team closes that gap inside its own scope, before a change request is even needed.

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. On a client engagement, that is the pattern for a client-provided machine inside the client's network: the runner sends out results, and the source stays where it is.

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

The second demo is a real CLI session. A developer asks the CLI to fix the lodash CVE in a repository; it reads the finding and the 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. That approval step is what a delivery team needs when every change goes through the client's change process.

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 chooses which tools Claude can use. For an engagement lead, that is a way to ask questions of one client's findings from an assistant the client has already approved, within the tool permissions you set. Safeguard is listed in the Claude connector directory as a community connector.

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

Quick check

Sources

• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security (PDF)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA, 2026 Minimum Elements for an SBOM (PDF)
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920
• OCC Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management
• 23 NYCRR 500.11, Third-party service provider security policy
• 45 CFR 164.314, Organizational requirements
• 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (FD&C Act section 524B)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (PDF)
• CycloneDX specification overview
• SPDX specification 3.0.1
• OASIS CSAF version 2.0
• CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• Safeguard docs: Organization and User Management
• Safeguard docs: CLI Usage
• Safeguard docs: Local Runner
• Safeguard docs: GitHub Actions
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: License Compliance
• Safeguard docs: Generate SBOM
• Safeguard docs: Portal My Products
• Safeguard docs: Portal Compliance
• Safeguard docs: Portal Sharing

Related reading: how software vendors deliver SBOMs at scale, a security consultant's toolkit for client work, federal software procurement SBOM requirements, a vendor SBOM ingest program blueprint and why systems integrators are becoming central to AppSec rollouts.

Get the CLI and the apps at safeguard.sh/download, and read the full documentation at docs.safeguard.sh.

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