US Software Supply Chain and AI Security Rules: A 90-Day Plan

The United States has no single federal law that tells every software company to produce an SBOM or follow a secure development framework. The pressure comes instead from contracts and sector rules: defense contracts and CMMC, the SEC's incident disclosure rule, New York's Part 500, PCI DSS, the FDA's cyber device law, California's new cybersecurity audit rules and a growing set of state AI laws. Most US software teams feel it as a customer question long before a regulator ever asks.

This guide maps those rules regulator by regulator, with the status we checked on each primary source on 25 October 2026, then turns them into one 30/60/90-day plan that works whether or not you use Safeguard. It is written for the people who actually get the letter, the questionnaire or the board question: the CISO, the head of AppSec, the VP of Engineering, the GRC lead and the vendor risk owner. It is not legal advice; where we interpret a rule, check the primary text with your counsel.

Key takeaways

• Federal civilian buyers moved from a mandate to risk-based choice. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Agencies no longer have to collect the secure software attestation form, but they may still use it and may write contracts that require an SBOM on request.
• Federal vulnerability timelines changed. CISA BOD 26-04 (10 June 2026) revoked BOD 22-01 and BOD 19-02 and replaced fixed deadlines with risk-based ones built on four factors. The full remediation timelines apply from 180 days after issuance, which falls on 7 December 2026.
• Defense work now carries CMMC in the contract. The CMMC program rule (32 CFR part 170) took effect 16 December 2024, and the DFARS rule that puts CMMC into contracts took effect 10 November 2025. The phase-in steps up again in November 2026.
• Public companies, New York financial firms and card processors already have clocks running. SEC Form 8-K Item 1.05 (four business days after a materiality determination), NYDFS Part 500 (72 hours to notify, fully phased in since 1 November 2025) and PCI DSS v4.0.1 requirement 6.3.2 (software component inventory, mandatory since 31 March 2025).
• Medical device makers need an SBOM in the premarket file under section 524B of the FD&C Act.
• States are moving on audits and AI. California's cybersecurity audit regulations took effect 1 January 2026. Colorado repealed and re-enacted its AI Act in May 2026 as an automated decision-making technology law, with key duties from 1 January 2027.
• AI governance is framework-led. The NIST AI RMF is voluntary, but buyers use it as the yardstick.
• Safeguard capabilities covered in this post, all GA: SBOM generation and analysis, SCA and deep dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the compliance and GRC suite, TPRM SBOM requests, Trust Center, AI-BOM discovery, AI agent discovery, MCP Guardrail, AI Gateway, autonomous remediation (ships switched off), the CLI and local runner, Package Firewall, and private VPC, on-prem, air-gapped and Zero AI deployment.

Who this applies to in the United States

US software security obligations follow the money and the sector. A company can be outside every regulation on this page and still be asked for all of it by a customer that is inside one. That is the commercial forcing function: there is no horizontal SBOM law, so buyers ask because their own supervisors, contracts or boards ask them.

Federal banking regulators, the NCUA, HHS and the FTC also shape vendor risk expectations, mostly through the regulated firm's third-party risk program. That is why your customer's vendor risk owner often asks the same questions as NYDFS.

The rules, regulator by regulator

NIST SP 800-218 (SSDF): still the shared vocabulary

NIST SP 800-218, the Secure Software Development Framework version 1.1, was published in February 2022. It groups practices into four families: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). The practices auditors and customers ask about most in a supply chain review are:

• PS.3.2: collect, safeguard, maintain and share provenance data for all components of each software release, for example in an SBOM.
• PW.4.1 and PW.4.4: acquire and maintain well-secured third-party components, and verify that acquired components are what they claim to be and remain well-secured through their lifecycle.
• RV.1.1: gather information from software acquirers, users and public sources on potential vulnerabilities in the software and its third-party components.
• RV.2 and RV.3: assess, prioritise and remediate vulnerabilities, then analyse root causes.

NIST published an initial public draft of SP 800-218 Revision 1 (SSDF version 1.2) on 17 December 2025. The comment period closed on 30 January 2026. As of today the final version 1.2 is not published, so version 1.1 is the current final text. Plan against 1.1 and watch for 1.2.

OMB M-26-05 and the secure software attestation form

From 2022 to early 2026, OMB M-22-18 and M-23-16 required federal agencies to collect a self-attestation from software producers that they follow specific SSDF practices. CISA released the common Secure Software Development Attestation Form on 11 March 2024, with an online Repository for Software Attestations and Artifacts.

On 23 January 2026, OMB Director Russell Vought signed M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security." It rescinds M-22-18 and M-23-16. The memo says the earlier policy "prioritized compliance over genuine security investments." CISA's attestation form page is now marked as archived content.

What M-26-05 keeps matters more for suppliers than what it removes:

• Agencies must continue to maintain a complete inventory of software and hardware.
• Agencies must develop software and hardware assurance policies that match their own risk determinations and mission needs.
• Agencies may still choose to use the attestation form and other resources built under M-22-18.
• Agencies may adopt contract terms that require a software producer to provide a current SBOM on request. For a cloud platform, the memo says the term should cover an SBOM of the runtime production environment.
• The memo points agencies to NIST SP 800-218, CISA's SBOM minimum elements and CISA's hardware bill of materials framework.

So the federal ask did not disappear. It moved from one form into each agency's own contracts and risk reviews. A supplier that can produce SSDF evidence and an SBOM on request is ready either way.

CISA's 2026 Minimum Elements for an SBOM

On 29 July 2026, CISA, NSA, the FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials. It updates and replaces the minimum elements the NTIA published in 2021, after a public comment period in 2025. CISA notes that some software types, such as AI and software as a service in cloud environments, may need additional elements beyond the baseline. If your SBOM program was built on the 2021 NTIA list, re-check your fields against the 2026 document; this is the reference federal buyers and many commercial buyers now cite.

CISA BOD 26-04: risk-based patch timelines for federal agencies

Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," was issued on 10 June 2026. It supersedes and revokes BOD 19-02 (2019) and BOD 22-01 (2021). The Known Exploited Vulnerabilities (KEV) catalog stays, and the criteria for adding a CVE to it are unchanged.

The urgency of a fix now depends on four questions:

1. Asset exposure: is the vulnerable asset publicly exposed?
2. KEV status: is the CVE in CISA's KEV catalog?
3. Exploit automation: can an adversary automate every step of the exploit?
4. Technical impact: does exploitation give partial or total control of the asset?

CISA publishes answers to the last three for every CVE through its Vulnrichment program. The directive's Table 1 maps the combinations to remediation timelines, and the most urgent combination requires remediation within three days plus a forensic triage of the asset. Agencies had to update policies immediately (Phase I), update processes within 60 days (Phase II) and meet the Table 1 timelines within 180 days (Phase III), which is 7 December 2026.

The directive binds federal civilian agencies. It reaches contractors only through their contracts, which agencies must review, and FedRAMP cloud offerings through the FedRAMP program office. Many private sector teams adopt the four-factor model anyway because it is a defensible way to rank fixes.

FAR and DFARS: the contract clauses that carry the rules

For defense work, DFARS 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting," requires contractors to protect covered defense information with the security requirements of NIST SP 800-171 and to report cyber incidents to DoD within 72 hours of discovery. Subcontractors handling covered defense information inherit the clause.

The DFARS CMMC rule (DFARS Case 2019-D041, 90 FR 43560), published 10 September 2025 and effective 10 November 2025, adds the contract clauses that make a CMMC status a condition of award where the solicitation requires it.

Civilian FAR clauses also matter to software suppliers, but several FAR changes were in motion during 2025 and 2026. Check the specific clauses in your own contracts rather than relying on a general summary.

CMMC 2.0: the phase-in is under way

The CMMC program rule, 32 CFR part 170 (89 FR 83092), took effect on 16 December 2024. It sets three levels: Level 1 for Federal Contract Information, Level 2 aligned to the 110 requirements of NIST SP 800-171 Revision 2 for Controlled Unclassified Information, and Level 3 adding selected NIST SP 800-172 requirements. Depending on the contract, a Level 2 status is reached by self-assessment or by an assessment from a certified third-party assessment organisation.

Section 170.3(e) phases CMMC into contracts in four steps, each one calendar year after the last. Phase 1 began when the DFARS rule took effect on 10 November 2025, mainly with self-assessments. Phase 2 starts on 10 November 2026 and brings Level 2 assessments by certified third-party assessors into applicable contracts. Phase 3 follows in November 2027 and full implementation in November 2028. If you sell into the defense supply chain, Phase 2 is the date your prime is planning around now.

SEC cybersecurity disclosure: Form 8-K Item 1.05 and Regulation S-K Item 106

The SEC adopted its cybersecurity disclosure rules in July 2023. Under Form 8-K Item 1.05, a public company must disclose a material cybersecurity incident generally within four business days after it determines the incident is material. Disclosure can be delayed only if the US Attorney General determines that immediate disclosure poses a substantial risk to national security or public safety and tells the SEC in writing. Most companies have had to comply with the 8-K requirement since 18 December 2023; smaller reporting companies had an extra 180 days.

Regulation S-K Item 106 requires an annual description in Form 10-K of the company's processes for assessing, identifying and managing material cybersecurity risks, including risks from third-party service providers, and of board oversight and management's role. It applies to annual reports for fiscal years ending on or after 15 December 2023.

Status today: both items remain in the SEC's rules. In comments on the SEC's review of Regulation S-K, banking and securities trade groups led by SIFMA urged the Commission to rescind Item 106 and addressed the Item 1.05 mandate too. Treat both as in force and watch for rulemaking.

For software teams the link is simple: a materiality determination needs facts fast, such as which products contain the affected component and whether the vulnerable code is exposed.

NYDFS 23 NYCRR Part 500

New York's Department of Financial Services issued Part 500 in 2017 and amended it on 1 November 2023. The amendments phased in over two years, and the final phase took effect on 1 November 2025, which brought in the expanded multi-factor authentication requirement in section 500.12 and the asset inventory requirement in section 500.13(a). Sections that matter for software and suppliers:

• 500.8 Application security: written procedures for secure development of in-house applications and for evaluating and testing the security of externally developed applications.
• 500.11 Third-party service provider security policy: written policies for assessing, contracting with and periodically reviewing service providers.
• 500.13(a) Asset inventory: a complete, accurate and documented inventory of information systems, with owner, location, classification, support expiration date and recovery time objectives tracked.
• 500.17(a) Notice: notify the superintendent within 72 hours of determining that a cybersecurity incident has occurred.
• 500.17(b) Annual filing: by 15 April each year, a certification of material compliance or an acknowledgment of non-compliance.
• 500.17(c) Extortion payments: notice within 24 hours of a ransom payment and a written explanation within 30 days.

PCI DSS v4.0.1 requirement 6.3.2

PCI DSS v4.0.1 is a limited revision of v4.0 from the PCI Security Standards Council. It clarified wording but added or removed no requirements. Requirement 6.3.2 requires an inventory of bespoke and custom software, and of the third-party software components incorporated into it, to support vulnerability and patch management. It was a best practice until 31 March 2025 and has been mandatory since. Related requirements are 6.3.1 (identify vulnerabilities from industry sources), 6.3.3 (install critical patches within one month of release), 6.4.3 (manage scripts on payment pages) and 12.8 (manage third-party service providers).

PCI DSS does not use the word SBOM as a mandate, but an SBOM per release is the most practical way to keep the 6.3.2 inventory current.

FDA section 524B: cyber devices

Section 524B of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360n-2) was added by section 3305 of Public Law 117-328, enacted on 29 December 2022, and took effect 90 days later, on 29 March 2023. A cyber device includes software, can connect to the internet and has characteristics that could be vulnerable to cybersecurity threats. The sponsor must:

• 524B(b)(1): submit a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure.
• 524B(b)(2): design, develop and maintain processes that give reasonable assurance the device and related systems are cybersecure, and make postmarket updates and patches available on a reasonably justified regular cycle, and out of cycle as soon as possible for critical vulnerabilities.
• 524B(b)(3): provide a software bill of materials, including commercial, open source and off-the-shelf software components.

The same law requires FDA to keep its premarket cybersecurity guidance updated, so check FDA's guidance page for the current final version before a submission.

California: CCPA cybersecurity audit regulations

On 24 July 2025 the California Privacy Protection Agency Board adopted regulations that require certain businesses to complete annual cybersecurity audits and risk assessments, and that set rules for automated decision-making technology. The Office of Administrative Law approved them on 22 September 2025 and they took effect on 1 January 2026. The audit duty applies to businesses whose processing presents significant risk to consumers' security. Read the approved text on the CPPA page for the thresholds and the dates your first certification is due.

Colorado: from the AI Act to an automated decision-making law

Colorado's SB24-205, signed on 17 May 2024, was the first broad state law on high-risk AI systems. Before its main duties took effect, on 14 May 2026 Colorado enacted SB26-189, "Automated Decision-Making Technology," which repeals and re-enacts those provisions with requirements for automated decision-making technology used in consequential decisions. Developer documentation duties begin on 1 January 2027, the Attorney General must adopt rules on post-adverse-outcome disclosures by the same date, and until 1 January 2030 the Attorney General must give 60 days' notice and a chance to cure before enforcement.

Other states have AI, privacy and automated decision laws at various stages. Track the ones where your customers' end users live.

NIST AI RMF and federal AI policy

The NIST AI Risk Management Framework 1.0 is voluntary. Its four functions are Govern, Map, Measure and Manage. On 26 July 2024 NIST added NIST AI 600-1, the Generative AI Profile, which lists risks specific to generative AI and suggested actions. On 7 April 2026 NIST released a concept note for an AI RMF profile on trustworthy AI in critical infrastructure.

Federal security directives now cite AI directly: BOD 26-04 says adversaries' use of AI may shorten the time between a patch and exploitation. There is no single federal AI statute, so for a supplier AI governance arrives through buyer questionnaires and contracts that point to the AI RMF.

What the rules ask of software and open source

Reading the regimes side by side, the same seven asks keep coming back. The table maps each to the evidence a supervisor, assessor or customer usually asks to see.

Nearly every regime needs a component inventory first, and each wants evidence that the process runs continuously. An SBOM from last spring does not answer a PCI assessor or an agency asking for "a current SBOM."

Real public incidents affecting the United States

These are recent, publicly documented software supply chain incidents that US agencies responded to. We describe only what the primary sources say.

The point for US rules is not a lesson about any victim. Questions such as "which of our products contain this component and version" had to be answered within days, and the answers depended on inventories that already existed.

The personas who own the problem

CISO

The CISO owns the SEC clock and the board narrative. They need to go from "a widely used component is compromised" to "here is our exposure and why it is or is not material" within a day or two, and they approve the NYDFS annual filing. The trigger is an incident, a board meeting or a customer escalation.

Head of AppSec or Product Security

AppSec owns the SSDF evidence and the backlog. For BOD 26-04 style ranking and PCI DSS 6.3.3 one-month patching, they need a list ranked by KEV, exploitability and exposure, not a raw CVE count. The trigger is a customer review, a PCI assessment or a new KEV entry.

VP or Director of Engineering

Engineering owns the work: SBOMs per release and current dependencies, without slowing releases. They want one pipeline step that produces the SBOM, runs the checks and blocks only on what matters. The trigger is usually a large customer's questionnaire or RFP.

GRC and regulatory affairs

GRC owns the mapping: which NYDFS section, which PCI requirement, which SSDF practice, which CMMC practice, and where the evidence lives. They need evidence that is dated, repeatable and ready for an assessor. Triggers are the 15 April NYDFS filing, the annual PCI assessment, a CMMC assessment window and the California audit certification. For medical device makers, regulatory affairs owns the 524B premarket file.

Procurement and vendor risk

The vendor risk owner asks suppliers for SBOMs and evidence, and answers customers who ask the same of you, whether under M-26-05 contract terms, NYDFS 500.11 or SEC Item 106. The trigger is a renewal, a new supplier or a supplier incident.

AI governance lead or CTO

Whoever owns AI adoption needs an inventory of models, AI services, agents and MCP servers, plus the documentation Colorado and California expect where AI drives consequential decisions. The trigger is a new AI feature, a customer questionnaire citing the NIST AI RMF, or the January 2027 Colorado date.

A practical 30/60/90-day plan

This plan works with any toolset. Swap in your own owners and tools.

Days 1 to 30: know what you have and which rules apply

1. Scope the regimes. Use the "Who this applies to" table to list each regime that applies to you directly and each that applies through a customer. Write down the trigger date for each: next PCI assessment, 15 April NYDFS filing, CMMC phase dates in your contracts, any 524B submission, any state AI duty.
2. Build the inventory. Generate an SBOM for every product release and every production container image, in SPDX or CycloneDX. Include transitive dependencies. Store each SBOM with the release it describes.
3. Check SBOM fields against the 2026 CISA minimum elements. Fix gaps in supplier names, versions, unique identifiers such as package URLs, and generation data.
4. List suppliers. Build a vendor inventory with what each vendor supplies, what data it touches and whether you have its SBOM or security evidence.
5. Name owners. Assign one owner per regime and one owner for the shared inventory.
6. Write the incident fact sheet. A one-page runbook that answers: where are SBOMs stored, who can query "which products contain component X at version Y," and who feeds the CISO and counsel for an SEC materiality call, a 72-hour NYDFS notice or a DFARS 7012 report.

Days 31 to 60: rank, fix and gate

1. Adopt a risk model. Rank vulnerabilities with the four BOD 26-04 factors (exposure, KEV, exploit automation, technical impact) plus whether your code actually reaches the vulnerable function.
2. Set timelines. Write your own remediation targets. If you sell to agencies or handle cards, keep them no slower than BOD 26-04 Table 1 and PCI DSS 6.3.3.
3. Burn down the top of the list. Fix KEV-listed, exposed, reachable issues first. Record each fix with a date and a link to the change.
4. Add a pipeline gate. Block releases that add a new KEV-listed critical vulnerability or a forbidden license; warn on the rest. Route exceptions to a named approver with an expiry date.
5. Request supplier SBOMs. Start with suppliers whose software sits in your regulated scope.
6. Map evidence to controls. For each regime, list the control, the evidence you have and where it lives. Mark gaps.

Days 61 to 90: prove it and keep it running

1. Run a tabletop. Replay the XZ Utils backdoor and time how long it takes to list affected products, decide materiality and draft notices.
2. Package the evidence. Assemble an SSDF evidence pack (practices, owners, artifacts), a PCI 6.3.2 inventory sample, a NYDFS 500.13 inventory extract and a CMMC self-assessment where relevant.
3. Publish what customers ask for. A trust page with your SBOM policy, disclosure policy and audit status answers many questionnaires.
4. Inventory AI. List models, AI SDKs, AI services, agents and MCP servers in use; mark any used in consequential decisions for Colorado and California purposes; map controls to the NIST AI RMF functions.
5. Schedule the cadence. SBOMs per release, vulnerability review weekly, supplier review quarterly, evidence refresh before each filing or assessment.

Decision table: what to do first

How Safeguard does this

Everything below is generally available (GA) today and is described from Safeguard's offering documentation and docs.safeguard.sh. Where the docs do not show a screen or command, we describe the outcome instead.

1. Inventory every product and image. In the web app, Integrations connects GitHub, GitLab, Bitbucket and generic Git repositories, container registries and Hugging Face models, and accepts uploaded manifests and CSAF or VEX files. SBOM generation and analysis (GA) produces SPDX and CycloneDX, with continuous scanning on push, on a schedule or on release. SCA and deep dependency scanning (GA) cover transitive dependencies and container layers.

2. Scan where the code lives, if it cannot leave. The Safeguard CLI (GA) scans one target at a time and writes JSON results locally:

   safeguard login
   safeguard scan --dir .
   safeguard scan --image myregistry.azurecr.io/myapp:v1
   safeguard scan --sbom sbom.json
   

   Results such as vuln.json and license.json land in a folder per scan under ./output by default. The local runner (GA) runs scans on your own machine: source code never leaves it, and only encrypted results are sent back. We did not run these commands for this post; they are as the CLI usage docs show them.

3. Rank by real risk. Vulnerability management (GA) matches components against vulnerability sources and enriches findings with EPSS and CISA KEV status. Reachability analysis (GA) shows whether your code calls the vulnerable path, which helps you apply a BOD 26-04 style model on top of exposure and KEV.

4. Gate releases. Policies, gates and guardrails (GA) evaluate scans of connected repositories at CI and release. Gate actions are Block, Warn and Notify, and approvals run through exceptions with named approvers. You can also create policies from plain English prompts.

5. Map evidence to US frameworks. The compliance and GRC suite (GA) includes framework pages for NIST SSDF, NIST SP 800-161, NY DFS 23 NYCRR 500, CCPA and CPRA, FDA medical devices, PCI DSS 4.0, CMMC and FedRAMP. Each is on in your workspace unless you switch it off in Compliance › Manage. Each scan of a product checks that framework's scan requirements against what the scan found, including the SBOM; for example the SSDF page checks provenance data for PS.3.2 and exact component versions for RV.1.1, and the PCI page checks the 6.3.2 inventory. Controls can be evidenced with automated tests, uploaded evidence, policies or an attestation, and each framework comes with policy templates.

6. Collect supplier SBOMs. TPRM (GA) sends SBOM requests to one vendor or many, tracks status from Sent to Validated, sends reminders and validates format and completeness when the SBOM arrives, then scans it automatically. This supports NYDFS 500.11 reviews and federal SBOM-on-request terms you pass down to your own suppliers.

7. Answer customers once. Trust Center (GA) publishes a public page at your own slug on trust.safeguard.sh, managed from Compliance › Trust Center, showing the frameworks you choose, live control status, policies, subprocessors and documents. Nothing goes live until you publish it.

8. Inventory AI. AI-BOM discovery (GA) finds AI SDK imports, model files, prompts, notebooks, MCP server configuration, managed inference endpoints and shadow AI services, and assembles them into an AI-BOM. AI agent discovery (GA), MCP Guardrail (GA) and the AI Gateway (GA) add visibility and runtime controls for agents and model traffic, which supports NIST AI RMF Map and Manage work and the inventories Colorado and California rules imply.

9. Stop bad packages at install. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious and dependency-confusion packages before they reach a build.

10. Fix with pull requests. Autonomous remediation (GA) lets Griffin open tested fix pull requests, single or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.

11. Keep data where your rules need it. SaaS runs in US, EU and Gov regions. For stricter requirements, Safeguard runs in a private VPC or dedicated tenancy, fully on-prem, or fully air-gapped with its AI models inside your environment and signed offline updates. Zero AI mode runs the platform with no LLM in the loop. On posture, Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not make you compliant or certified. Safeguard helps you produce and keep the evidence that NYDFS, PCI DSS, CMMC, the FDA or a federal buyer asks for. Assessors, QSAs, C3PAOs and regulators decide.
• It does not decide materiality or file notices. The SEC four-business-day clock, the NYDFS 72-hour notice and the DFARS 72-hour report are your company's decisions and filings.
• It does not sign attestations for you. If an agency still uses the secure software attestation form, an officer of your company signs it.
• It does not cover controls outside software. MFA rollout under 500.12, physical security, HR screening for CMMC and most CUI handling controls are outside what a scan decides.
• It does not patch vendor appliances or hosted services. When the vulnerable code sits in a product you do not build, the fix comes from that vendor.
• It does not write your AI impact assessments. It inventories AI assets; the assessment of whether a decision is consequential, and the consumer notices, stay with you and counsel.
• It does not offer an in-country region outside the US, EU and Gov SaaS regions. For any other residency need the answer is private VPC, on-prem, air-gapped or the local runner.

Common mistakes

• Treating M-26-05 as "no more SBOMs." It removed a single mandatory form. It kept inventories and allowed SBOM-on-request contract terms.
• Still quoting BOD 22-01 deadlines. It is revoked. Use BOD 26-04's risk-based model.
• Using the 2021 NTIA minimum elements as the current baseline. CISA's 2026 minimum elements replaced them in July 2026.
• Producing one SBOM a year. PCI 6.3.2, M-26-05 and the FDA all expect a current inventory. Generate per release.
• Counting CVEs instead of ranking them. A backlog sorted by CVSS alone misses KEV status, exposure and reachability.
• Waiting for the CMMC clause to appear in a contract. Assessments take months to schedule and prepare; primes are asking now.
• Leaving AI out of the inventory. Colorado and California rules, and any customer using the NIST AI RMF, will ask what models and agents you run.
• Assuming a vendor's SOC 2 report covers its open source. It rarely answers component-level questions; ask for the SBOM.

FAQ

Is there a US federal law that requires an SBOM?

No single horizontal law does. SBOMs are required or expected through specific routes: FDA section 524B for cyber devices, contract terms federal agencies may adopt under OMB M-26-05, PCI DSS 6.3.2 for payment software inventories, and customer contracts. In practice most US companies are asked for SBOMs by customers.

Did OMB M-26-05 end the secure software attestation form?

It ended the requirement that agencies collect it. M-26-05 rescinded M-22-18 and M-23-16 on 23 January 2026. Agencies may still choose to use the form and the SSDF, and may require an SBOM on request.

What replaced CISA BOD 22-01?

BOD 26-04, issued 10 June 2026. It ranks remediation urgency by asset exposure, KEV status, exploit automation and technical impact. Its full timelines apply from 180 days after issuance.

When does CMMC Level 2 third-party assessment start appearing in contracts?

Phase 2 starts on 10 November 2026, one calendar year after the DFARS rule began Phase 1. It brings Level 2 assessments by certified third-party assessors into applicable contracts.

How fast must a public company disclose a cyber incident?

Under Form 8-K Item 1.05, generally within four business days after the company determines the incident is material, unless the Attorney General approves a delay for national security or public safety.

What does NYDFS Part 500 require for software inventory?

Section 500.13(a), in force since 1 November 2025, requires a complete, documented inventory of information systems with owner, location, classification, support expiration and recovery objectives.

Does PCI DSS v4.0.1 require an SBOM?

Requirement 6.3.2 requires an inventory of bespoke and custom software and its third-party components, mandatory since 31 March 2025. It does not mandate the SBOM format, but an SBOM per release is the simplest way to meet it.

Can Safeguard run without our code leaving our network?

Yes. The local runner scans on your machine and sends back only encrypted results, and Safeguard can be deployed in a private VPC, on-prem or fully air-gapped, with Zero AI mode if you want no LLM in the loop.

Related reading

• Federal software procurement SBOM requirements
• The global SBOM movement: who is asking for software transparency
• SBOM rules compared: US, EU, Germany and India
• NSM-22 replaced PPD-21: what changed

Every US regime in this guide eventually asks how fast you move a vulnerable component to a safe version. The section below explains how Safeguard closes that gap when a fix exists and when it does not yet exist upstream.

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 is a real Safeguard CLI session: you ask it to fix the lodash CVE in a repository, and it reads the finding, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same flow is how a team works down a BOD 26-04 style or PCI 6.3.3 queue one approved change at a time.

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

The second demo sets up the local runner on your own machine, approves it with its device code and then scans from the terminal. For defense suppliers handling CUI and financial firms that will not grant repository access, this is the way to build the inventory without sending source code anywhere.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. GRC and AppSec teams can use the same connection to ask which products contain a component during an incident, which is the first question behind an SEC or NYDFS clock.

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

Quick check

Sources

• NIST SP 800-218, SSDF version 1.1
• NIST SP 800-218 Rev. 1 initial public draft, SSDF version 1.2
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• CISA, Secure Software Development Attestation Form (archived)
• CISA, 2026 Minimum Elements for an SBOM
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA, Cybersecurity Directives
• DFARS 252.204-7012
• Federal Register, DFARS CMMC rule, 90 FR 43560
• Federal Register, CMMC Program rule, 89 FR 83092
• SEC press release 2023-139, cybersecurity disclosure rules
• SIFMA and others, comment letter on Regulation S-K cybersecurity disclosures
• 21 U.S.C. 360n-2 (FD&C Act section 524B), GovInfo
• NYDFS, Second Amendment to 23 NYCRR 500, adopted text (effective 1 November 2023)
• NYDFS, Cybersecurity Implementation Timeline for Covered Entities
• New York State, 23 NYCRR 500 as adopted in 2017 (section 500.08 Application Security)
• PCI SSC, Just Published: PCI DSS v4.0.1
• CPPA, CCPA updates, cybersecurity audits, risk assessments and ADMT regulations
• Colorado General Assembly, SB24-205
• Colorado General Assembly, SB26-189
• NIST AI Risk Management Framework
• CISA alert, XZ Utils supply chain compromise, CVE-2024-3094
• CISA alert, widespread supply chain compromise impacting npm
• Safeguard docs, NIST SSDF
• Safeguard docs, NIST SP 800-161
• Safeguard docs, NY DFS 23 NYCRR 500
• Safeguard docs, CCPA and CPRA
• Safeguard docs, FDA medical device
• Safeguard docs, PCI DSS 4.0
• Safeguard docs, CMMC 2.0
• Safeguard docs, FedRAMP
• Safeguard docs, CLI usage
• Safeguard docs, Guardrails and enforcement
• Safeguard docs, TPRM SBOM requests
• Safeguard docs, Trust Center setup
• Safeguard docs, AI-BOM discovery
• Safeguard docs, Air-gapped deployment
• Safeguard docs, Generate SBOM

To try it, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

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