Nothing in federal secure-software policy prohibits AI-written code — but the producer attests to the development process either way. If your firm signs CISA's Secure Software Development Attestation Form, you are certifying that NIST SP 800-218 (SSDF) practices governed every line you deliver, including the lines an AI coding agent wrote. The attestation does not care who typed the code. It cares whether your process controlled it.
I spent eighteen years in federal acquisition as a Contracting Specialist and Contracting Officer at GSA, IRS, DoD, and DOI, and I have watched every compliance wave land the same way: policy first, enforcement later, and contractors who documented early absorbing the change as paperwork. AI-generated code is colliding with the secure-software attestation regime right now. Here is what you are actually signing.
What are the federal secure-software requirements, and where do they come from?
The chain runs: Executive Order 14028 (2021) directed secure-software standards; NIST published SP 800-218, the Secure Software Development Framework (SSDF); OMB Memoranda M-22-18 and M-23-16 required agencies to obtain attestations from software producers; and CISA published the common Secure Software Development Attestation Form contractors actually sign.
- Executive Order 14028, Improving the Nation's Cybersecurity, responded to the SolarWinds supply-chain compromise by ordering software-supply-chain standards for anything the government buys.
- NIST SP 800-218 (SSDF) defines the practices — organized into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). The framework is published at csrc.nist.gov.
- OMB M-22-18, as adjusted by M-23-16, told agencies they may only use software from producers who attest to a subset of those practices.
- CISA's common attestation form is the standardized self-attestation, signed by the CEO or a designated authorized official, and submitted through CISA's repository or directly to the agency. Details live at cisa.gov.
Scope matters: the regime targets software produced or substantially modified after EO 14028's benchmark dates and used by federal agencies. Custom-developed software delivered under an IT services contract can fall in scope, and agencies increasingly write attestation requirements directly into solicitations.
What does the CISA attestation form actually make you certify?
The form makes an authorized company official certify, on penalty of federal enforcement, that the software was developed consistent with a defined subset of SSDF practices: secure build environments, trusted source-code supply chains, provenance controls for internal and third-party components, and automated vulnerability checking with a remediation process.
| Attestation area | What it means in practice | Where AI-written code creates a question |
|---|---|---|
| Secure development environment | Separated build environments, MFA, logging, encryption | Is the AI agent operating inside that environment — or on a developer's personal machine? |
| Trusted source-code supply chain | Good-faith effort to maintain trusted components and code provenance | An AI agent can reproduce third-party code with no import statement to flag it |
| Provenance of components | Maintain data on internal code and third-party components | Who wrote this function, with what tool, reviewed by whom? |
| Vulnerability detection and response | Automated scanning of code and dependencies, plus a disclosure and remediation process | AI-generated code enters the pipeline faster than manual review scales — your scanning has to keep up |
The enforcement teeth are not hypothetical. A knowingly false attestation is a false statement to the government, and the Department of Justice's Civil Cyber-Fraud Initiative has already used the False Claims Act against contractors who misrepresented cybersecurity compliance. Your CEO's signature on that form is a compliance representation, not a formality.
Can you attest when an AI coding agent wrote part of the codebase?
Yes — if AI-generated code flows through the same controlled process as human-written code. The SSDF is authorship-agnostic: it regulates how code is reviewed, tested, scanned, and traced, not who or what produced it. You cannot attest honestly if agents commit code that skips human review, runs outside your secured environment, or enters the build without scanning.
Treat the AI agent the way the SSDF treats any producer of code — as a component of your development process that must be governed:
- Keep agents inside the attested boundary. If your form certifies a secured build environment, the AI tool must operate within it — enterprise deployment, logged, access-controlled. A developer running an agent against the repo from an unmanaged personal machine breaks the story your CEO signed.
- Mandate human review before merge. SSDF practice PW.7 covers code review; make AI-generated changes structurally unable to reach the build without a named human reviewer. The review record is your evidence.
- Scan everything, trust nothing. Static analysis, dependency scanning, and secret detection apply with extra force to AI output, which can introduce outdated patterns or reproduce vulnerable snippets from training data.
- Record provenance. Which tool, which version, which task, which reviewer. Commit-level metadata is cheap to capture now and impossible to reconstruct later.
When I reviewed contractor compliance representations as a Contracting Officer, the firms that survived scrutiny were never the ones with the most impressive policies — they were the ones whose records matched their claims. An attestation backed by commit logs, review records, and scan reports is defensible. An attestation backed by "our developers are careful" is a False Claims Act deposition waiting to happen.
Where do SBOMs fit when AI wrote some of the code?
A Software Bill of Materials (SBOM) inventories the components inside your software — and agencies may require one alongside the attestation. AI-written code complicates the SBOM in one specific way: an agent can embed third-party logic without declaring a dependency, so nothing shows up in the manifest for your SBOM tooling to find.
Practical handling:
- Generate SBOMs from the build, automatically. Standard formats (SPDX, CycloneDX) generated in the CI pipeline, not assembled by hand at delivery time.
- Add code-similarity or snippet scanning if your deliverables carry licensing risk — it is the only tooling class that catches reproduced third-party code that never appeared in a package manifest.
- Answer the requirement in front of you. The common CISA form does not itself demand an SBOM, but OMB policy lets agencies require artifacts, and DoD and civilian solicitations increasingly do. Read Section L and the contract data requirements — do not assume the form is the whole obligation.
What should an IT services contractor do before signing the form?
Run a gap assessment against the form's four attestation areas, fix the gaps you find, and build the evidence file before the signature — not after a solicitation demands it in ten days. If you cannot attest yet, OMB policy allows submitting a Plan of Action and Milestones (POA&M) route through the agency, which is honest and survivable; a false signature is neither.
- Map your development process to SSDF practices — including every AI tool in the toolchain, its deployment tier, and its access scope.
- Write an AI-assisted development policy: approved tools, mandatory human review, provenance capture, prohibited uses. This document is what turns "we use AI carefully" into evidence.
- Instrument the pipeline: branch protection requiring review, automated scanning gates, SBOM generation, retained logs.
- Decide who signs. The form requires the CEO or a designee with authority to bind the company — brief that person on what the signature certifies, in writing.
- Version the evidence. Attestations cover software on an ongoing basis; when your process or toolchain changes, your documentation has to move with it.
Across our 70+ proven GSA contract awards, the compliance pattern never changes: requirements arrive as policy, become solicitation language, then become mass modifications and order-level discriminators. Secure-software attestation is mid-way through that arc. Contractors selling software-touching services through the Schedule should expect ordering agencies to ask for the form — and for the AI question inside it — before the FAR ever makes it universal.
What Is the Bottom Line?
- AI-written code is not prohibited — but the CISA attestation certifies your process, and AI output must flow through that process like any other code.
- The SSDF (NIST SP 800-218) is authorship-agnostic. Secure environments, provenance, review, and scanning apply to agent-generated code in full.
- Provenance is the new gap. Record which tool wrote what, and which human reviewed it — commit-level metadata, captured automatically.
- SBOM tooling misses AI-embedded third-party code. Add snippet-level scanning where licensing or supply-chain risk warrants it.
- A false attestation is False Claims Act exposure. If you cannot attest yet, use the POA&M path — never the optimistic signature.
Frequently Asked Questions
Does federal policy ban AI-generated code in delivered software?
No. Neither EO 14028, NIST SP 800-218, nor the CISA attestation form prohibits AI-written code. The requirements govern the development process — environments, provenance, review, and vulnerability management — and apply to code regardless of how it was produced.
Who must sign the CISA Secure Software Development Attestation Form?
The company's CEO or a designated employee with authority to bind the corporation. The signer certifies the software was developed consistent with the form's SSDF-based practices, which makes an internal evidence file essential before anyone signs.
Does the attestation requirement apply to custom software built under an IT services contract?
It can. OMB M-22-18 and M-23-16 cover software the agency uses, and agencies increasingly apply attestation requirements to custom-developed deliverables through solicitation terms. Check each solicitation rather than assuming only commercial products are in scope.
Is an SBOM required with every attestation?
Not by the common form itself. OMB policy permits agencies to require SBOMs and other artifacts separately, and many DoD and civilian solicitations now do. Generate SBOMs automatically in your build pipeline so the requirement never becomes a scramble.
What happens if my attestation turns out to be false?
A knowingly false attestation is a false statement to the government and can trigger False Claims Act liability — the DOJ Civil Cyber-Fraud Initiative has pursued exactly this theory against contractors misrepresenting cybersecurity compliance. Documented, good-faith implementation is the protection.
Can I attest if I cannot yet meet every practice on the form?
Do not sign. OMB policy provides a Plan of Action and Milestones path: identify the gaps, give the agency your remediation plan and timeline, and let the agency decide on continued use. A documented POA&M is survivable; a false signature is not.
Do coding agents like Claude Code or Codex themselves need to be FedRAMP authorized?
The tool needs an authorized boundary when government data — CUI, government-furnished code — flows into it. For your own commercial codebase, FedRAMP is not the test; keeping the tool inside your attested secure development environment is.
If your firm delivers software-touching services through a GSA Schedule and needs its compliance posture — attestation readiness, labor categories, contract terms — squared away before agencies start asking, that is the work we do every week at our GSA Schedule services page.