Aerospace and Defense Supply Chain Security: CMMC, DFARS, 90-Day Plan

Aerospace and defense contractors secure their software supply chain by knowing exactly which components sit inside every system that touches Controlled Unclassified Information, fixing flaws in those components on a schedule they can defend, and holding suppliers to the same standard through the contract. CMMC Phase 2 begins on 10 November 2026, when DoD intends to start requiring third-party Level 2 assessments as a condition of award on applicable contracts. A 90-day plan built around inventory, flaw remediation evidence and supplier flowdown gets most contractors ready to show an assessor real records instead of a policy binder.

The plan below works with whatever tools you already have; Safeguard appears only in "How Safeguard does this". Nothing here is legal or assessment advice. Your contract, your contracting officer and your assessor decide what applies to you.

Key takeaways

• The clock is real. The DFARS CMMC acquisition rule took effect on 10 November 2025, which started Phase 1. Phase 2 begins one calendar year later, on 10 November 2026, and adds Level 2 (C3PAO) assessments for applicable solicitations.
• CMMC Level 2 is NIST SP 800-171 Revision 2. The CMMC program rule maps Level 2 to the 110 requirements of 800-171 R2, even though NIST published Revision 3 in May 2024. Plan against R2 for assessment and watch R3.
• DFARS 252.204-7012 still governs incidents. "Rapidly report" means within 72 hours of discovery. You must preserve images of affected systems for at least 90 days, and the clause flows down to subcontractors.
• Software inventory is evidence. Requirements 3.4.1 (baseline configuration and inventory), 3.11.2 (vulnerability scanning) and 3.14.1 (flaw remediation) all depend on knowing which components and versions you run.
• Recent incidents hit the sector through third-party software and appliances, not only through custom code: an edge appliance flaw used against a parts distributor, ransomware on airport passenger processing software, and a backdoor planted in a widely used open source library.
• Enforcement is not only CMMC. DOJ has used the False Claims Act to settle allegations that contractors misrepresented cybersecurity compliance.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and deep dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates (Block, Warn, Notify, with approvals through exceptions), autonomous remediation (ships switched off, every category set to Manual), license compliance, CSAF and VEX upload, the compliance and GRC suite with CMMC, DFARS 252.204-7012 and NIST SP 800-171 frameworks, TPRM with SBOM requests, the Safeguard CLI and local runner, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

The situation

The trigger for most readers is a letter, a clause or a date. A prime's supplier portal adds a CMMC field to the next bid. A contracting officer asks for your SPRS entry. A program manager forwards a solicitation with a CMMC Level 2 (C3PAO) requirement and asks whether the team can bid. Or the date simply arrives: Phase 2 begins on 10 November 2026, about two weeks after this post was written.

A bad week looks like this. An assessor asks how you know the software inventory in your system security plan is current, and the honest answer is a spreadsheet last touched in spring. A critical vulnerability lands in a library used in a ground station tool, and nobody can say within a day which programs ship it. A subcontractor reports an incident, and you cannot tell whether the affected component sits in a system you deliver. Each of these is a software supply chain question, and each one is answerable with records you can build in 90 days.

What software aerospace and defense companies run

Defense contractors do not run one kind of software. They run several estates with different owners, release cycles and rules. A useful inventory starts by naming them.

Two features make this sector harder than most. First, lifecycles are long. A component compiled into an avionics build may stay in service for a decade or more, which means a vulnerability disclosed today can matter to hardware delivered years ago. Second, much of the work happens inside enclaves with limited or no internet access, so tools that need a constant connection to a vendor cloud are often unusable where the CUI lives.

The regulations and frameworks that apply

The rules below come from primary sources fetched for this post. Dates and clause numbers are as published. Where a document has been revised, the current version is named first.

The CMMC program rule (32 CFR part 170)

DoD published the CMMC program final rule in the Federal Register on 15 October 2024, effective 16 December 2024. It sets three levels:

• Level 1 covers Federal Contract Information and maps to the 15 security requirements in FAR 52.204-21(b)(1).
• Level 2 covers CUI and maps to the 110 requirements of NIST SP 800-171 Revision 2. Depending on the contract, it is met by self-assessment or by an assessment from a certified third-party assessment organization (C3PAO).
• Level 3 adds 24 selected requirements from NIST SP 800-172, assessed by DCMA's Defense Industrial Base Cybersecurity Assessment Center.

The rule allows a Conditional status when the minimum score is met and certain critical requirements are in place, with open items in a plan of action and milestones (POA&M). Those items must be closed and verified within 180 days, or the conditional status expires. A final status is valid for three years, and the contractor must affirm continuing compliance annually.

The DFARS CMMC acquisition rule (48 CFR, DFARS Case 2019-D041)

The complementary acquisition rule was published on 10 September 2025 and took effect on 10 November 2025. Under the program rule, Phase 1 begins on that effective date, and each later phase begins one calendar year after the previous one:

The acquisition rule also states that for three years after its effective date, a CMMC requirement appears in a contract when program managers and requiring activities decide to apply one, excluding awards solely for commercially available off-the-shelf items. It updates the clause so that subcontractors also submit affirmations.

DFARS 252.204-7012, Safeguarding Covered Defense Information

This clause has been in defense contracts for years and remains the operational rule for incidents. The parts that matter most for software supply chain work:

• (b)(2) requires the contractor to implement NIST SP 800-171 "in effect at the time the solicitation is issued or as authorized by the Contracting Officer."
• (c) requires rapid reporting of cyber incidents, defined as within 72 hours of discovery, through the DoD reporting site, which requires a DoD-approved medium assurance certificate.
• (e) requires preserving images of known affected systems and relevant monitoring data for at least 90 days from the report.
• (m) requires flowing the clause down to subcontracts for operationally critical support or where performance involves covered defense information, including subcontracts for commercial products and services.

Seventy-two hours is not much time to work out which components were affected, which is why software inventory belongs inside incident response.

NIST SP 800-171, Revisions 2 and 3

NIST published SP 800-171 Revision 3 in May 2024, superseding Revision 2 (January 2021) as the current NIST text. CMMC Level 2, however, is defined in the program rule against Revision 2, and DFARS 252.204-7012 points to the version in effect when the solicitation is issued or as the contracting officer authorizes. For most contractors that means assessing against R2 today while mapping work forward to R3.

The R2 requirements most tied to software supply chain work are:

• 3.4.1: establish and maintain baseline configurations and inventories of organizational systems, including software.
• 3.11.2: scan for vulnerabilities periodically and when new vulnerabilities affecting the system are identified.
• 3.14.1: identify, report and correct system flaws in a timely manner.

Revision 3 adds a supply chain risk management family, which moves supplier questions from implied to explicit.

NIST SP 800-161 Revision 1 and SP 800-218 (SSDF)

NIST SP 800-161 Revision 1 (May 2022, updated November 2024) is NIST's guidance on cybersecurity supply chain risk management. It is the reference many primes use when they write supplier requirements, and NIST added a fillable SCRM assessment scoping questionnaire in December 2025. NIST SP 800-218, the Secure Software Development Framework (February 2022), describes the practices a software producer follows, and it is the vocabulary federal buyers use for secure development attestations.

CISA 2026 Minimum Elements for an SBOM

On 29 July 2026, CISA and partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, which builds on and replaces the 2021 NTIA baseline. CISA's notice lists new baseline fields for component hash, license, SBOM tool name and SBOM generation context. It is the baseline buyers will point to when they ask a supplier for an SBOM. Ask for it by name in supplier requests.

How the pieces fit

Real public incidents from the last three years

These incidents come from official advisories, government press releases and company filings. The summaries stay with what those sources say.

An edge appliance flaw used against a parts distributor (November 2023)

CISA, the FBI and partners published advisory AA23-325A on 21 November 2023. It describes LockBit 3.0 affiliates exploiting CVE-2023-4966, known as Citrix Bleed, in NetScaler ADC and Gateway appliances. According to the advisory, Boeing observed the affiliates using the flaw to gain initial access to Boeing Distribution Inc., its parts and distribution business, which maintains a separate environment. The advisory says other trusted third parties observed similar activity.

The supply chain lesson is about bought software. The flaw was in a commercial appliance, not in code the victim wrote. Your inventory has to include third-party appliances and the versions they run, or it will miss the systems attackers reach first.

A backdoor in a widely used open source library (March 2024)

On 29 March 2024, CISA reported a supply chain compromise affecting XZ Utils, tracked as CVE-2024-3094, in which malicious code was embedded in specific releases. CISA recommended downgrading to an uncompromised version, such as XZ Utils 5.4.6 Stable, and hunting for malicious activity. The library is a common dependency of Linux distributions, which sit under ground systems, build servers and containers across the sector.

The lesson is speed of lookup. On the day an alert like this lands, the useful question is "which of our images, builds and systems contain the affected versions", and the answer should take minutes.

State actors targeting aerospace and defense (July 2024)

Advisory AA24-207A, released on 25 July 2024 by the FBI with CISA, DC3, NSA and international partners, describes a North Korean state-sponsored group known as Andariel. The advisory says the group primarily targets defense, aerospace, nuclear and engineering entities to obtain sensitive technical information and intellectual property. It says the actors gain initial access by exploiting known vulnerabilities in web servers and widely used software, such as Log4Shell (CVE-2021-44228) in the Apache Log4j library.

For contractors, this is the threat model behind CMMC. Known, unpatched flaws in common software are a route to the technical data that 800-171 exists to protect.

False Claims Act settlement over contract cybersecurity (May 2025)

On 1 May 2025, DOJ announced that Raytheon Company, RTX Corporation and Nightwing entities agreed to pay $8.4 million to resolve allegations that Raytheon violated the False Claims Act by failing to comply with cybersecurity requirements in DoD contracts and subcontracts. According to DOJ, the allegations concerned an internal development system used for unclassified work on certain DoD contracts, and the conduct allegedly occurred between 2015 and 2021. A settlement resolves allegations; it is not a finding of liability.

The lesson for every contractor is about records. Representations about cybersecurity compliance carry legal weight, and the annual CMMC affirmation adds another one. Development systems are in scope when they handle covered information.

Ransomware on airport passenger processing software (September 2025)

In a Form 8-K filed with the SEC, RTX said that on 19 September 2025 it became aware of a product cybersecurity incident involving ransomware on systems that support its MUSE passenger processing software, which lets multiple airlines share check-in and gate resources. RTX said the MUSE airport systems operate outside its enterprise network, on customer-specific networks, and that customers shifted to backup or manual processes and experienced flight delays and cancellations. RTX said the incident was not expected to have a material financial impact. The filing does not describe how access was gained, and this post does not speculate.

The lesson is that aerospace companies are also software vendors. When your product runs on a customer's network, your customers need from you the same component transparency you want from your own suppliers.

The personas who own the problem

No single role owns software supply chain security in a defense contractor. The table names who usually holds each piece, what they need and when they need it.

What each role is really asking

The CISO is asking whether the company can affirm and survive scrutiny. In software terms that means an inventory current enough to answer an assessor's sample, an incident playbook in which "which systems run the affected component" takes minutes, and a scope decision that puts development systems handling covered information inside the boundary.

The CMMC or GRC lead needs dated, attributable records: SBOMs per system, timestamped scan results, tickets or pull requests that show flaws corrected, and exceptions with reasons and expiry dates. Any software item that lands on the POA&M has 180 days to close under a conditional status.

The engineering lead wants one way of working across codebases that release twice a year and codebases that release weekly, with an exception path for programs where a component cannot change without recertification work.

The platform engineer turns policy into pipeline behaviour: scanning that runs where the code is, often with no internet, results that land in one place, and gates that fail builds only for the right reasons.

Supplier management owns the 7012(m) flowdown: which subcontracts involve covered defense information or operationally critical support, proof the clause is in each, and SBOMs from software suppliers.

Product security answers "are we affected" for fielded versions and publishes that answer in a machine-readable form. The MUSE incident shows how quickly a product issue becomes a customer's operational problem.

Step by step: a 30/60/90-day plan

This plan works with any tools, including free and open source ones. It assumes Phase 2 is your forcing date, but the order holds whenever your trigger lands.

Days 1 to 30: scope and inventory

1. Confirm scope with the CISO and GRC lead. List the systems that process, store or transmit CUI, including development and test systems that hold covered technical data. Write down the boundary.
2. List every software estate in scope. Use the system types table above. For each, record the owner, the build system, and whether the environment has internet access.
3. Generate SBOMs for what you build. Use a generator that outputs SPDX or CycloneDX for each repository and container image in scope. Store them with the build, dated and named by version.
4. Inventory what you buy. For commercial software and appliances in scope, record product, version and vendor. Edge appliances and remote access products come first, given the incidents above.
5. Match components against vulnerability data. Use the NVD, OSV, GitHub advisories and the CISA Known Exploited Vulnerabilities catalog. Record the scan date.
6. Pick the fix rule you will defend. Write a short, plain rule for "timely" under 3.14.1, for example by severity and by whether the flaw is on the KEV catalog. Your assessor will ask what timely means for you.
7. Pull the subcontract list. Identify every subcontract involving covered defense information or operationally critical support, and check for the 7012 clause.

Days 31 to 60: fix, gate and flow down

1. Work the backlog by exposure. Start with known exploited flaws and those in internet-facing or remote access systems. Then reachable flaws in delivered software. Record each fix as a ticket or pull request linked to the finding.
2. Add a gate to CI for new code. Fail builds on new critical findings and on licenses your contracts forbid. Allow exceptions with a reason, an approver and an expiry date.
3. Write exceptions for fielded systems. Where a component cannot change without recertification, record the compensating control and the date the decision will be reviewed. This is where a POA&M item may come from.
4. Send SBOM requests to software suppliers. Ask for SPDX or CycloneDX that meets the CISA 2026 minimum elements, a named security contact, and their incident reporting path.
5. Add component lookup to the incident playbook. The first hour of a 7012 incident should include "which systems contain this component and version". Test it with a tabletop.

Days 61 to 90: prove it and keep it running

1. Map evidence to requirements. For 3.4.1, 3.11.2 and 3.14.1, attach SBOMs, scan records and fix records with dates. Do the same for the other requirements your software records support.
2. Run a mock sample. Have someone outside the team pick five systems and ask for the inventory, the last scan, and the last three fixes. Time it.
3. Close or schedule every POA&M item. Anything open needs a date inside the 180-day window if you expect a conditional status.
4. Publish product transparency where it helps. For products you deliver, prepare VEX statements for widely reported CVEs that do not affect you, so customers do not have to ask.
5. Set the cadence. Scans on every build and on a schedule for fielded versions, a monthly review of exceptions, a quarterly supplier SBOM refresh, and an annual review before the affirmation.

Template: evidence checklist for an assessor sample

Template: supplier SBOM request (plain text you can adapt)

We are updating our records under DFARS 252.204-7012 and our CMMC program. For each software product or service you supply to us in support of [contract or program], please send a software bill of materials in SPDX or CycloneDX format that meets the CISA 2026 Minimum Elements for an SBOM, the name of your security contact, and the process you use to tell customers about vulnerabilities and incidents affecting the product. Please send it by [date] and update it with each major release.

Decision table: what to do with a finding in an in-scope system

Illustrative scenario: one advisory, 72 hours

This is an illustrative scenario with invented round numbers. A contractor runs 40 in-scope systems. A new advisory lands for a compression library. With SBOMs stored per build, a component search shows 6 systems contain an affected version: 4 ground tools and 2 container images used in a test environment. The ground tools get upgrade pull requests the same day. The test images are rebuilt. No delivered avionics build contains the component, which the team records as not affected. If the team had suspected compromise, the same lookup would have told them which systems to image and preserve under 7012(e). Without SBOMs, the same question takes days of asking program teams.

How Safeguard does this

Safeguard is a software supply chain security platform. The steps below follow the plan above and use only flows described in Safeguard's offering documentation and docs.safeguard.sh. Every capability named here is generally available (GA).

1. Choose where Safeguard runs. For CUI enclaves, Safeguard offers on-prem and fully air-gapped deployment (GA). The air-gapped deployment docs describe a signed snapshot bundle that ships on a cadence you choose, from hourly to quarterly, through a receiver in your DMZ that verifies signatures. The docs say no component inside the perimeter calls outbound, and list delivery options including a one-way diode, signed removable media, a scheduled DMZ sync and a pull replica. Access uses your own SSO through SAML or OIDC. If you want no AI in the loop at all, Zero AI mode (GA) runs the platform deterministically; bring your own model (GA) and local models (GA) are the other options.

2. Keep source code on your machines with the local runner. The Safeguard CLI and local runner (GA) scan on your own systems. The docs show the scan commands:

   # Your own or proprietary code
   safeguard scan --dir .
   
   # A container image
   safeguard scan --image myregistry.azurecr.io/myapp:v1 \
     --registry-username "$REGISTRY_USER" \
     --registry-password "$REGISTRY_PASSWORD"
   
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   Results are written as JSON under ./output by default. The docs note that a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and the source never leaves the machine. These snippets are copied from the docs and were not run for this post.

3. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) covers application dependencies and container layers. The platform shows which projects contain a given component and version, which is the lookup the 72-hour clock needs.

4. Validate what suppliers send. The CLI docs show a validator for SBOM and VEX documents:

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

   It checks CycloneDX and SPDX documents, and CSAF and OpenVEX, against their specifications. --strict treats warnings as errors.

5. Prioritize flaws. Vulnerability management (GA) matches components against vulnerability sources and enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks findings by whether your code actually calls the vulnerable path, so the first fixes are the ones that matter most.

6. Gate new risk in CI. Policies and gates (GA) evaluate SBOMs and findings. The docs list policy conditions such as vulnerability severity, CVSS score, EPSS score, license, component age and maintenance status. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). Exceptions are requested with a business justification and an expiration date, go to approvers, and leave an audit trail. To fail a CI job on a gate, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   Plain English policy creation (GA) is available for teams that prefer to describe a rule in words. License compliance (GA) covers license policy for components.

7. Open fix pull requests, under your control. Autonomous remediation (GA) has Griffin open tested, policy gated pull requests that move a dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. For programs where a change needs recertification, leave the category on Manual and record an exception instead.

8. Map evidence to CMMC, DFARS and 800-171. The compliance and GRC suite (GA) includes framework pages for CMMC 2.0, DFARS 252.204-7012 and NIST SP 800-171, each on by default in a workspace unless you switch it off in Compliance › Manage. Per the docs, each scan of a product checks scan-decided requirements against the product's SBOM, for example baseline software inventory and version records for 800-171 3.4.1, components identifiable for vulnerability scanning under 3.11.2, and flaw traceability under 3.14.1. For DFARS 252.204-7012, the docs describe checks that support 72-hour incident scoping and subcontractor flowdown provenance. Other controls are evidenced with automated tests, uploaded evidence, policies or an attestation, and the framework pages include policy templates written for each, such as a CMMC Third-Party Assessment Preparation Policy and a CUI Cyber Incident Reporting Policy.

9. Request SBOMs from suppliers. TPRM (GA) lets you send single or bulk SBOM requests from a vendor record, with a template that sets format requirements (SPDX or CycloneDX), a deadline and automated reminders. The docs list request statuses from Sent through Submitted, Validated or Rejected; received SBOMs get format validation, a completeness check and an automatic vulnerability scan, and you can ask for a revision.

10. Publish transparency for products you deliver. CSAF and VEX upload (GA) lets you record exploitability statements. Trust Center (GA) gives you a page for your security posture and questionnaire answers for customers.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not certify you. CMMC status comes from a self-assessment or an assessment by a C3PAO or DIBCAC, entered in SPRS. Safeguard helps you collect and organize evidence; it does not issue a status or sign your affirmation.
• It does not report incidents to DoD. Reporting under 7012(c), the medium assurance certificate, and the decision that an event is a reportable incident stay with your team.
• It does not image systems or capture packets. Media preservation under 7012(e) needs forensic tooling and process.
• It does not patch vendor appliances or hosted services. Fixes for commercial appliances, operating systems you do not build and vendor-hosted systems must come from those vendors. The edge appliance incident above is that kind of case.
• It does not cover every 800-171 family. Access control, multifactor authentication, physical protection, personnel security and training are outside a software supply chain platform's scanning, even where the compliance suite lets you attach evidence for them.
• It does not replace recertification judgment. Whether a library change in a flight build needs new assurance work is an engineering and airworthiness decision.
• Safeguard's own posture. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Neither is a certification of your environment.

Common mistakes

• Treating the system security plan as the inventory. A narrative that says "we maintain an inventory" will not survive an assessor's sample. Keep the records themselves.
• Leaving development systems out of scope. If a development system handles covered information, it is in scope. The DOJ settlement above concerned allegations about an internal development system.
• Scanning only what you write. The incidents above came through a commercial appliance, an open source library and a product on customer networks. Inventory what you buy and what you ship.
• Undefined "timely". Without a written rule for 3.14.1, every open finding looks like a failure. Write the rule, then meet it.
• Gates with no exception path. A gate that blocks a delivery with no approved way through gets switched off. Exceptions with an approver and an expiry keep the gate on.
• Asking suppliers for "an SBOM" with no standard. Name the format and the CISA 2026 minimum elements, and validate what comes back.
• Planning only for Revision 3 or only for Revision 2. Assess against R2 as the CMMC rule requires, and map forward so R3 is not a second project.
• Forgetting the POA&M clock. A conditional status gives 180 days. Items with no owner and no date will expire with the status.

FAQ

When does CMMC Phase 2 start?

Phase 2 begins one calendar year after Phase 1. Phase 1 began on 10 November 2025, the effective date of the DFARS CMMC acquisition rule, so Phase 2 begins on 10 November 2026. DoD intends to include Level 2 (C3PAO) requirements in applicable solicitations from then, and may defer them to an option period.

Is CMMC Level 2 based on NIST SP 800-171 Revision 2 or Revision 3?

The CMMC program rule defines Level 2 against the 110 requirements of NIST SP 800-171 Revision 2. NIST published Revision 3 in May 2024. Assess against R2 for CMMC and map your work to R3 so you are ready when contracts move.

Does CMMC require an SBOM?

The CMMC rule does not use the word SBOM as a requirement. NIST SP 800-171 R2 requirement 3.4.1 asks for inventories of organizational systems, including software, and 3.11.2 and 3.14.1 depend on knowing component versions. An SBOM is the most practical way to produce and refresh that record.

What does DFARS 252.204-7012 require when there is an incident?

It requires reporting to DoD within 72 hours of discovery through the DoD reporting site, using a DoD-approved medium assurance certificate. It also requires preserving images of affected systems and relevant monitoring data for at least 90 days from the report.

Do subcontractors need CMMC and the 7012 clause?

Under 7012(m), the clause flows down to subcontracts for operationally critical support or where performance involves covered defense information, including subcontracts for commercial products and services. The DFARS CMMC rule adds that subcontractors also submit affirmations. Check your prime contract for the level required of each subcontractor.

How long does a conditional CMMC status last?

Open POA&M items must be closed and verified within 180 days. If the closeout assessment does not confirm that all requirements are met by then, the conditional status expires.

Can we run software supply chain scanning inside a CUI enclave with no internet?

Yes, if the tool supports it. Look for local scanning that keeps source on your machines, offline vulnerability data delivered on a signed schedule, and no outbound calls from inside the boundary. Safeguard's air-gapped deployment docs describe that model.

Are open source components a CMMC problem?

They are an inventory and flaw remediation problem, which CMMC Level 2 assesses through 800-171 requirements. The XZ Utils compromise in March 2024 showed how a single library can reach many systems through operating system images.

What should we ask software suppliers for?

An SBOM in SPDX or CycloneDX that meets the CISA 2026 minimum elements, a security contact, their vulnerability disclosure and incident notification process, and a commitment to update the SBOM with each major release. For products where a CVE does not apply, ask for a VEX statement.

Related reading

• Aerospace and defense software supply chain
• CMMC 2.0 software supply chain guide
• SBOMs for defense contractors under CMMC
• CMMC Level 2 supply chain control evidence
• CMMC vs NIST 800-171: key differences

Defense programs often cannot wait for an upstream maintainer, and some cannot change a component at all without new assurance work. The options below cover the cases where a fixed version exists and the cases where it does not, so your exception list stays short and every remaining item has a reason.

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. This is the pattern for a CUI enclave: the scan happens where the code lives, and only results leave the machine.

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

The second demo is a real CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. The assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, and runs npm install and npm test with approval. It prints a summary and pushes nothing. The same flow applies to a ground software repository where a program team wants a fix prepared for review rather than merged automatically.

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

Quick check

Sources

• Federal Register: Cybersecurity Maturity Model Certification (CMMC) Program, 32 CFR part 170 (15 October 2024), govinfo text
• Federal Register: DFARS Case 2019-D041, Assessing Contractor Implementation of Cybersecurity Requirements (10 September 2025), govinfo text
• Federal Register document 2024-22905
• Federal Register document 2025-17359
• DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting (acquisition.gov)
• NIST SP 800-171 Revision 3
• NIST SP 800-161 Revision 1, Update 1
• NIST SP 800-218, Secure Software Development Framework
• CISA: Updated Minimum Elements for a Software Bill of Materials (July 2026 release notice)
• CISA advisory AA23-325A: LockBit 3.0 affiliates exploit CVE-2023-4966 Citrix Bleed
• CISA alert: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• CISA advisory AA24-207A: North Korea cyber group conducts global espionage campaign
• DOJ: Raytheon companies and Nightwing Group to pay $8.4M to resolve False Claims Act allegations (1 May 2025)
• RTX Corporation Form 8-K (September 2025)
• Safeguard docs: CMMC 2.0 framework
• Safeguard docs: DFARS 252.204-7012 framework
• Safeguard docs: NIST SP 800-171 framework
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Policies and gates
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: CLI usage
• Safeguard docs: Generate SBOM

To try the flows above, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

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