The secure software development attestation and the human who signed it

Attestation-based regulation works by moving assurance from an assessor to a signature. That only functions if the signer can know what they are signing, and for a software organisation of any size, they cannot.

Part of Defense industrial base identity

What the attestation asks

Federal software producers are required to attest that their development practices align with secure software development guidance, drawing on the NIST Secure Software Development Framework. The attestation is made by an authorised person at the producer, and agencies rely on it in acquiring the software.

The practices concern things like maintaining trusted source code supply chains, maintaining provenance data, using automated tooling to check for vulnerabilities, and securing development environments.

The scale problem

A software organisation selling to the federal government may have hundreds of engineering teams, thousands of repositories, several build systems accumulated through acquisitions, and practices that vary by product line and by how recently a team was onboarded.

The executive signing cannot personally verify any of it. They are relying on a compliance function that surveyed engineering leads, who relied on their own impressions of their teams' practices.

An attestation about an organisation is only as good as the organisation's ability to measure itself, and most cannot.

Measurable and unmeasurable practices

Honest attestation starts with classifying the practices, because some are directly observable from build and repository state and others are not.

The bottom two rows matter and cannot be measured by tooling. An attestation programme that pretends otherwise is producing false precision; one that admits it can at least treat those practices through a different mechanism.

The Attestation Evidence Standard

Run an automated practice-state measurement across the estate, hash its output, and include the hash in the signed attestation.

{
  "type": "manav-stmt/1",
  "action": "secure_development_attestation",
  "render": [
    "Producer: [entity]  Products in scope: [list]",
    "Repositories measured: [count]  Builds measured: [count]",
    "Practice state hash: [value]",
    "Measurable practice conformance: [percentages by practice]",
    "Unmeasurable practices: [list, addressed by policy attestation]",
    "Measurement date: [date]  Tooling: [name, version]"
  ],
  "signer": "[executive credential assertion, title]"
}

The executive is now attesting to something reproducible. A year later, the measurement can be re-run against the same repositories and compared.

The uncomfortable first run

Organisations that do this discover that conformance is lower than the previous attestation implied — not because anyone lied, but because survey-based self-reporting is systematically optimistic and nobody had measured.

That is the moment the programme either becomes real or gets quietly shelved. The argument for pressing on is that the measurement exists whether or not you run it: an investigator, a customer, or a plaintiff can run equivalent tooling against your public artefacts.

Scope, and the acquisition trap

Define the scope boundary explicitly and hash it. The common failure is an attestation whose scope is described as our products, which silently includes an acquired codebase running on a build system nobody has audited.

Naming the products and counting the repositories turns scope from an assumption into a statement.

What the signer needs beneath the signature

Objections and honest limits

“Our toolchain produces all of this.” Some of it, in vendor-specific formats, retained for vendor-specific periods. The question is whether an executive can obtain a defensible roll-up on demand.

“The attestation is a formality.” It is a signed statement to a government customer about facts. The formality framing is exactly the one that produces personal exposure.

Supporting an executive attestation

1. Enumerate the claims on the form. Sentence by sentence, not framework by framework.
2. Map each to an artefact that exists. Retrievable today, not reconstructible in principle.
3. Produce a roll-up the signer can read. Coverage percentage and exceptions per claim.
4. Let the signer see the exceptions. They are the party exposed, and they should see the gaps before signing.

Terms used here

SSDF

The Secure Software Development Framework, the practice set the attestation requirements derive from.

Attestation form

The document by which a producer states that software was developed in conformity with required practices.

Roll-up

An aggregate view of coverage and exceptions across repositories, which is what an executive can actually review.

Frequently asked questions

Does this make us compliant? No. It makes the attestation reproducible, which is a different and narrower claim. Compliance depends on the underlying practices.

What about practices tooling cannot measure? Classify them honestly and address them through policy attestation, with the classification stated in the signed record. False precision is worse than an acknowledged gap.

Who should sign? The person the requirement designates — typically a senior executive of the producer. The point of the evidence standard is to give that person something to stand on.

Does FCA exposure apply here? Cybersecurity False Claims Act enforcement has covered representations about security practices to the government. This article gives no legal advice; counsel should advise on exposure.

Who is exposed by the attestation? The named executive who signs, alongside the organisation. That is what makes the evidence question personal rather than procedural.

What is the hardest claim to evidence? That code was reviewed before release, because most pipelines record an approval count rather than a named human bound to the merged commit.

What should an executive see before signing? A per-claim roll-up showing coverage and, explicitly, the exceptions.

Sources and further reading

• CISA — Secure Software Development Attestation Form
• U.S. Department of Justice — press releases
• Published guidance on software supply chain provenance and artefact signing.
• NIST SP 800-218 — Secure Software Development Framework