The CISA Leak and Supply Chain: When Your Vendor Is Your CMMC Risk

Most CMMC breach analysis focuses on the contractor’s own network. The May 2026 CISA story shifts the lens. A contractor working under a CISA contract left agency material in a public GitHub repo for roughly six months before anyone caught it. Brian Krebs broke the story on May 18, congressional letters followed on May 19, and Bruce Schneier amplified it on May 22. CISA didn’t fail at protecting its own core systems. Its contractor did. CISA still owns the outcome.

That distinction is the whole story for the DIB.

CMMC contractors have spent the last two years tightening their own posture. SSPs are written. Evidence is captured. POA&Ms are tracked. The work has been real. But for a meaningful share of the contractor population, that work stops at the network perimeter. The MSP managing their endpoints, the cloud provider hosting their email, the SaaS vendor processing their engineering data, the recruiting firm with access to personnel records, all sit in a category that contractors quietly treat as outside the boundary. The CISA leak is the visible version of why that’s wrong.

The Pattern Across Recent Supply-Chain Incidents

CISA is not the first contractor in a public GitHub repo. It is the loudest recent one. The pattern repeats with enough frequency that the federal CISO community now talks about supply-chain exposure as a default category rather than an edge case.

In the past eighteen months, federal and federal-adjacent material has been found in public repos belonging to: a payroll vendor handling federal employee data, a contracting firm supporting a civilian agency, a cleared-personnel placement firm, and now CISA’s own contractor. The shape is consistent. A developer at the vendor pushes credentials, configs, or working artifacts to a public branch. The repo sits there for days or weeks. A researcher finds it. The story breaks. The agency named at the top of the contract becomes the lede even though the agency’s systems weren’t directly involved.

For DIB contractors, the analog is direct. The prime is the agency in that story. The vendor is the contractor. A defense contractor whose MSP commits a Terraform repo to public GitHub, including the IAM policies that govern the contractor’s CUI enclave, has a CMMC problem regardless of whether the prime contractor’s own personnel made the mistake. The framework doesn’t separate “us” from “them” when CUI is in scope. The contract requirements flow the same way.

How FAR and DFARS Extend Obligations Downstream

The language is unambiguous in the clauses contractors have been agreeing to since 2017.

FAR 52.204-21 establishes the baseline safeguarding requirement for federal contract information. The clause requires the contractor to apply 15 basic safeguards to information systems that process, store, or transmit FCI. The clause is required to be flowed down to any subcontractor that processes, stores, or transmits FCI in the performance of the subcontract. The flow-down isn’t optional. It’s the structure of the regulation.

DFARS 252.204-7012 layers the controlled unclassified information requirement on top. The clause requires contractors to provide adequate security on covered contractor information systems that process, store, or transmit CUI, defined operationally as implementing the security requirements in NIST 800-171. The clause also requires the contractor to include the clause, including paragraph requirements, in subcontracts and similar contractual instruments where CUI will be transmitted. Same flow-down structure. Same enforceability.

DFARS 252.204-7021 adds CMMC certification level requirements to the flow-down. A prime operating at Level 2 cannot award a covered subcontract to a sub that lacks the required CMMC status. Verification before award. Not after.

What the language does is establish a legal chain. The DoD holds the prime accountable. The prime is required to hold subcontractors accountable. Each tier carries the obligation forward by contract. When a vendor in that chain leaks the data, the contractual liability does not stop at the vendor. It moves up the chain to whichever entity was responsible for ensuring the vendor met the requirement. That entity is named in the contract. Assessors will look at it.

This is the architecture the CMMC for subcontractors guide covers from the sub’s vantage point. The CISA incident shows what it looks like when the obligation flows up rather than down.

The Vendor Scoping Discipline

Most contractors’ SSPs have a vendor list. The vendor list is usually wrong in one of two directions. Either it lists every vendor the organization uses without any classification (the SaaS sprawl approach), or it lists only the vendors the contractor explicitly granted CUI access to, missing everything in between. The CMMC boundary discipline requires a sharper cut.

Three categories matter for vendor scoping.

In-scope vendors. These vendors process, store, or transmit CUI in the performance of a contract. The MSP that administers your CUI enclave. The cloud provider that hosts your CUI workload. The collaboration platform you use to share covered drawings with a prime. These vendors are inside your CMMC boundary. Their controls are your controls. Their failures are your findings.

Shared-scope vendors. These vendors have access to systems, accounts, or infrastructure that border your CUI environment but don’t directly handle CUI. The identity provider that authenticates users to your CUI workspace. The endpoint management platform that pushes policy to laptops that may or may not access CUI. The backup provider with credentials to your enclave but a contractual scope that excludes CUI from the backup set. These vendors are in a gray zone. Their failures can become your findings depending on how a specific incident traces.

Out-of-scope vendors. These vendors operate against systems, data, or infrastructure that are demonstrably segmented from your CUI environment. The marketing automation platform on your commercial network. The HR system that holds payroll and benefits but not CUI. The point-of-sale at the company cafeteria. These vendors are outside the boundary, provided the segmentation is real and documented.

The discipline isn’t writing those lists. It’s defending them. For every in-scope and shared-scope vendor, you need evidence that the vendor meets the requirements that apply to your handling of that data. For every out-of-scope vendor, you need evidence that the scoping decision is grounded in a real architectural boundary, not a hopeful assertion. The CUI boundary scoping guide walks through how that documentation has to look. Apply the same rigor to the vendor inventory.

Contract Language That Actually Transfers Obligations

A vendor contract that says “Vendor will comply with applicable laws and regulations” transfers nothing. Generic compliance clauses are unenforceable in any real sense and assessors know to discount them.

Contract language that holds up under assessment has three properties.

First, it names the specific framework and version. Not “applicable cybersecurity requirements” but “the security requirements in NIST 800-171 Rev 2, as incorporated by DFARS 252.204-7012” or the equivalent for the work the vendor performs. The version specificity matters because requirements change. A clause that references “current standards” lets the vendor decide what current means.

Second, it includes flow-down obligations to the vendor’s subcontractors. If your MSP outsources part of their backup function to a third-party storage provider, your contract with the MSP needs language that requires the MSP to flow the same protections down. Otherwise you’ve created a hidden tier of unmanaged risk.

Third, it specifies incident notification timing and what the notification has to include. The DFARS 252.204-7012 clause requires a 72-hour incident report to DoD. If your vendor is the one with the incident and your contract gives them 30 days to notify you, you cannot meet your own 72-hour obligation. The math has to work. Vendor notification timing should be 24 hours or less for any incident affecting CUI handling, with required content including the systems involved, the data potentially affected, and the immediate containment status.

A fourth element belongs in any contract with a vendor that holds your data or credentials. Audit and inspection rights. The vendor must provide evidence of their controls on request, permit a documented assessment of their environment, and produce specified artifacts within a defined timeline. Without those rights, you cannot produce vendor management evidence at assessment time even if the vendor’s posture is good.

What Evidence of Vendor Management Looks Like at Assessment

Assessors don’t grade vendor management as a single control. They grade it through the controls that depend on vendor behavior, which is most of them.

When a C3PAO asks how you handle access control on cloud-hosted CUI, the answer involves your IDP, your cloud provider, possibly your MSP, and the policy artifacts that govern all three. If you can produce a vendor risk assessment for each, a signed contract with the right language, evidence that you periodically verify their controls, and documentation of how their controls combine with yours to satisfy the objective, the control passes. If you can produce a logo on a vendor list and a fifteen-page MSA with no security exhibit, the control doesn’t pass regardless of how well-configured your environment is.

The evidence package an assessor will look for has six elements.

A current vendor inventory with classifications. Which vendors are in-scope, which are shared-scope, which are out-of-scope, and what evidence supports each classification.

A vendor risk assessment for each in-scope and shared-scope vendor. The risk assessment must reflect the vendor’s actual controls, not a self-attestation accepted without review. SOC 2 reports, FedRAMP authorizations, CMMC status, and equivalent third-party attestations are the usable inputs. A vendor questionnaire returned by the vendor’s sales team is not.

Contractual evidence that vendors are required to meet specific standards. The contract language described above, on file, current, and enforceable.

Incident notification and coordination records. Even if no incidents occurred, you should have evidence that the notification pathway has been tested, that contact information is current, and that the obligation is understood on both sides.

Periodic verification activity. At least annually, you should be reviewing each in-scope and shared-scope vendor’s current attestation, refreshing the risk assessment, and confirming that the contract language remains accurate. The activity needs an artifact.

Termination and offboarding records. When a vendor relationship ends, what happens to your data, your credentials, and your access? Assessors look at this in detail because vendor offboarding is where data leaks tend to surface.

The shared responsibility model in CMMC describes how those evidence elements compose into the controls. The MSP guide to CMMC compliance services covers the specific case where the MSP itself is the primary in-scope vendor.

A 30-Day Vendor Inventory and Risk-Tier Exercise

For contractors who don’t currently have this evidence assembled, the work is finite. The next month is the right window before Phase 2 enforcement activity intensifies through the back half of 2026.

Week one is inventory construction. Pull the AP system. Pull the procurement records. Pull the credential management platform. Build a single list of every external organization that provides software, infrastructure, services, or access to your environment. For each, capture the contracting entity, the system or service involved, the data type they touch, and the current contract on file. Expect the list to be larger than you thought.

Week two is classification. Walk each entry through the in-scope, shared-scope, out-of-scope decision. For ambiguous entries, default to shared-scope until you can document the boundary that justifies out-of-scope. The DFARS 252.204-7012 clause, when paired with the DFARS guide, provides the language to anchor each decision.

Week three is risk assessment. For every in-scope and shared-scope vendor, pull their most current third-party attestation. Map their controls to the objectives that your handling of their data depends on. Note the gaps. Where a vendor has none of the relevant attestations and won’t provide one on request, the risk assessment writes itself. That vendor is a finding waiting to be written.

Week four is contract review and remediation planning. Compare the language in each in-scope and shared-scope contract against the three properties named earlier. Where contracts fall short, schedule renegotiation or replacement. Where vendor controls fall short, document the compensating controls you’ve implemented on your side, the risk acceptance if any, and the timeline to remediate.

At the end of thirty days, you have a vendor inventory, classifications with evidence, risk assessments with attestations, contract gap analysis, and an artifact trail an assessor can verify. The work is mechanical once started. The reason it hasn’t been done at most contractors is that nobody owns it and nothing has forced it.

The CISA story will force it for some. The Phase 2 assessment cycle will force it for the rest.

Closing

Vendor management has been treated as a peripheral CMMC topic for as long as the framework has existed. Contractors focused on their own environments. Vendors were either trusted or unaccounted for. The framework, in its language, never agreed with that treatment. The CISA leak made that disagreement concrete.

For the next assessment cycle, every contractor with vendors handling CUI or operating against scoped systems needs to produce the same six-element evidence packet described above. Most contractors today cannot. That gap is the new finding category. The assessors know it. The standards bodies are tightening on it. The contractors who close it before Phase 2 will spend less time in remediation than the contractors who wait.

The CISA story will fade. The vendor management gap will not. Close it now or explain it later.