To sell software to the US federal government under Executive Order 14028, your company must submit CISA's Secure Software Development Attestation Form, signed by the CEO or a designated officer, affirming that the software conforms to a defined subset of NIST's Secure Software Development Framework (SSDF, SP 800-218). The form was finalized on March 11, 2024, which started two clocks: agencies must collect attestations for critical software by June 11, 2024, and for everything else by September 11, 2024. If federal revenue matters to you, this stopped being a future problem two months ago.
I have now walked two engineering organizations through this. The paperwork is short. The work behind honestly signing it is not, and the gap between those two facts is where companies get into trouble — the form carries False Claims Act exposure, and your CEO is the signatory.
Step 1: Determine what is actually in scope
Per OMB memos M-22-18 and M-23-16, the attestation covers software delivered to federal agencies that was developed after September 14, 2022, existing software with a major version change after that date, and software delivered as a service. Explicitly out of scope: software the agency developed itself and open source software the agency obtains directly and freely.
That last exclusion confuses people. If an agency downloads your Apache-licensed project from GitHub, no attestation. If you sell them a supported distribution of that same project, attestation. The trigger is the commercial delivery relationship, not the license.
Build the inventory first: every product, its version lineage since September 2022, and its delivery model. For a SaaS product, the "software" includes the service's own stack, which is a larger surface than most teams initially scope.
Step 2: Read the actual form, not summaries of it
The form attests to four practice areas, drawn from SSDF but narrower than the full framework:
- Secure environments — the environments used to develop and build the software are separated, monitored, logged, enforce MFA, encrypt sensitive data, and defend against unauthorized access.
- Trusted source code supply chains — a good-faith effort to maintain trusted supply chains for internal code and third-party components.
- Provenance — you maintain provenance for internal code and third-party components to the extent feasible.
- Automated vulnerability management — automated tools check for security vulnerabilities on an ongoing basis and before releases, and you have a policy to remediate disclosed vulnerabilities in a reasonable timeframe.
Notice what is not on the form: SBOMs are not universally mandated by the common form itself, though individual agencies can and do request them as artifacts alongside it. Do not confuse the minimum with what your contracting officer will ask for.
Step 3: Map each attestation line to evidence you can produce
This is the bulk of the work. For each of the four areas, write down the concrete control and where the proof lives. A worked slice of what that mapping looks like:
| Form requirement | Concrete control | Evidence |
|---|---|---|
| Separate build environments | Builds run in ephemeral CI runners, no developer access to prod signing keys | CI config, IAM policy export |
| MFA in dev/build environments | Hardware-key MFA enforced org-wide in GitHub and cloud console | IdP policy screenshot, audit log |
| Trusted component supply chain | Locked dependency manifests, internal registry proxy, automated review of new packages | Lockfiles in every repo, registry allowlist config |
| Provenance | Signed build provenance attached to release artifacts; SBOM per release | Attestation bundle, SBOM archive |
| Automated vuln checks | SCA and container scanning on every PR and nightly against released versions | Pipeline definitions, scan reports |
Provenance and component inventory are where most organizations discover gaps. If you cannot enumerate the third-party components in a given release, you cannot honestly attest to area 3. Generating an SBOM per release and archiving it — whether with open tooling like Syft or a platform like SBOM Studio — is the cheapest way to make that line true, and it doubles as the artifact agencies most often request. Continuous vulnerability scanning against those releases covers area 4; this is the workflow SCA tooling exists for, and at Safeguard it is the exact use case we see federal-adjacent vendors adopt first.
Step 4: Handle the gaps with a POA&M, not optimism
You have three honest options for each requirement: attest, attest based on a third-party assessment performed by a FedRAMP-authorized 3PAO, or document a Plan of Action and Milestones (POA&M) for the parts you cannot yet meet.
The POA&M path is underused because it feels like admitting failure. It is the opposite — it is the mechanism that lets you keep selling while you close gaps, provided the agency accepts it along with your identification of the practices in place. What you must not do is sign the clean attestation while a known gap exists. The signature block binds the CEO (or a designated employee with authority to bind the company), and the form is submitted under penalties that include 18 U.S.C. 1001. Nobody's Q3 pipeline is worth that.
Step 5: Submit through RSAA and operationalize the renewal
Submission goes through CISA's Repository for Software Attestation and Artifacts (RSAA) — an online portal where you file the common form, or agencies may accept it directly where the portal does not yet cover their process. Practical notes from doing it:
- The signatory needs to be genuinely briefed. Prepare a two-page internal memo summarizing what they are signing and the evidence basis. Legal will want this artifact later anyway.
- File the evidence bundle internally with a retention policy. The form does not require attaching evidence, but agencies can request artifacts, and a request with a two-week turnaround is not the moment to start collecting.
- Treat it as continuous. A material change — new build system, acquisition, new product line — can invalidate the basis of your attestation. Wire a review into your release process rather than a yearly scramble.
Step 6: Do not gold-plate beyond the form
A final piece of hard-won advice: the form is a floor, and floors are what you attest to. I have watched a team burn a quarter building SLSA level 3 provenance for every internal microservice because a consultant conflated "SSDF alignment" with the attestation requirement. Ship the four areas honestly, document the rest in your roadmap, and put the saved quarter into the controls that reduce actual risk. If your team needs a structured way to build up the underlying practices, our Academy courses on supply chain fundamentals map cleanly onto the SSDF practice families.
Frequently asked questions
Who is allowed to sign the attestation form?
The CEO, or an employee the CEO designates who has authority to bind the corporation. It cannot be delegated to an external consultant or your reseller. The 3PAO assessment route exists if leadership is unwilling to self-attest.
Do open source projects need to attest?
Not for software an agency obtains directly and freely — the exclusion in M-22-18 covers that case. The obligation attaches to the commercial supplier when open source is sold, supported, or bundled into a delivered product, and that supplier attests to its own development and integration practices.
What happens if we miss the deadline?
Agencies are directed to stop using or procuring the software unless you provide an accepted POA&M or the agency obtains an extension. In practice this surfaces as contracting officers withholding renewals and new awards, so the commercial consequence arrives before any legal one.
Is an SBOM required by EO 14028 self-attestation?
The common form itself does not require submitting an SBOM, but agencies may request one as a supporting artifact, and several already do by default. Generating and archiving SBOMs per release is the pragmatic move: it supports the provenance attestation line and pre-answers the most common artifact request.