Verified identities in the SDLC are now a supply chain control

At a glance

What this is: This article says Secure SDLC needs verified identities for commits and signatures because untrusted code can move through development and deployment as a supply chain risk.

Why it matters: It matters because IAM, PAM, and software supply chain governance now intersect where commit trust, signing keys, and CI/CD controls determine whether code provenance is defensible.

Context

The core issue is not software development speed, but trust in who or what is allowed to introduce code into the pipeline. Once a repository, build step, or release process accepts unverified identities, provenance becomes harder to prove and malicious or vulnerable code can travel downstream as if it were legitimate.

In a Secure SDLC, identity is part of the control plane for code creation, review, signing, and release. That makes commit identity, signature validation, and key custody governance concerns rather than narrow engineering preferences.

The article’s focus is typical of modern supply chain risk: the same control weakness can affect internally written code, third-party libraries, and release artefacts. That is why SDLC security now sits at the intersection of application security, identity governance, and build integrity.

Key questions

Q: What breaks when code commits are not tied to verified identities?

A: When commit identity is weak, a repository stops being a trustworthy record of authorship and becomes an easy ingress path for backdoors, vulnerabilities, and unauditable changes. Security teams lose reliable attribution, incident response becomes slower, and malicious code can be blended into ordinary development traffic before anyone notices.

Q: Why do signing keys need the same governance as other privileged secrets?

A: Signing keys can authorise code that downstream systems treat as trusted, which gives them privileged blast radius. If those keys are exposed or loosely managed, attackers can generate rogue but authentic-looking artifacts. Treat them as high-value secrets with restricted access, strong storage, and full auditability.

Q: How do teams know if SDLC security tooling is actually working?

A: It is working when findings are reduced to the issues that matter most, remediation happens without breaking releases, and secrets are blocked before they land in shared history. Useful signals include lower alert noise, faster safe fixes, and fewer privileged credentials embedded in code or pipeline configuration.

Q: What should teams do when vulnerable code enters the pipeline anyway?

A: Treat the event as a provenance failure as well as a code-quality issue. Contain the affected branch or release path, validate every artefact downstream of the change, and review whether commit rights, signing authority, or pipeline approvals allowed the change to propagate.

Technical breakdown

Verified identities for code commits

A verified commit model ties repository changes to an authenticated identity so the organisation can distinguish approved code from arbitrary submissions. In practice, this is not just about user authentication at login. It is about binding authorisation to the act of contribution, preserving auditability, and making repudiation harder when suspicious code appears. If anyone can commit directly, a repository becomes a permissive ingress point for vulnerabilities, backdoors, and policy bypasses. In SDLC terms, commit trust is a provenance control, not a developer convenience. It has to work across human developers, service accounts, and any automation that can write to source control.

Practical implication: require verified identities for write access to repositories and tie commit attribution to reviewable identity records.

Digital signatures and signing key custody

Digital signatures prove that code or an update came from a holder of the private signing key and that the artefact was not altered after signing. The control only works if key custody is sound, because a compromised signing key turns trusted release mechanics into an attack path. That is why signature validation, key protection, and release authority must be governed together. The SolarWinds example shows the failure mode clearly: if malicious code can be legitimately signed, downstream users see a trusted update, not an obvious intrusion. In a Secure SDLC, signing is therefore a trust boundary, not a packaging step.

Practical implication: protect signing keys as high-value credentials and verify signatures before release promotion or deployment.

Automated security testing inside CI/CD pipelines

Automated security testing moves detection earlier by checking code while it is being committed, built, and assembled rather than waiting until late-stage testing or production. Static application security testing, software composition analysis, and related checks reduce the chance that vulnerable dependencies or known flaws are released simply because they were discovered too late. The operational value is not just faster feedback. It is a narrower window in which bad code can persist unchallenged. In SDLC governance, automation needs to be paired with identity assurance, because testing can identify risk in code but cannot by itself prove who introduced it.

Practical implication: embed SAST and SCA into CI/CD so security checks run before unverified or vulnerable code reaches release stages.

Threat narrative

Attacker objective: The attacker aims to get malicious code accepted as trusted software so it can spread through build and deployment chains.

1. Entry occurs when an attacker or untrusted actor is able to submit code, library changes, or release artefacts into a repository or pipeline without verified identity controls.
2. Credential or signing-key abuse follows when a private key, commit path, or release mechanism is used to make malicious code appear legitimate.
3. Escalation happens when trusted build and deployment workflows propagate that code to wider internal or customer environments under valid provenance.
4. Impact is achieved when downstream teams or customers execute code they believe is authentic, allowing backdoors, vulnerabilities, or malicious updates to persist in production.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

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

Verified commit identity is now a provenance control, not a developer workflow detail. The article is correct to frame commit authenticity as part of Secure SDLC governance because the repository is where supply chain trust begins. If unverified identities can write to source control, the organisation loses a reliable link between code change and accountable actor. The practitioner implication is that source control access must be governed as a security boundary.

Code signing only works when signing authority is treated like privileged access. Digital signatures are often discussed as integrity checks, but the actual control point is custody of the private key and the conditions under which it can be used. Once that key is exposed or misused, downstream consumers have no easy way to distinguish legitimate release activity from attacker-authored output. The implication is that signing keys belong in the same governance conversation as other high-risk credentials.

Secure SDLC is increasingly an identity problem across both human and machine actors. Developers, build automation, and release tooling all participate in code provenance, so the organisation has to know which identities can create, approve, or promote software artefacts. That widens the governance surface beyond individual laptops and into CI/CD trust boundaries. The practitioner implication is to align source control, signing, and release permissions under one identity model.

Automated testing reduces exposure, but it does not replace provenance assurance. SAST and SCA can catch vulnerable code, yet they do not answer the more fundamental question of whether the right identity introduced the change in the first place. That distinction matters when supply chain attacks use legitimate-looking artefacts to bypass detection. The practitioner implication is to govern both code quality and code origin.

Identity assurance in the SDLC should be treated as part of software supply chain resilience. As development pipelines absorb more automation and more third-party dependencies, trust has to be verified at commit, build, and release stages rather than assumed at deployment. That shifts the governance burden from after-the-fact inspection to upstream control of who can shape the software. The practitioner implication is to harden the pipeline as a provenance chain.

What this signals

Provenance is becoming an identity governance problem inside software delivery. SDLC controls now have to answer who can introduce code, who can approve it, and who can sign it before it reaches customers. That pushes source control, release signing, and CI/CD permissions into the same governance model rather than leaving them in separate operational silos.

Code signing is only as strong as the identity behind the key. Once release authority is tied to a compromised or poorly governed signing key, the integrity control becomes a trust amplifier for attacker-controlled output. Security teams should therefore treat signing custody and release authority as one control surface, not two.

For practitioners

• Enforce verified commit identities Require authenticated, reviewable identities for repository writes and block direct commits from unknown or unapproved actors.
• Protect signing keys as privileged credentials Store code-signing keys with strict access control, monitoring, and separation from routine developer access because a compromised key can legitimise malicious releases.
• Embed SAST and SCA into CI/CD Run static analysis and dependency checks before merge or release so vulnerable code is caught while remediation is still practical.
• Bind release approval to provenance checks Require signature verification and source attribution checks before deployment promotion so untrusted artefacts do not inherit release trust.
• Scan active applications for emerging flaws Continue vulnerability scanning after release because maintenance-stage changes and updated libraries can reintroduce risk into previously stable code.

Key takeaways

• Secure SDLC now depends on verifying who can change code, not just whether the code passes tests.
• The article ties malicious release risk to the trust chain that starts at commit and ends at signing.
• Teams should govern repository access, signing keys, and pipeline checks as one provenance control set.

Key terms

• Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
• Verified identity: Verified identity is an access model where the person or account behind a session is strongly proven before permission is granted. In MedTech, that usually means binding authentication to a specific device and trusted credential source so login can support operational risk decisions.
• Digital Signature: A verifiable cryptographic result created with a private key and checked with the matching public key. In identity systems, it is used to prove possession of a secret without revealing that secret, which makes it useful for authentication and non-repudiation.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.