CI/CD pipeline exposure in DevSecOps is still a governance gap

At a glance

What this is: This is an independent analysis of StepSecurity’s take on Datadog’s DevSecOps 2026 findings, centred on CI/CD and GitHub Actions supply chain exposure.

Why it matters: It matters because CI/CD workflows now carry production credentials and execution trust, so IAM and security teams must treat build systems as high-value identity and access environments.

By the numbers:

• Datadog found that 87% of organizations have at least one exploitable vulnerability, affecting 40% of all services.
• The median dependency is now 278 days behind its latest major version, up from 215 days last year.
• Only 4% pin the hash for all marketplace actions, while 71% never pin the hash for any of their actions.
• Datadog found that 1.6% of organizations using npm have used at least one malicious dependency in the past year.

👉 Read StepSecurity’s analysis of Datadog’s DevSecOps 2026 report and CI/CD risk

Context

CI/CD security is really about controlling which code, actions, and dependencies are trusted inside the software delivery path. When that path is under-governed, attackers can use build systems to reach production credentials, release pipelines, and downstream artifacts. In this article, StepSecurity uses Datadog’s DevSecOps 2026 report to argue that the risk is not abstract: workflow trust, dependency freshness, and runtime monitoring remain weak points.

The identity angle is genuine because GitHub Actions, developer machines, and AI-assisted development tools all operate with delegated access and reusable secrets. That makes CI/CD a non-human identity problem as much as a DevSecOps problem. The normal assumption that build infrastructure is ephemeral and low-risk does not hold when workflows can execute third-party code with high privilege.

StepSecurity’s framing is also typical of the current market: the attack surface is growing faster than manual review can keep up. The important question for practitioners is no longer whether supply chain compromise is possible, but which controls actually reduce blast radius before malicious code reaches production.

Key questions

Q: What breaks when GitHub Actions are not pinned to immutable references?

A: When actions are not pinned, the code that runs in a trusted workflow can change after review, which destroys the assumption that approval equals execution safety. A later malicious or compromised update can inherit the same trust, credentials, and network reach as the original action. That creates a hidden execution path into build and release systems.

Q: Why do CI/CD pipelines create non-human identity risk?

A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: Who is accountable when a compromised dependency exposes production secrets?

A: Accountability is shared across application, platform, and identity teams because the failure spans dependency control, secret exposure, and workload access governance. Security frameworks expect organisations to reduce attack surface, but the practical answer is to remove reusable secrets from places untrusted code can reach and to log every runtime credential handoff.

Technical breakdown

Why unpinned GitHub Actions create supply chain exposure

GitHub Actions workflows often execute third-party code inside trusted pipelines, which turns the action version into a security boundary. If teams reference tags rather than immutable commit SHAs, they inherit whatever code that tag points to later, including malicious updates or compromised releases. This is why pinning matters: it prevents silent change to the code running in privileged workflow context. The problem becomes worse when workflows also hold production secrets, sign artifacts, or deploy infrastructure. In that model, a compromised action is not just a tooling issue, it is an execution path into the delivery environment.

Practical implication: pin workflow actions to immutable commit SHAs and treat action updates like code changes, not routine library refreshes.

How release-day dependencies widen the trust window

Day-of-release adoption creates a trust gap between publication and sufficient security signal. New packages, images, or actions may be legitimate, but they also provide attackers a short window to publish lookalike or compromised versions before reputation, telemetry, or incident data can catch up. The same pattern applies to repositories, package registries, and container images. Organisations that move fastest are not automatically safer if they consume artefacts before those artefacts have earned trust. A cooldown policy narrows that exposure by forcing a minimum waiting period before adoption.

Practical implication: introduce a configurable cooldown for newly published dependencies and images, especially in high-privilege build paths.

Why runtime behaviour matters more than static checks alone

Static policy can block known bad versions, but it cannot fully predict malicious behaviour hidden inside a dependency or workflow step. Runtime monitoring closes that gap by observing file access, network activity, process spawning, and secret handling during execution. That is especially important in CI/CD because build jobs routinely have broad outbound connectivity and access to credentials that do not belong in ordinary application runtime. When a workflow behaves unexpectedly, the signal is behavioural, not just version-based. This is the difference between hoping a package is safe and verifying what it actually does under real conditions.

Practical implication: combine allowlisting and version pinning with runtime controls that can detect or block unexpected network and file-system behaviour.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted build automation into a secret-extraction and code-distribution channel that reaches production systems at scale.

1. Entry begins when an attacker compromises a workflow dependency, marketplace action, or release-day package that a CI/CD pipeline trusts.
2. Escalation follows when that code executes inside a privileged GitHub Actions context with access to build secrets, signing material, or deployment permissions.
3. Impact occurs when the compromised workflow exfiltrates credentials, alters builds, or expands access into downstream repositories and production systems.

NHI Mgmt Group analysis

CI/CD pipelines are now non-human identity environments, not just automation layers. GitHub Actions, developer machines, and package pipelines all depend on delegated access, reusable secrets, and code execution rights. That makes them an NHI governance problem as much as a DevSecOps problem. The control question is who and what is allowed to act inside the delivery system, under which constraints, and with what blast radius. Practitioners should therefore treat workflow identities as governed assets, not background tooling.

Unpinned actions create a standing-trust problem that most teams still underestimate. A tag is not a security boundary if the referenced code can change after review. This is a classic lifecycle failure because the trust decision happens once while execution happens repeatedly. StepSecurity’s analysis is a reminder that build-time privilege should be constrained as tightly as production privilege. Teams need immutable references, action allowlists, and monitoring that assumes upstream compromise is always possible.

Day-of-release adoption has become a governance anti-pattern in fast-moving software supply chains. The industry still behaves as though speed and safety are opposing goals, but the real issue is unmanaged trust latency. When organisations consume packages or images before they have earned sufficient confidence, they inherit the attacker’s timing advantage. The practical conclusion is that freshness must be paired with verification, or accelerated delivery becomes accelerated exposure.

Runtime controls are where supply chain governance becomes enforceable. Static checks can reduce obvious risk, but they do not stop a malicious dependency from behaving differently at execution time. Behavioural inspection, egress control, and artifact policy shift the model from assumed trust to observed trust. For identity and access teams, that means CI/CD should sit inside the same governance conversation as privileged access and secrets management. The field should move from code review alone to execution control.

Blast-radius control is the named concept that best captures this problem space. The article’s core message is that security teams must understand not just whether a workflow is trusted, but how far a compromised workflow can move if trust fails. That requires mapping secrets, permissions, outbound paths, and downstream dependencies together. The practitioner takeaway is to design pipeline governance around containment first, because compromise in CI/CD is now a propagation problem, not a single-system event.

What this signals

CI/CD governance is converging with identity governance because the delivery pipeline now carries credentials, trust decisions, and execution privileges. Teams that still separate DevSecOps from identity control will continue to miss the point where compromise becomes propagation. The practical shift is toward governing workflow identities, not only repository permissions.

Blast-radius control: the defining design principle for modern pipeline security is no longer preventing every risky dependency, but limiting what a compromised workflow can reach. That means shorter credential lifetimes, narrower scopes, and stronger runtime containment across build infrastructure.

For identity and security programmes, this also means CI/CD belongs in the same operational review cycle as secrets management and privileged access. The more AI-assisted development accelerates code flow, the more important it becomes to verify execution paths, not just code provenance.

For practitioners

• Pin every marketplace action to an immutable reference Use full-length commit SHAs for all third-party GitHub Actions, then enforce that requirement with repository checks so tag drift cannot change execution after review.
• Add a release-day cooldown gate for dependencies Block newly published packages, images, or actions for a configurable waiting period so teams do not consume artefacts inside the attacker’s highest-risk exposure window.
• Treat workflow secrets as high-risk credentials Inventory which secrets, tokens, and signing keys are reachable from each workflow, then reduce scope so a compromised job cannot access more than it needs.
• Enable runtime monitoring on privileged builds Monitor network traffic, file-system access, and process behaviour during CI/CD runs so unexpected exfiltration or execution paths are visible before they propagate further.

Key takeaways

• The article shows that CI/CD compromise is now a workflow identity problem as much as a supply chain problem.
• Datadog’s figures reinforce that dependency lag, release-day adoption, and unpinned actions create a measurable trust gap.
• Practitioners should move from static approval to execution control, with pinning, cooldowns, and runtime inspection as the baseline.

Key terms

• CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
• Dependency Pinning: Dependency pinning means fixing a project to specific package versions instead of always pulling the newest release. It reduces surprise upgrades and gives security teams time to evaluate whether a new package version is trustworthy before it enters production.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Release Cooldown: A time delay applied before a newly published package or update can be adopted by automated systems. It reduces the chance that poisoned releases move immediately into production and gives defenders time to detect, validate, and block suspicious changes.

What's in the full article

StepSecurity's full blog covers the operational detail this post intentionally leaves for the source:

• How StepSecurity maps Datadog’s findings to specific GitHub Actions controls and pipeline protections.
• Step-by-step descriptions of runtime monitoring, action pinning, and compromised-package checks in build workflows.
• Operational examples of how release cooldowns and maintained actions are applied in real CI/CD environments.
• Product-specific guidance on extending protection to developer machines and AI-assisted coding tools.

👉 The full StepSecurity post covers pipeline controls, dependency timing, and runtime protections in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build governance that fits modern identity and access risk across automation and hybrid environments.