Verified identities in the SDLC are now a supply chain control

At a glance

What this is: This is a Secure SDLC guide that argues software security must be built into every phase, with verified identities and signed code as core defenses against supply-chain compromise.

Why it matters: It matters to IAM and NHI practitioners because developer identities, signing keys, and automation accounts are part of the same trust fabric as service accounts and other NHIs.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 30.9% of organisations store long-term credentials directly in code.

👉 Read Beyond Identity's guide to securing the software development lifecycle

Context

Secure SDLC means the development lifecycle treats security as a design requirement, not a late-stage check. For identity teams, that matters because code repositories, CI/CD systems, signing keys, and automation accounts all behave like non-human identities with their own trust boundaries and access paths.

The article focuses on the development and deployment risks that arise when identities are not verified, artifacts are not signed, or keys are not protected. That starting point is typical for organisations trying to harden the software supply chain, but it still leaves the broader NHI governance problem in view: who or what is allowed to change code, sign releases, and push trusted updates?

Key questions

Q: How should security teams govern developer identities in the SDLC?

A: Security teams should treat developer identities as privileged non-human and human access paths inside the delivery pipeline. That means using verified identities for repository writes, restricting branch access, logging every change, and reviewing who can approve builds or signing operations. The goal is to make code provenance traceable from commit to release.

Q: What is the difference between code signing and secure code provenance?

A: Code signing proves that an artifact was signed by a trusted key, while secure code provenance proves where the code came from and who changed it along the way. Signing is a release control. Provenance is a chain-of-custody control. Teams need both, because a legitimate signature does not help if the signing process was compromised.

Q: When does a CI/CD pipeline become a security risk?

A: A CI/CD pipeline becomes a security risk when it can accept unverified code, expose signing keys, or promote artifacts without strong controls on who approved the change. In that state, the pipeline can be used to distribute malicious software at scale. Teams should inspect identity, secrets, and approvals together.

Q: How can teams reduce software supply chain risk without slowing delivery?

A: Teams can reduce risk by automating security checks, limiting write access, and isolating release signing instead of adding manual gates everywhere. The key is to place controls where the highest trust transitions occur, such as commit, build, test, and sign. That preserves speed while shrinking the blast radius of a compromise.

Technical breakdown

Why verified identities matter for code commits

A verified identity requirement ties each commit to an accountable principal, which reduces anonymous or untraceable code changes in shared repositories. In practice, the control is about provenance rather than just authentication. If a malicious actor can write into a repository, the code review process alone may not detect intent, especially when the change is small or buried in dependency updates. Verified commit policies strengthen auditability and make downstream incident response more credible because teams can trace who approved or authored a change.

Practical implication: Treat repository write access as privileged access and require strong identity proofing before allowing commits.

Digital signatures, private keys, and trusted release pipelines

Software signing establishes integrity, but only if the signing keys are protected and the release path is tightly controlled. The weak point is not the signature algorithm itself, but the operational path to the private key. If attackers can access the key or manipulate the build process, they can produce code that appears legitimate to customers and internal systems. This is why release signing, secret storage, and build isolation have to be managed together rather than as separate controls.

Practical implication: Protect signing keys as high-value secrets and isolate signing from routine build activity.

Why automated testing belongs in CI/CD trust controls

SAST, SCA, and similar checks are often treated as quality gates, but they also function as trust validation for the pipeline. They reduce the chance that vulnerable dependencies or injected code reach release, especially when changes move quickly through automation. The control value increases when testing runs on every commit and every build artifact, not just before major releases. In secure SDLC terms, the pipeline itself becomes a control plane that must be continuously monitored and constrained.

Practical implication: Embed security testing directly into CI/CD so risky code is blocked before it can be promoted.

Threat narrative

Attacker objective: The attacker wants to turn a trusted software delivery path into a distribution mechanism for malicious code.

1. Entry occurs when an attacker gains the ability to submit code or alter a trusted library through a compromised developer identity or repository permission path.
2. Escalation happens when malicious changes are signed or otherwise validated by the release process, turning hostile code into trusted software.
3. Impact follows when customers deploy the signed update and execute attacker-controlled code inside their own environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Verified commit identity is an NHI control, not just a developer hygiene issue. When code contributors are not strongly bound to identity, repositories become attack surfaces rather than controlled collaboration systems. That matters because source control, CI/CD bots, and signing workflows are all non-human identities with privilege. Practitioners should treat code authorisation as part of the NHI program, not a separate DevOps concern.

Code signing creates trust only when signing keys are governed like production secrets. The article correctly treats compromised private keys as a release-path failure, but the broader lesson is that signing is only as strong as key custody, rotation, and access review. If the same automation account, pipeline, or service principal can reach signing material too broadly, the trust model collapses. Security teams should map signing keys into their secrets and privileged access controls.

Secure SDLC is a governance model for identity in motion. The lifecycle spans requirements, design, development, testing, deployment, and maintenance, which means identity controls must also span every phase. Security requirements in the design stage, verified commits in development, and signed artefacts at deployment are all checkpoints on the same chain. Teams that separate application security from identity governance will miss the real exposure, which is trust drift across the delivery pipeline.

Identity blast radius is the key concept this article surfaces. A single compromised commit path, signing key, or pipeline account can affect many downstream users because software distribution multiplies trust. That is the same structural problem NHI programmes face elsewhere: one identity with too much reach creates disproportionate exposure. Practitioners should reduce blast radius by segmenting pipeline privileges, tightening approvals, and limiting who can reach signing operations.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that exposure often outlasts detection and demands faster revocation.
• For lifecycle governance, the NHI Lifecycle Management Guide is the natural next step for teams mapping commit, sign, rotate, and offboard controls.

What this signals

Secure SDLC decisions increasingly sit inside the NHI programme because build systems, signing services, and deployment automation are identity-bearing assets. The practical shift is to govern those assets with the same discipline used for service accounts: least privilege, rotation, auditability, and explicit ownership.

Identity blast radius: the software supply chain can turn one compromised identity into many downstream compromises. That means practitioners should define who can commit, who can sign, and which automation accounts can promote artefacts before they scale trust across teams and environments.

The control question is no longer whether security exists in the pipeline, but whether the pipeline itself is governed as a critical access path. Teams that align SDLC controls with the NIST Cybersecurity Framework 2.0 will be better positioned to map identity risk to governance, detection, and recovery.

For practitioners

• Require verified identities for all repository writes Bind commit permissions to strongly authenticated developer identities, restrict direct writes to protected branches, and preserve an auditable trail for every change to source, test, and build infrastructure.
• Treat signing keys as high-value secrets Store private signing material in hardened secret stores, limit access to release automation only, and review every principal that can invoke signing or key export operations.
• Move security tests into the pipeline path Run SAST, SCA, and artifact validation on every build so vulnerable dependencies and injected code are rejected before release promotion.

Key takeaways

• Verified commit identity, not just code review, is what stops anonymous changes from entering trusted repositories.
• Release signing only works when private keys, build paths, and automation accounts are governed as high-value identities.
• Secure SDLC is ultimately a trust-boundary problem, and identity controls determine how far one compromise can spread.

Key terms

• Secure SDLC: A Secure SDLC is a software development process that embeds security into each lifecycle phase instead of treating it as a final check. It requires requirements, design, code, testing, deployment, and maintenance to all include controls that reduce vulnerabilities, supply chain exposure, and release-path abuse.
• Code Provenance: Code provenance is the chain of custody that shows where code came from, who changed it, and how it moved into release. It matters because a signed artifact is not enough on its own. Teams need traceability from the original commit through build and deployment to trust the result.
• Release Signing Key: A release signing key is the private credential used to digitally sign software or updates so recipients can verify integrity and authenticity. It is a high-value secret because compromise of the key can make malicious code appear legitimate. Governance should include access restriction, storage hardening, rotation, and monitoring.

Deepen your knowledge

Secure SDLC identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning developer access, signing keys, and pipeline governance, it is worth exploring.

This post draws on content published by Beyond Identity: Steps to Secure Your SDLC. Read the original.