Who must sign the CISA secure software development attestation form, and what does that signature assert?

## The signature is the whole design It would have been easy to make the federal secure-development attestation a technical questionnaire returned by a security team. It was not designed that way. The form is signed by the software producer's **chief executive officer or an officer the CEO designates**, and that choice is the mechanism, not a formality. A government buyer cannot inspect every supplier's pipeline, so instead of verification it takes a *statement of fact from someone who can bind the company* and attaches consequences to it. The asset being protected here is audit truth and non-repudiation: there must be a person whose name is on the claim and who cannot later say the claim was somebody else's. ## What the signature covers The assertion is that the software was developed in conformance with the referenced NIST secure-development practices. Three scoping facts follow: - **It is company-level, product-scoped.** It is not a per-release engineering sign-off and not a per-team claim. - **It includes what you did not write.** Third-party libraries and open-source components inside the product you sell are inside the scope of what you attest for. "That dependency isn't ours" is not available. - **It is a claim about practice, not product state.** You are not asserting the software is free of vulnerabilities. A CVE published a week later does not make the attestation false; abandoning code review while claiming you perform it does. Where an agency prefers, an assessment performed by an accredited third-party assessor can be supplied instead of the producer's own attestation. And where a producer cannot honestly assert every practice, the accepted route is to document the gap with a plan to close it and let the agency decide whether to accept the risk — not to sign anyway. ## The gap the form creates inside a company Picture an analytics vendor selling into a government cloud environment. The engineers know the pipeline: what the build does, which steps enforce review, whether release artifacts are protected, where the exceptions are. The person who must sign has never opened it. Between them sits nothing, unless the company builds it. That gap is where the actual work is, and it is what a good interview answer describes: 1. **Decompose the assertion.** Each practice on the form maps to one or more concrete things the organisation does or does not do. 2. **Name an owner per practice.** Someone is accountable for the claim being true — not for filling in the cell. 3. **Collect evidence that would survive being asked about.** Configuration that enforces the practice beats a policy document that describes it; a control that cannot be bypassed beats a control everyone agrees to follow. 4. **Handle exceptions honestly.** Where a legacy product line does not meet a practice, that becomes a documented gap with a date, escalated to the signer *before* signature, not discovered afterwards. 5. **Give the signer a defensible basis.** The officer signs on the strength of an internal assurance process — someone's written summary, sourced from owners, reviewed by legal — and that process is itself the thing an investigator would later examine. ## Why the stakes are not merely commercial A weak candidate treats a false attestation as a contract problem: worst case, the agency terminates. That is wrong in an important way. An attestation is a representation made to the federal government in order to be paid, and knowingly false representations of that kind attract federal false-statement and false-claims exposure — for the company, and personally for the signer. This is precisely why the form demands an officer's signature rather than a security engineer's: the seriousness is the point. It also explains a behaviour engineers sometimes find frustrating, where legal refuses to let a team assert a practice the team believes it follows. Legal is asking whether the claim is *provable*, not whether it is *probably true*. ## Second-order effects worth naming The officer signature also reshapes internal power. Once a named executive is personally exposed, requests to fix the pipeline stop competing with feature work on equal terms — the attestation becomes the strongest lever a platform-security team has for funding. Mature organisations use it that way deliberately: attest narrowly and truthfully first, then let the documented gaps drive the roadmap. And because the same evidence answers commercial customers who have copied the federal wording into their own contracts, the assurance process is worth building once as a durable capability rather than assembling in a panic per deal. One caution for interviews: the form, its revisions, the memoranda behind it and who may accept a third-party assessment have all changed since the regime began. Answer with the structure — officer signature, product-wide scope, practice-not-product claim, documented gaps, real legal exposure — and say you would confirm the current instrument before anyone signs anything.