CISA software attestations expose supply chain governance gaps

At a glance

What this is: CISA's secure software attestation form shifts the conversation from policy statements to evidence that software producers can prove secure development, trusted provenance, and regular vulnerability checking across the software supply chain.

Why it matters: For IAM, PAM, NHI, and application security teams, the attestation pressure lands on secrets, build identities, third-party components, and who can assert control over the SDLC.

Context

CISA's attestation form is a governance test, not just a compliance filing. It asks software producers to prove that secure development controls exist across the build chain, including source integrity, vulnerability review, and traceability for components that enter production.

The identity security angle is real even though the topic sits in software supply chain governance. Attestation credibility depends on whether humans, service accounts, build systems, and third-party tooling have controlled access to code, secrets, and release workflows.

The pressure point is evidence. Organisations that cannot show who touched the pipeline, what secrets were exposed, and how third-party components were verified will struggle to make the declarations the form requires.

Key questions

Q: Where do secure software attestation programmes fail in practice?

A: They fail when organisations cannot produce evidence that secure development controls actually operated across the pipeline. The most common gap is a mismatch between declared controls and observable records for build access, provenance, secrets handling, and vulnerability checks. If the proof is fragmented, the attestation becomes a paperwork exercise rather than a defensible assurance statement.

Q: Why do software attestations increase accountability for build and release identities?

A: Because CI/CD runners, deployment tokens, and automation accounts can alter code and artefacts, so they become part of the control evidence. If those non-human identities are not inventoried and governed, the organisation cannot credibly say its development process was secure. Attestation forces ownership, scope, and traceability for machine access that was previously implicit.

Q: What breaks when package age and provenance controls are missing in software supply chains?

A: Without package age and provenance controls, malicious releases can execute before teams have enough signal to detect them. That creates a short but dangerous trust window where a poisoned dependency behaves like legitimate code. The result is faster compromise, weaker containment, and more difficult rollback because the malicious artifact may already be embedded in builds or distributed to downstream environments.

Q: How should security teams respond when they cannot prove attestation claims?

A: They should pause sign-off, identify which control evidence is missing, and close the gap before making declarations. The immediate priority is usually to reconnect source, build, and secrets records so the organisation can support its statements. If that evidence cannot be reconstructed, independent review becomes necessary.

Technical breakdown

Secure software attestations depend on evidence, not policy language

An attestation only has value if the organisation can point to verifiable controls behind it. In practice, that means secure build environments, traceable source changes, dependency checks, and records showing when vulnerabilities were found and addressed. The form is less about a one-time declaration than about whether the software producer can maintain a defensible chain of custody for code from development through deployment. Where teams rely on manual sign-off or fragmented tooling, the evidence trail becomes too weak to support the statement being made.

Practical implication: map attestation claims to control evidence before signing anything.

Provenance is the control plane for software supply chain trust

Provenance answers where code came from, who changed it, and how it moved through the pipeline. For modern software delivery, provenance has to extend beyond internal code to third-party components, build outputs, and pipeline artefacts. Without that lineage, teams cannot separate trusted releases from tampered or unverified ones. This is why attestations increasingly force organisations to treat provenance as an operational control, not an after-the-fact audit artifact.

Practical implication: require lineage for source, dependencies, and build artefacts before release approval.

Secrets and build identities are part of attestation scope

The article's references to SDLC visibility and secrets detection matter because software supply chain risk is often enabled by credential exposure, over-broad build access, and uncontrolled automation. Build systems, CI/CD runners, and service accounts function as identities with privileges that can alter code, publish artefacts, or reach sensitive repositories. If those identities are not inventoried, scoped, and monitored, the organisation cannot credibly claim secure development control. The identity bridge here is direct: attestation depends on governance over the non-human identities that operate the pipeline.

Practical implication: include build identities and secrets in the same governance model as human administrative access.

Threat narrative

Attacker objective: The objective is to compromise the integrity of software releases and exploit the producer's supply chain trust to push untrusted code or artefacts downstream.

1. Entry occurs when insecure development environments, exposed secrets, or weak pipeline access allow an attacker or untrusted process into the software delivery chain.
2. Credential or build identity abuse follows when service accounts, tokens, or CI/CD permissions are used to reach source code, artefacts, or release systems.
3. Impact occurs when altered code, unverified dependencies, or tampered artefacts reach production, undermining trust in the software producer's attestation and delivery process.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Software attestations are only as strong as the evidence chain behind them. CISA has turned secure development from an internal assurance exercise into a declared control set that can be challenged. That changes the burden on software producers: they now need traceable proof for development environments, source handling, and vulnerability review. Practitioners should treat attestation as an evidence architecture problem, not a form-filling task.

Provenance is becoming the defining control for software trust. If an organisation cannot show where code originated, how dependencies were validated, and how artefacts were promoted, the attestation is little more than a statement of intent. This is why provenance, not just scanning, is central to supply chain governance. Teams should align release governance to provenance and traceability requirements, not just package hygiene.

Build identities are part of software governance, whether teams model them or not. CI/CD runners, deployment tokens, and automation credentials can modify code paths and release artefacts, so they must be governed as privileged non-human identities. That is where NHIMG's identity lens adds value: software supply chain assurance is also credential assurance. Practitioners should bring build identities into the same control ownership model as privileged human access.

Attestation debt: the gap between declared secure development and the controls needed to prove it. This article shows that many organisations still rely on a belief that policy statements can stand in for operational evidence. They cannot. The practical conclusion is to close the gap between what is signed and what is observable across SDLC, provenance, and secrets governance.

Third-party validation is a pressure signal, not a silver bullet. The recommendation to use external assessors reflects a wider problem: internal teams often do not trust their own evidence enough to self-assert compliance. External review can improve confidence, but it does not replace control ownership. Security leaders should use validation to test the quality of their governance model, not to outsource it.

What this signals

Attestation is pushing software governance toward proof-based control ownership. Teams that still manage source code, build systems, and secrets as separate concerns will struggle to defend the declarations CISA now expects. The practical shift is toward a single evidence model that links change control, provenance, and identity governance across the delivery chain.

Build and pipeline identities are now part of the software trust boundary. That boundary used to stop at the application. In attestation-driven programmes, it extends into service accounts, CI/CD tokens, and release automation, which means privileged access management and NHI governance must be folded into SDLC assurance.

Attestation debt will surface where organisations rely on manual compliance habits. The article points to a familiar pattern: teams can describe security intentions, but they cannot always show operational proof. The next stage for practitioners is to automate evidence capture for provenance, secrets, and vulnerability checks before audit pressure forces the issue.

For practitioners

• Tie attestation claims to control evidence Document the exact logs, approvals, scans, and inventory records that support each statement in the attestation form before anyone signs it.
• Inventory build and release identities List every CI/CD service account, token, and automation identity that can change source, build artefacts, or deployment paths, then assign ownership.
• Extend secrets detection across the SDLC Scan code, pipelines, repositories, and build logs for exposed credentials so the attestation covers real secret-handling practice, not intent.
• Track provenance for internal and third-party components Require lineage for source code, dependencies, and artefacts so release decisions can be traced back to verified inputs.
• Use external assessment where evidence is incomplete Engage an independent reviewer when the organisation cannot confidently demonstrate secure development controls from existing records.

Key takeaways

• CISA's attestation form shifts secure development from a statement of intent to a requirement for evidence across the software supply chain.
• The key weakness is not the declaration itself but the inability to prove provenance, secrets control, and vulnerability checking with durable records.
• Teams that cannot govern build identities and trace delivery lineage will struggle to make credible attestation claims.

Key terms

• Software Attestation: A mechanism for verifying that software of known origin and expected order is running before access is allowed. It gives infrastructure teams evidence that the requesting environment has not drifted from a trusted baseline.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.
• Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps security and platform teams connect identity governance to the operating model behind software delivery.