{
 "slug": "software-attestation-evidence",
 "topic_id": "TOPIC-204",
 "cluster": "Defense Industrial Base, CUI & Export-Control Identity",
 "tier": "Tier A",
 "title": "The secure software development attestation and the human who signed it",
 "summary": "Federal software producers attest to secure development practices. An executive signs for engineering practices spanning potentially thousands of repositories, on evidence a compliance team assembled.",
 "lede": "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.",
 "date": "2025-01-23",
 "category": "Compliance",
 "author_id": "constance-ibe-whitmore",
 "tags": [
  "secure software development",
  "SSDF",
  "attestation",
  "False Claims Act",
  "federal software",
  "supply chain security"
 ],
 "image_title": "Software Attestation Evidence",
 "schema": "Article",
 "key_takeaways": [
  "The attestation asks an executive to affirm organisation-wide engineering practice. The evidence is whatever a compliance team could assemble, and it is rarely reproducible.",
  "Practices divide into measurable and unmeasurable. Honest attestation requires knowing which is which and saying so.",
  "Binding the signature to an automated practice-state measurement makes the attestation reproducible rather than aspirational."
 ],
 "body": [
  {
   "type": "h2",
   "text": "What the attestation asks"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "One signature, thousands of repositories",
   "caption": "The attestation is organisational. The evidence is distributed and mostly unstructured.",
   "nodes": [
    {
     "label": "Practices required",
     "note": "SSDF-derived"
    },
    {
     "label": "Evidence lives in CI, SCM, ticketing",
     "note": "thousands of repos",
     "bad": true
    },
    {
     "label": "Executive signs a single form",
     "note": "cannot inspect personally",
     "bad": true
    },
    {
     "label": "Personal exposure attaches",
     "note": "to the signer",
     "bad": true
    }
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "The scale problem"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "blockquote",
   "text": "An attestation about an organisation is only as good as the organisation's ability to measure itself, and most cannot."
  },
  {
   "type": "h2",
   "text": "Measurable and unmeasurable practices"
  },
  {
   "type": "p",
   "html": "Honest attestation starts with classifying the practices, because some are directly observable from build and repository state and others are not."
  },
  {
   "type": "table",
   "head": [
    "Practice class",
    "Example",
    "Measurable automatically?"
   ],
   "rows": [
    [
     "Repository configuration",
     "Branch protection, required reviews, signed commits",
     "Yes"
    ],
    [
     "Build integrity",
     "Hermetic builds, provenance generation, artefact signing",
     "Yes"
    ],
    [
     "Dependency management",
     "SBOM generation, known-vulnerability scanning",
     "Yes"
    ],
    [
     "Environment separation",
     "Development and production isolation",
     "Partially"
    ],
    [
     "Developer training",
     "Secure coding education completion",
     "Recorded, not observed"
    ],
    [
     "Design review quality",
     "Threat modelling depth",
     "<strong style=\"font-weight:600\">No</strong>"
    ],
    [
     "Code review substance",
     "Whether a reviewer understood the change",
     "<strong style=\"font-weight:600\">No</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "The Attestation Evidence Standard"
  },
  {
   "type": "p",
   "html": "Run an automated practice-state measurement across the estate, hash its output, and include the hash in the signed attestation."
  },
  {
   "type": "code",
   "text": "{\n  \"type\": \"manav-stmt/1\",\n  \"action\": \"secure_development_attestation\",\n  \"render\": [\n    \"Producer: [entity]  Products in scope: [list]\",\n    \"Repositories measured: [count]  Builds measured: [count]\",\n    \"Practice state hash: [value]\",\n    \"Measurable practice conformance: [percentages by practice]\",\n    \"Unmeasurable practices: [list, addressed by policy attestation]\",\n    \"Measurement date: [date]  Tooling: [name, version]\"\n  ],\n  \"signer\": \"[executive credential assertion, title]\"\n}"
  },
  {
   "type": "p",
   "html": "The executive is now attesting to something reproducible. A year later, the measurement can be re-run against the same repositories and compared."
  },
  {
   "type": "h2",
   "text": "The uncomfortable first run"
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "p",
   "html": "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."
  },
  {
   "type": "h2",
   "text": "Scope, and the acquisition trap"
  },
  {
   "type": "p",
   "html": "Define the scope boundary explicitly and hash it. The common failure is an attestation whose scope is described as <em>our products</em>, which silently includes an acquired codebase running on a build system nobody has audited."
  },
  {
   "type": "p",
   "html": "Naming the products and counting the repositories turns scope from an assumption into a statement."
  },
  {
   "type": "h2",
   "text": "What the signer needs beneath the signature"
  },
  {
   "type": "table",
   "caption": "Claims and the artefacts that support them",
   "head": [
    "Claim",
    "Supporting artefact"
   ],
   "rows": [
    [
     "Code is reviewed before release",
     "Signed approvals bound to the merged commit"
    ],
    [
     "Builds run in controlled environments",
     "Provenance attestations from the build system"
    ],
    [
     "Artefact integrity is maintained",
     "Artifact signatures verified at deploy"
    ],
    [
     "Access to the pipeline is controlled",
     "Per-change records naming individuals"
    ],
    [
     "Vulnerabilities are addressed",
     "Tracked with dated closure evidence"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Our toolchain produces all of this.”</strong> 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."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“The attestation is a formality.”</strong> It is a signed statement to a government customer about facts. The formality framing is exactly the one that produces personal exposure."
  }
 ],
 "faq": [
  {
   "q": "Does this make us compliant?",
   "a": "No. It makes the attestation reproducible, which is a different and narrower claim. Compliance depends on the underlying practices."
  },
  {
   "q": "What about practices tooling cannot measure?",
   "a": "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."
  },
  {
   "q": "Who should sign?",
   "a": "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."
  },
  {
   "q": "Does FCA exposure apply here?",
   "a": "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."
  },
  {
   "q": "Who is exposed by the attestation?",
   "a": "The named executive who signs, alongside the organisation. That is what makes the evidence question personal rather than procedural."
  },
  {
   "q": "What is the hardest claim to evidence?",
   "a": "That code was reviewed before release, because most pipelines record an approval count rather than a named human bound to the merged commit."
  },
  {
   "q": "What should an executive see before signing?",
   "a": "A per-claim roll-up showing coverage and, explicitly, the exceptions."
  }
 ],
 "sources": [
  {
   "t": "CISA — Secure Software Development Attestation Form",
   "u": "https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form"
  },
  {
   "t": "U.S. Department of Justice — press releases",
   "u": "https://www.justice.gov/news"
  },
  {
   "t": "Published guidance on software supply chain provenance and artefact signing."
  },
  {
   "t": "NIST SP 800-218 — Secure Software Development Framework",
   "u": "https://csrc.nist.gov/pubs/sp/800/218/final"
  }
 ],
 "related": [
  {
   "slug": "affirmation-evidence-standard",
   "title": "CMMC Phase II is suspended",
   "category": "Compliance"
  },
  {
   "slug": "custody-authority-separation",
   "title": "After the 2026 certificate authority compromise",
   "category": "Developer"
  },
  {
   "slug": "release-approval-receipt",
   "title": "Engineering release and configuration control",
   "category": "Compliance"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Software%20Attestation%20Evidence/1500_900/blog.jpg",
 "wordcount": 839,
 "url": "/blog/software-attestation-evidence.html",
 "reading_time": "4 min read",
 "seo_title": "The secure software attestation and who signed it",
 "meta_description": "Federal software producers attest to secure development practices. One executive signs for engineering across thousands of repositories.",
 "hub": {
  "slug": "topics/dib-identity",
  "title": "Defense industrial base identity"
 },
 "answer": "An executive, for engineering practices spanning potentially thousands of repositories, on evidence they cannot personally inspect. The form asks for a statement about how software was produced; the signer's exposure is personal, and the underlying facts live in systems they do not operate.",
 "answer_q": "Who signs the secure software development attestation, and on what basis?",
 "glossary": [
  {
   "term": "SSDF",
   "def": "The Secure Software Development Framework, the practice set the attestation requirements derive from."
  },
  {
   "term": "Attestation form",
   "def": "The document by which a producer states that software was developed in conformity with required practices."
  },
  {
   "term": "Roll-up",
   "def": "An aggregate view of coverage and exceptions across repositories, which is what an executive can actually review."
  }
 ],
 "checklist": {
  "title": "Supporting an executive attestation",
  "id": "support",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Enumerate the claims on the form.",
    "text": "Sentence by sentence, not framework by framework."
   },
   {
    "name": "Map each to an artefact that exists.",
    "text": "Retrievable today, not reconstructible in principle."
   },
   {
    "name": "Produce a roll-up the signer can read.",
    "text": "Coverage percentage and exceptions per claim."
   },
   {
    "name": "Let the signer see the exceptions.",
    "text": "They are the party exposed, and they should see the gaps before signing."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav binds the authorising individual to the exact record being released or approved, and produces a receipt a prime, a government customer or an auditor can verify without access to your systems.",
  "href": "../docs.html",
  "label": "See approval receipts"
 }
}