TL;DR: CI/CD pipelines become attractive attack paths when speed, automation, and weak identity controls let malicious or unverified code slip through, according to Beyond Identity’s analysis of pipeline security practices. The practical lesson is that code integrity and commit identity must be enforced continuously, not only at release time.
At a glance
What this is: This is an analysis of CI/CD pipeline security best practices, centred on verified code integrity, device-based access controls, and continuous commit identity checks.
Why it matters: It matters because DevOps pipelines now sit inside identity governance as a control point for code provenance, developer access, and supply-chain trust.
Context
CI/CD pipeline security is the discipline of protecting software delivery workflows from tampering, untrusted access, and code integrity failures. In this article, the primary problem is not developer speed itself but the governance gap created when identity checks and integrity checks are delayed until the end of the pipeline.
For IAM and NHI teams, the important connection is that pipeline access is an identity problem as much as a software delivery problem. When commit provenance is weak, shared devices are allowed, or source code integrity is only checked at release time, the development pipeline becomes a trusted path for malicious change.
Key questions
Q: What breaks when CI/CD security is only checked at release time?
A: Release-time-only controls miss tampering that happens earlier in the pipeline. Malicious code can be introduced, built, and even signed as part of a legitimate release, which means the final gate may confirm delivery but not provenance. Security teams need controls that validate commits, dependencies, and build inputs before the release artifact exists.
Q: Why do untrusted developer devices increase CI/CD pipeline risk?
A: Because a valid user on an untrusted endpoint can still clone, modify, or exfiltrate code outside corporate trust boundaries. Device posture matters when the repository itself is a source of intellectual property and supply-chain trust. Access decisions should therefore include endpoint security, not just user authentication.
Q: How do teams know if identity security controls are actually working?
A: Identity security controls are working when teams can show a current view of high-risk entitlements, detect privilege drift quickly, and remove access before exposure spreads. A useful sign is reduced time between entitlement change and policy review. Another is fewer unresolved conflicts between approved access and actual production permissions.
Q: What is the difference between release signing and source-code integrity?
A: Release signing confirms that a final artefact was approved, while source-code integrity proves that the content being released was not tampered with earlier in the lifecycle. A valid signature cannot restore trust if malicious changes were inserted upstream. Practitioners need both provenance and release assurance, not one in place of the other.
Technical breakdown
Shift-left security in CI/CD pipelines
Shift-left security moves checks earlier in the software delivery lifecycle so that code, dependencies, and pipeline actions are validated before they become release artifacts. In CI/CD, this matters because the pipeline is not a single gate but a chain of build, test, sign, and deploy steps, each with its own trust assumptions. If security is applied only at the end, malicious changes can travel through multiple trusted stages and still look legitimate at release. The real control problem is not only detection, but where trust is enforced in the workflow.
Practical implication: move integrity and identity validation into the earliest feasible pipeline stages, not just the final release gate.
Device-based access controls for code repositories
Device-based access controls tie repository access to the security posture of the requesting endpoint, not just the user or service account. That matters because developers often work from unmanaged, dual-use, or personal devices that may not meet corporate security requirements. If source code is cloned or modified on untrusted machines, the organisation loses confidence in both confidentiality and integrity. This is a governance issue because the developer identity may be valid while the device context is not. Strong pipeline security therefore treats device trust as part of commit trust.
Practical implication: restrict repository access to compliant devices and treat endpoint trust as part of source-code governance.
Verified commit identity and source-code integrity
Verified commit identity links each change to a known, trusted author at the point of commit, while source-code integrity controls detect whether code or dependencies were altered at any stage. The SolarWinds example in the article shows why end-of-pipeline signing alone is insufficient: if malicious code is inserted upstream, a valid final signature can still wrap untrusted content. That creates a false sense of assurance. The technical requirement is continuous provenance, not just signed release output, so the organisation can tell whether the change history itself is trustworthy.
Practical implication: require verified commit identity and integrity checks that follow code through build, test, and release.
Threat narrative
Attacker objective: The attacker’s objective is to insert malicious code into a trusted software supply chain and deliver it at scale through legitimate release processes.
- Entry occurs when an attacker gains access to the development environment or pipeline path and can influence code or build content before release.
- Credential or trust abuse follows when the pipeline accepts changes, signatures, or release artefacts without verifying that every commit and component is legitimate.
- Impact occurs when malicious code is bundled into a trusted software release and distributed to downstream customers as if it were safe.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
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
CI/CD pipeline integrity is an identity control, not just a DevOps control. The article shows that code provenance, repository access, and release trust all depend on being able to prove who or what changed the pipeline. That makes the pipeline part of identity governance rather than a separate engineering concern. Practitioners should treat commit identity and build provenance as governance controls, not optional hardening.
Verified commit identity is the missing trust anchor in many pipeline security models. A signed release does not prove the entire path was trustworthy if unverified changes were allowed upstream. That is why continuous provenance matters more than a final-stage approval. Practitioners should assume that release-time controls cannot recover lost trust earlier in the chain.
Device trust belongs in source-code governance because valid users can still operate from untrusted endpoints. BYOD and remote work create a gap between who is acting and from where they are acting, and that gap can invalidate pipeline assurance even when credentials are correct. This is where IAM, endpoint posture, and DevOps controls intersect. Practitioners should align repository access with device assurance, not user identity alone.
Source-code integrity is the control that prevents a trusted pipeline from becoming a distribution channel for tampered software. The SolarWinds example in the article shows that one trusted release can conceal many prior trust failures. That is why integrity must be evaluated across the full development lifecycle, including third-party components. Practitioners should govern provenance end to end, not only at publication time.
Identity proof at commit time reduces the blast radius of compromised development workflows. When each change is tied to a verified identity, malicious edits become easier to attribute and harder to blend into normal developer activity. This does not eliminate supply-chain risk, but it changes the control model from passive inspection to enforceable provenance. Practitioners should make commit verification a baseline pipeline requirement.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Code provenance has become a governance boundary, not just an engineering detail. When a pipeline accepts changes without strong identity proof, release signatures can become a false comfort rather than evidence of trust. Teams responsible for IAM and DevOps governance should treat commit verification as part of access control, not a downstream quality check.
Pipeline identity controls and endpoint controls now need to move together. A trusted user on an untrusted machine is still a supply-chain exposure, especially in environments where developers work from personal or dual-use devices. Organisations that separate repository access from device posture will keep inheriting avoidable integrity risk.
According to the Ultimate Guide to NHIs, 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That figure reinforces the practical point here: pipeline governance has to cover where credentials and code actually live, not just where policy says they should live.
For practitioners
- Enforce shift-left integrity checks Validate code, dependencies, and pipeline actions before release artifacts are produced, so malicious changes do not pass through later trust gates unchanged.
- Restrict repository access to compliant devices Require endpoint posture controls for code repositories so developers only access source from devices that meet corporate security requirements.
- Tie every commit to a verified identity Require each commit to be signed or otherwise bound to a known corporate identity before it can enter the repository or build flow.
- Check source-code integrity across the full lifecycle Monitor source code and third-party components for tampering during build, test, and release, not just at the final signing step.
Key takeaways
- CI/CD pipeline security fails when identity and integrity checks are delayed until the end of the delivery process.
- The article’s SolarWinds example shows how a trusted release can still conceal upstream tampering in code or components.
- Verified commit identity and device-based access controls are the controls most likely to reduce pipeline trust failures in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Pipeline and repository workflows can expose secrets and trust material during development. |
| NHI-05 — Overprivileged NHI | CI/CD service access often exceeds what the pipeline actually needs. | |
| NHI-10 — Human Use of NHI | Developer workflow trust depends on humans using verified identities and approved devices. | |
| Recommendation — Scan pipeline paths for leaked credentials and block builds that expose secrets in code or logs. Reduce pipeline and repository privileges to the minimum required for each build step. Bind developer actions to verified identities and prevent informal reuse of trusted pipeline access. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | CI/CD compromise often starts with credential access and expands through pipeline trust paths. |
| Recommendation — Map pipeline abuse to credential access and lateral movement to prioritise detection around build systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Commit identity and pipeline access both depend on strong authenticator lifecycle controls. |
| Recommendation — Apply authenticator management to issued credentials used in CI/CD and revoke stale pipeline access. | ||
Key terms
- CI/CD Pipeline Security: CI/CD pipeline security is the practice of protecting the software build, test, and deployment process from tampering, misuse, and unauthorized access. It covers source control, build systems, secrets, artifacts, runners, approvals, and release controls, with identity checks, least privilege, integrity validation, and auditability across every stage.
- Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
- Verified Commit Identity: A control that binds each code commit to a trusted, attributable identity so the organisation can tell who made a change and whether that change was authorised. In CI/CD governance, it helps distinguish legitimate developer activity from tampering, shared-account use, or untraceable pipeline edits.
- Device-Based Access Control: An access control model that considers the security state of the endpoint, not only the user or account requesting access. For code repositories and pipeline systems, it limits exposure by requiring trusted, compliant devices before sensitive source code or build systems can be reached.
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.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org