What the government means by "supply chain"
A software supplier hears "supply chain" and pictures parts, trucks, and warehouses. In a federal contract the phrase means something narrower and far more demanding. The government wants to know where the code you deliver came from, who touched it on the way, what it depends on, which suppliers sit behind those dependencies, how you would find out if one of them became a problem, and what you would do that day. Those questions now live in the Federal Acquisition Regulation, in the Defense Federal Acquisition Regulation Supplement, in OMB memoranda, and in the clauses a contracting officer pastes into your award. They are enforced. They are enforced against small suppliers, not only against the primes above them.
The term of art is C-SCRM: cybersecurity supply chain risk management. NIST Special Publication 800-161 Revision 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, published May 2022, is the reference the rest of the federal apparatus points at. Its scope is wider than most suppliers expect. It covers third-party and open-source components, the build environment they pass through, the people with commit access, the tooling that signs releases, the notification path when something goes wrong, and the disposal of what you delivered when the contract ends.
What follows covers the obligations that attach to a supplier of software, data, or analytic services. Counterfeit-parts rules such as DFARS 252.246-7007 and 252.246-7008 govern electronic components and reach a software firm only if it also ships hardware. Everything below reaches a firm that ships nothing but a container image.
The rules that actually apply, by name
Six authorities carry the weight. Read your award for the clause numbers rather than assuming; a task order under a governmentwide vehicle can carry a different set than the base contract.
| Authority | What it requires | Who it binds |
|---|---|---|
| FAR subpart 4.23; clauses 52.204-28, -29, -30 | Representation on covered articles and a prohibition on delivering anything named in a published FASCSA exclusion or removal order. | Every offeror; flows down to subcontracts at all tiers, including commercial and COTS items. |
| FAR subpart 4.21; clauses 52.204-24, -25, -26 | Representation, after reasonable inquiry, that the firm neither provides nor uses covered telecommunications equipment as a substantial or essential component. | All solicitations and contracts, including commercial items. |
| OMB M-22-18 and M-23-16; CISA attestation form | A signed attestation that the software was produced under NIST SP 800-218, the Secure Software Development Framework. | Producers of software an agency uses, with narrow exceptions. |
| NIST SP 800-161r1 and SP 800-53 Rev. 5, SR family | A written C-SCRM plan, supplier assessment, provenance records, tamper detection, component authenticity, disposal. | Federal systems; inherited by contractors through the SSP and through clause flowdown. |
| DFARS 252.204-7012, -7019, -7020 | NIST SP 800-171 implementation, a current assessment score posted in SPRS, and a 72-hour cyber incident report. | DoD contracts involving covered defense information; flows down to subcontractors. |
| DFARS 239.73; clauses 252.239-7017, -7018 | Supply chain risk disclosure, and government authority to exclude a source without disclosing why. | Acquisitions supporting national security systems, under 10 U.S.C. 3252. |
FASCSA is the newest obligation and the one most software firms miss
The Federal Acquisition Supply Chain Security Act is Title II of the SECURE Technology Act, Public Law 115-390, signed December 21, 2018. It created the Federal Acquisition Security Council and gave it authority to issue exclusion and removal orders against specific sources and specific covered articles. The Council's own rule sits at 41 CFR part 201-1. The acquisition side arrived later: an interim FAR rule under FAR Case 2020-011 took effect December 4, 2023 and added subpart 4.23 plus three clauses.
Two things about that rule catch small suppliers. First, published FASCSA orders live in the exclusions module of SAM.gov, and checking them is your job before you propose and again before you deliver. Second, the prohibition does not dilute at low dollar values. Most FAR obligations relax below the simplified acquisition threshold of $250,000, and many disappear below the micro-purchase threshold of $10,000. This one applies at every dollar value and to commercially available off-the-shelf items, which is unusual enough that firms who have read a lot of FAR sometimes assume their way past it.
The representation in FAR 52.204-29 is made after a reasonable inquiry. The related clause at FAR 52.204-25 defines that phrase usefully: an inquiry designed to uncover information in your possession, which specifically does not require an internal or third-party audit. That is a workable standard. It is also a standard you have to be able to show you met. An inquiry with no record behind it is indistinguishable from no inquiry at all.
The secure software attestation
Executive Order 14028, signed May 12, 2021, put secure software development on a schedule in section 4. NIST published SP 800-218, the Secure Software Development Framework version 1.1, in February 2022. OMB M-22-18, dated September 14, 2022, then directed agencies to obtain a self-attestation from producers of software they use, and OMB M-23-16, dated June 9, 2023, adjusted the timelines and clarified scope. CISA's Secure Software Development Attestation Form, approved by OMB on March 11, 2024, is the common instrument most agencies now hand you.
Scope, in plain terms: software developed after September 14, 2022, existing software changed by major version, and software-as-a-service. Software an agency developed in house is out of scope. Freely obtained open-source components are out of scope on their own, but the producer who assembles them into a delivered product attests for the assembly. That surprises firms who reason that they "only glue open source together." Gluing is producing.
The form asks for a small number of concrete practices: a build environment separated from general-purpose development, multifactor authentication and consistent access controls on that environment, provenance maintained for internal code and third-party components, automated checking for known vulnerabilities, and a documented remediation process. A company officer signs it. That signature is why the practices behind it have to be real engineering work, since the signature is what a False Claims Act theory attaches to.
Where you cannot yet attest to a practice, the memoranda contemplate documenting the gap in a plan of action and milestones, with the agency able to seek an extension from OMB. That path exists and is legitimate. It has to be used explicitly, in writing, before delivery. The June 2025 amendments to federal cybersecurity policy narrowed the government-wide machinery for centrally validating attestations and directed NIST to refresh the SSDF guidance; the agency-level requirement to collect the attestation was not withdrawn.
Artifact readiness — what gets asked for first
Editorial weighting from public guidance and practitioner reading — illustrative, not a measured statistic.
Where the artifacts come from: SP 800-161 and the SR controls
NIST SP 800-53 Revision 5 added a control family for exactly this work. SR-1 is policy. SR-2 is the C-SCRM plan itself. SR-3 covers supply chain controls and processes. SR-4 is provenance. SR-5 is acquisition strategy. SR-6 is supplier assessment and review. SR-8 is notification agreements, meaning your suppliers tell you and you tell your customer. SR-9 is tamper resistance and detection, SR-10 is inspection, SR-11 is component authenticity, and SR-12 is disposal. Nearly every artifact a federal assessor asks a software supplier to produce maps to one of those twelve controls.
SP 800-161r1 is where those controls become a program. Appendix A layers the C-SCRM guidance across enterprise, mission, and operational levels. Appendix C provides a plan template a firm can fill in honestly in a couple of weeks. No federal agency expects two hundred pages from a supplier of a single analytic service. Ten to fifteen pages with a real supplier register behind it clears the bar and stands up under questioning, which a padded document does not.
A supply chain program is a records program with an engineering front end. The engineering is the easy half. Generating an SBOM at build time is one pipeline stage. Signing artifacts is another. Pinning dependencies by hash is a configuration change. The hard half is that somebody has to own the register, review it on a cadence, keep the dates current, and be able to reconstruct the state of any delivered build months later.
The artifacts that have to exist
- A C-SCRM plan mapped to the SR control family, dated and version-controlled
- An SBOM per delivered build, in SPDX (ISO/IEC 5962:2021) or CycloneDX (ECMA-424), carrying at minimum the NTIA data fields: supplier, component, version, unique identifier, dependency relationship, author, and timestamp
- A supplier and dependency register naming an internal owner for each entry
- The signed SSDF attestation, plus the practice evidence behind each assertion on it
- Records of the reasonable inquiry supporting the FASCSA and Section 889 representations
- Build environment documentation: separation, access control, MFA, and who holds signing keys
- A vulnerability intake and remediation procedure with named response windows
- A notification procedure identifying who tells the customer, within what time, and through which channel
Where flowdown actually bites
The FASCSA prohibition and the DFARS safeguarding clauses both flow down. A firm holding a subcontract inherits the obligation from the prime, and a firm issuing one has to pass it along in writing. Missing flowdown language is among the most common defects in small-business subcontract agreements, and it surfaces at the worst moment: during an incident, when the prime asks for your supplier records and you ask your subcontractor for theirs.
Open-source intake is the second pressure point. A dependency pulled from a public registry has a producer, a license, a version, and a maintenance state, and each of those is a fact your customer may ask about. The practice that works is boring: pin by hash, mirror into an internal registry, record the license and the retrieval date, and review the register quarterly rather than at award time only.
For AI and machine-learning delivery there is a third case the rules do not yet name cleanly. A pretrained model checkpoint and a training dataset are third-party components in every meaningful sense: origins, licenses, versions, integrity properties, and the possibility of alteration. Nothing in the current clause set says how to document them, so the supplier decides. We treat a checkpoint as a dependency: source, license, version hash, retrieval date, and a written reason it was selected. When an assessor asks, the record is already there.
What assessors write up most often
- Attestation signed, practices absent: the form asserts a separated build environment that does not exist yet.
- SBOM generated once: produced by hand for the proposal, never wired into the pipeline, stale by the first delivery.
- Representation without inquiry: the FASCSA and 889 reps are checked with no record of what was checked or when.
- Flowdown omitted: the subcontract agreement carries price and scope but not the clauses the prime is bound by.
- No off-ramp: the plan never says what happens when a supplier is excluded, so the answer gets invented under pressure.
- Stale SPRS score: the DoD assessment is more than three years old, which makes the firm unawardable regardless of technical merit.
What getting it wrong costs
The expensive failure mode is the False Claims Act, 31 U.S.C. 3729 through 3733. Damages are trebled and civil penalties are assessed per false claim, adjusted for inflation annually and now above $14,000 each. A relator who brings the case keeps 15 to 30 percent under 31 U.S.C. 3730(d). Since the Department of Justice announced its Civil Cyber-Fraud Initiative in October 2021, cybersecurity representations have been an explicit enforcement priority: Aerojet Rocketdyne settled for $9 million in July 2022, Verizon for $4.091 million in September 2023, and Penn State for $1.25 million in October 2024. Every one of those matters turned on statements about security practices rather than on a breach.
The administrative failure modes are slower and nearly as costly. A FASCSA order naming a component you ship forces a re-architecture on the government's timeline. Suspension and debarment under FAR subpart 9.4 removes you from federal work entirely. A negative CPARS rating follows you through source selections for three years. Under DoD rules, an SPRS assessment older than three years stops an award before any evaluator reads the technical volume.
The cheapest failure is the one firms notice least: losing the competition. Evaluators score supply chain sections. A supplier who submits a dated C-SCRM plan, a sample SBOM, and a signed attestation reads as a firm that has done this before. A supplier who promises to comply after award reads as risk the evaluator can avoid by choosing somebody else.
A practical sequence for doing this the first time
First-pass C-SCRM buildout
Six to eight weeks of deliberate work produces a program that survives a real assessment. Firms that stretch it across a year rarely finish, because the artifacts drift out of date faster than the remaining ones get written.
How we build this into delivery
Our engineers treat supply chain records as build outputs rather than documents written afterward. SBOM generation, dependency pinning, artifact signing, and provenance capture for models and datasets run inside the pipeline that produces the deliverable, so the record for any build can be reconstructed from the build itself. The C-SCRM plan, the obligation map, and the supplier register are maintained alongside the code, in the same repository, under the same review.
That posture holds up in the two places it gets tested: a source selection where an evaluator is scoring the supply chain section, and a program office asking what version of a component shipped four months ago. Both are answerable in minutes when the records are generated rather than assembled.
Bottom line
Federal supply chain risk management is not a hardware problem that software firms are being dragged into. It is a records discipline that happens to be enforced through clauses with real teeth: a prohibition that reaches every dollar value, an attestation an officer signs, an assessment score that gates awards, and a statute that trebles damages. The engineering is a week of pipeline work. The program is a few weeks of writing and a calendar entry. The alternative is discovering the gap during a source selection, or during an incident, when neither is cheap.
Frequently asked questions
The FASCSA prohibition in FAR 52.204-30 and the Section 889 representations apply regardless of contract size, including below the micro-purchase threshold and to commercial off-the-shelf items. The DFARS clauses apply when the contract involves covered defense information. Scale the documents to the firm; the obligations themselves do not scale down.
An SBOM is a machine-readable inventory of what is inside one build, in SPDX or CycloneDX format with the NTIA minimum data fields. A C-SCRM plan is the written program describing how the firm selects suppliers, checks exclusion orders, maintains provenance, responds to a supplier problem, and disposes of delivered material. The SBOM is an artifact the plan produces.
A company officer, typically the chief executive or a designated official with authority to bind the firm. That signature is what makes the attestation legally meaningful, and it is why the practices behind each assertion need to exist before it is signed rather than after.
Freely obtained open-source components are not separately attested by their own maintainers, but the firm that assembles them into a delivered product attests for the assembly. Practically, that means pinning versions by hash, recording license and origin, mirroring into a controlled registry, and checking for known vulnerabilities on a recurring schedule.
Published FASCSA exclusion and removal orders appear in the exclusions area of SAM.gov, tagged as FASCSA orders. Check before proposing and again before delivering, and keep the dated record of the check as evidence supporting the representation in FAR 52.204-29.