CISA software attestations expose supply chain governance gaps

At a glance

What this is: This is a breakdown of CISA’s secure software development attestation requirements and the SDLC controls software producers must be able to evidence.

Why it matters: It matters because IAM, PAM, and NHI governance teams must treat build systems, APIs, and development secrets as governed identities and access paths, not just engineering conveniences.

👉 Read OXSecurity's breakdown of CISA software attestation requirements

Context

CISA’s attestation form is a governance test for software producers, not just a compliance exercise. The core question is whether teams can prove that software was built in secure environments, with controlled provenance, vulnerability scanning, and accountable sign-off across the software supply chain.

For identity and access practitioners, the hidden issue is that development pipelines depend on non-human identities, secrets, and privileged automation at scale. If those identities are not inventoried, scoped, and monitored, the attestation becomes a statement of intent rather than an auditable control boundary.

Key questions

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. That gap makes compliance claims hard to defend and leaves supply chain risk hidden inside ordinary delivery workflows.

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. If those credentials are long-lived or poorly scoped, an attacker can use them to undermine both software integrity and the assurance claims behind the attestation.

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. Provenance only works when the organisation can link source, build inputs, signing actions, and release approvals into one auditable chain with accountable ownership at each stage.

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.

Technical breakdown

Secure development environments and software provenance

The attestation expects producers to show that software is built in a controlled environment and that internal code plus third-party components can be traced back to their origin. That means build systems, package repositories, CI/CD runners, and artifact stores all need integrity controls, logging, and change traceability. Provenance is not just documentation. It is the ability to reconstruct how an artifact was produced, which inputs were used, and whether anything altered the path between source and release.

Practical implication: Map every build path and artifact source to a named owner and enforce evidence retention for release provenance.

Secrets detection across the SDLC

Secrets scanning matters because exposed credentials in source repositories, build logs, and pipeline variables can invalidate the trust model behind the attestation. A secret is any credential, token, API key, or certificate that can be abused to impersonate a system or developer action. In modern delivery pipelines, these secrets often belong to non-human identities with broad operational reach, so a single exposed token can create both supply chain and identity risk.

Practical implication: Scan code, logs, images, and pipeline variables continuously for secrets and remove standing credentials from automation wherever possible.

Vulnerability checks and third-party component governance

Regular vulnerability checks are only useful if the organisation can connect scan results to the specific software version, dependency set, and deployment path in scope. That is why software bill of materials data, dependency lineage, and issue management have to work together. The attestation is not satisfied by a one-time scan. It depends on repeatable assurance that vulnerabilities are identified, assigned, and tracked through remediation in the same systems that produce the release.

Practical implication: Tie dependency findings to software versions and require remediation ownership before release approval.

Threat narrative

Attacker objective: The attacker aims to compromise the software supply chain so malicious or untrusted code is shipped while provenance and accountability are weakened.

1. Entry occurs through exposed build-time credentials, overly broad pipeline access, or compromised third-party components used in the software development lifecycle.
2. Escalation follows when those credentials or components allow an attacker to alter code, inject dependencies, or manipulate build and release artefacts.
3. Impact is the production of untrusted software or the loss of provenance needed to prove software integrity to regulators and customers.

NHI Mgmt Group analysis

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.

Secrets in the SDLC are now a governance issue, not a narrow application-security defect. Build secrets, API keys, and pipeline tokens are non-human identities with real authority, and they often sit outside traditional IAM review cycles. Once those identities are embedded in automation, a single leak can affect both software integrity and regulated attestations. The practical conclusion is that NHI governance has to extend into developer tooling and release engineering.

Software provenance depends on identity controls at machine speed. Provenance maintenance only works when access, signing, and release actions are attributable to the right system or operator at the right time. That places build service accounts, signing keys, and deployment tokens squarely inside the governance perimeter. If those identities are not lifecycle-managed, provenance becomes an after-the-fact claim instead of a control.

Supply chain assurance is converging with identity assurance. The article shows how inventory, scanning, and policy enforcement are now inseparable from who or what can modify code and artefacts. This is exactly where IAM, PAM, and NHI programmes need a shared control view with security engineering. Practitioners should treat software attestation as a cross-functional identity assurance exercise, not a compliance artefact.

What this signals

Build pipelines are becoming a primary identity perimeter. As software attestation requirements tighten, organisations need to treat CI/CD accounts, signing keys, and release tokens as governed identities with clear lifecycle control. The practical signal for security programmes is that a provenance gap now functions like an access-control gap, and both should be measured in the same governance cycle.

The attestation pressure will push more ownership into platform and security engineering teams, but the real differentiator will be whether those teams can produce evidence on demand. For identity practitioners, the right next move is to align NHI inventory, secret rotation, and release approval workflows so a compliance request does not expose invisible privilege.

For practitioners

• 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. Assign ownership, expiry, and review cadence to each identity so the attestation can be supported by a real control map rather than an assumed one.
• Remove standing secrets from pipelines Replace long-lived pipeline credentials with short-lived, scoped alternatives where possible and enforce rotation for the rest. Extend scanning to repositories, build logs, and environment variables so exposed secrets are found before they become proof that the attestation is unreliable.
• Link provenance to release approval Require release sign-off to reference the exact build artefact, dependency set, and provenance record that produced it. This creates a verifiable chain from source to production and makes it harder for tampering or unauthorised substitution to hide inside a normal release flow.
• Bind vulnerability findings to software versions Make sure scanning results are mapped to the version actually deployed, not just the repository state at the time of scan. This helps prevent attestations from relying on stale evidence when dependency drift or delayed remediation changes the risk profile after the fact.

Key takeaways

• CISA’s attestation turns software delivery into an evidence-backed governance problem, not a simple policy declaration.
• Non-human identities in build and release pipelines are central to both provenance and compliance risk.
• Teams that cannot inventory, scope, and audit release credentials will struggle to defend software integrity claims.

Key terms

• Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.
• 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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

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.

👉 OXSecurity's full post covers the attestation fields, SDLC control mapping, and platform workflow details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to operational evidence across modern delivery environments.