Notifications
Clear all
Topic starter
02/08/2026 11:29 am
TL;DR: CISA’s new secure software development attestation form requires software producers to affirm secure development environments, source code supply chain security, provenance, and regular vulnerability checks, with third-party validation recommended, according to OXSecurity. The real issue is not filing paperwork, but proving SDLC control over code, dependencies, and secrets across an expanding software supply chain.
NHIMG editorial — based on content published by OXSecurity: CISA secure software development attestation requirements and how to operationalise them
Questions worth separating out
Q: What breaks when software attestations are based on incomplete pipeline visibility?
A: The attestation loses evidential value because the organisation cannot show which systems built the software, which identities touched it, or whether the artefact was altered after source control.
Q: Why do build secrets and pipeline tokens matter to software compliance?
A: They matter because they are non-human identities with the power to alter code, artifacts, and deployment state.
Q: What do security teams get wrong about provenance in software delivery?
A: They often treat provenance as documentation rather than a continuously verifiable control.
Practitioner guidance
- Inventory build-time non-human identities Catalogue every CI/CD account, signing key, API token, and deployment credential that can alter source, build, or release outcomes.
- Remove standing secrets from pipelines Replace long-lived pipeline credentials with short-lived, scoped alternatives where possible and enforce rotation for the rest.
- Link provenance to release approval Require release sign-off to reference the exact build artefact, dependency set, and provenance record that produced it.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of the CISA attestation fields and what each declaration requires in practice.
- Platform-specific ways to map SDLC inventory, provenance, and secrets detection to compliance evidence.
- How PBOM generation and issue tracking support software version traceability during attestation.
- The vendor's recommended workflow for aligning ASMP controls with secure development and release governance.
👉 Read OXSecurity's breakdown of CISA software attestation requirements →
CISA secure software attestations: what security teams need to prove?
Explore further
02/08/2026 12:45 pm
Attestation is becoming a control evidence problem, not a paperwork problem. CISA’s form asks software producers to prove the state of their delivery environment, not merely assert it. That shifts the burden from policy writing to evidence generation across build systems, code provenance, and vulnerability response. Teams that cannot tie attestations to controlled pipelines will struggle to defend the declaration under audit.
A question worth separating out:
Q: Who is accountable if attested software later proves insecure?
A: Accountability extends beyond engineering teams because the certification itself is executive-level assurance. Boards and senior leaders must ensure that the attested controls were real, operating, and evidenced at the time of sign-off. If the organisation cannot prove that, the signature becomes a governance liability rather than a control.
👉 Read our full editorial: CISA software attestations expose supply chain governance gaps
