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

At a glance

What this is: StepSecurity argues that Datadog's 2026 DevSecOps data confirms CI/CD pipelines and GitHub Actions remain exposed to supply chain abuse, especially where workflows run with production-level trust.

Why it matters: This matters because identity and access controls for build systems, workflows, and non-human execution paths now shape supply chain blast radius as much as code quality or vulnerability management.

By the numbers:

• 87% of organizations have at least one exploitable vulnerability in deployed services, affecting 40% of all services, according to Datadog's State of DevSecOps 2026 report cited by StepSecurity.
• The median dependency is 278 days behind its latest major version, up from 215 days last year, according to Datadog's State of DevSecOps 2026 report cited by StepSecurity.
• 50% of organizations use third-party libraries within a day of release, according to Datadog's State of DevSecOps 2026 report cited by StepSecurity.
• Only 4% of organizations pin the hash for all marketplace GitHub Actions, while 71% never pin the hash for any of their actions, according to Datadog's State of DevSecOps 2026 report cited by StepSecurity.

Context

CI/CD pipelines are not just build infrastructure. They are trusted execution environments that can read secrets, fetch dependencies, publish artifacts, and trigger downstream deployment activity. When those workflows are loosely governed, the build layer becomes a supply chain control point rather than a neutral delivery mechanism.

The identity angle here is real because GitHub Actions, service credentials, and other non-human execution paths often operate with more privilege than the human developers who manage them. In practice, that means access scope, action pinning, and runtime guardrails determine whether a compromised workflow becomes a contained event or a platform-wide exposure.

Key questions

Q: What breaks when CI/CD workflows are allowed to run unpinned third-party actions?

A: Unpinned actions turn workflow execution into a moving target, because a trusted tag can later point to compromised code. That breaks provenance, makes approval meaningless over time, and expands blast radius when the workflow also holds secrets or deployment rights. Teams should treat the action reference itself as a security control, not just a convenience for updates.

Q: Why do privileged build workflows increase supply chain risk so quickly?

A: Privileged build workflows concentrate secret access, artifact creation, and release authority in one execution path. If that path is compromised, attackers can reach credentials, alter outputs, and pivot into downstream systems without needing a separate breach. The risk rises because build runners often inherit trust that was designed for human-controlled release processes, not hostile code execution.

Q: What are the signs that CI/CD secret governance is failing?

A: Common warning signs include shared secrets across multiple pipelines, credentials stored in workflow files or build variables, broad access to secret brokers, and unclear ownership for rotation or revocation. Another signal is when teams cannot explain which workflow minted a credential or why it still exists. Those conditions indicate the platform has weak lifecycle governance, not just a tooling gap.

Q: How should teams respond when a pipeline dependency or action is compromised?

A: They should first stop further execution of the affected workflow, revoke or rotate any exposed secrets, and identify which repositories or release paths used the compromised component. Then they should assess whether the compromise reached build artifacts, logs, or downstream deployment systems before restoring normal workflow access.

Technical breakdown

Why GitHub Actions become a trust boundary problem

GitHub Actions workflows often execute third-party code inside a privileged runner, which means the workflow itself becomes a policy decision rather than a simple automation step. If actions are unpinned, tags can move underneath the control owner, and if the workflow can access production credentials, the runner inherits far more power than most teams realise. This is a classic trust-boundary failure: the pipeline assumes the dependency chain is safe because it is convenient, not because it is verified. Once a workflow can read secrets, write artifacts, or open outbound connections, it has become part of the attack surface, not just the delivery path.

Practical implication: Treat workflow identity and action provenance as control points, not implementation details.

How day-of-release dependencies and unpinned actions widen blast radius

Release-day dependency use creates a narrow but dangerous exposure window because malicious packages are most likely to be weaponised immediately after publication. In CI/CD, that risk is amplified when build steps automatically trust new dependencies or marketplace actions without cooldown, pinning, or runtime inspection. The result is that the pipeline can import malicious code before anyone has had time to evaluate it. Blast radius grows because the same workflow often touches repositories, release artifacts, and cloud credentials in one execution chain. That is why supply chain governance has to cover both pre-execution trust decisions and what the runner is allowed to do once code is live.

Practical implication: Apply release cooldowns and immutable references before a workflow can consume external code.

Runtime monitoring is now part of CI/CD identity control

Static review cannot see every malicious behaviour because a compromised action or package may only reveal itself when it starts making network calls, reading files, or exfiltrating secrets at runtime. That is where runtime monitoring changes the model. Instead of asking only whether a workflow was approved, teams need to ask whether the running process behaved like the approved process. This matters for non-human identities because the build runner is acting as an identity-bearing system with delegated authority. If that delegated authority is abused, the right control is behavioural containment, egress restriction, and immediate cancellation of suspicious execution.

Practical implication: Add behavioural controls that can stop a workflow even after it has passed static checks.

Threat narrative

Attacker objective: The attacker wants to convert a trusted build or deployment workflow into a credential and code-execution channel that spreads compromise downstream.

1. Entry occurs when attackers poison a GitHub Actions workflow, compromised marketplace action, or fresh dependency that a pipeline trusts automatically.
2. Credential access follows when the workflow reads CI secrets or production credentials that were available to the runner.
3. Escalation and lateral movement happen when those secrets are used to alter release artifacts, tamper with downstream repositories, or pivot into additional build and deployment systems.
4. Impact is secret exposure, malicious code execution, and supply chain compromise at the workflow and artifact layer.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.

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 governance now sits at the centre of supply chain security: the decisive question is no longer whether a pipeline exists, but whether its execution path is governed like a privileged identity. Workflows that can mint artifacts, read secrets, and call external services are operating as delegated non-human identities. That means access scope, provenance, and runtime behaviour need to be governed together, not as separate hygiene tasks. Practitioners should treat the pipeline as a high-value control plane, not a convenience layer.

The named concept here is workflow blast-radius control: the article's core point is that teams must understand exactly what each workflow can reach if it is compromised. Unpinned actions, release-day dependencies, and broad secret access all increase the reachable surface of a single bad execution. This is not a visibility problem alone; it is a privilege design problem. Practitioners need to model each workflow's reachable identities, repositories, and deploy targets before they assume monitoring will be enough.

Build infrastructure still receives weaker governance than production systems: that mismatch is why CI/CD compromise keeps recurring. Teams often harden endpoints and cloud workloads while leaving runners, marketplace actions, and pipeline secrets under-governed. The governance gap is especially sharp where humans approve code but non-human actors execute it. Practitioners should align build security with the same privilege, review, and containment standards they apply to other critical production paths.

GitHub Actions hardening is becoming an identity discipline, not just a DevOps task: when a workflow is allowed to run arbitrary third-party code, it effectively becomes an execution principal with delegated authority. That shifts the security question from code quality to control of delegation. The right response is to constrain what can execute, what it can inherit, and how quickly it can be stopped when its behaviour diverges. Practitioners should govern delegation chains the same way they govern privileged human access.

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: CI/CD Pipeline Identity Security Guide

What this signals

Workflow blast-radius control: CI/CD security now depends on understanding what each runner can reach if its code, action, or dependency is compromised. The governance gap is no longer just about visibility into pipelines, but about limiting delegated authority before execution begins.

The practical lesson for security programmes is that build infrastructure needs the same privilege and containment discipline as production systems. That means pinning actions, limiting secret scope, and adding runtime interruption where suspicious behaviour appears, rather than relying on review alone.

For practitioners

• Pin every GitHub Action to an immutable reference Require full-length commit SHA pinning for all marketplace and third-party actions so tags cannot drift into compromised versions. Enforce the rule through repository policy, not developer memory.
• Add cooldown controls for fresh dependencies Block new packages and release-day dependencies for a short review window before they can enter build pipelines. Use that window to confirm the package is legitimate and not part of an active campaign.
• Restrict workflow secret access by privilege scope Limit each runner to the smallest secret set and deployment target it actually needs. Separate build, test, and release credentials so compromise in one workflow cannot immediately reach production.
• Monitor runner behaviour during execution Inspect network calls, file access, and process behaviour in CI/CD runs so suspicious activity is detected at runtime. Stop executions that attempt secret exfiltration or unexpected outbound communication.
• Review third-party action exposure as a governance task Inventory which workflows use external actions, where those actions are trusted, and which repositories depend on them. Reassess ownership, approval, and offboarding whenever the supply chain changes.

Key takeaways

• CI/CD pipelines have become delegated execution environments, so compromise in the build layer can expose secrets, artifacts, and downstream release paths.
• Datadog's 2026 data shows that supply chain exposure is still common, with unpinned actions, fast dependency adoption, and exploitable services all contributing to risk.
• The most effective control shift is from passive review to active governance of provenance, privilege, and runtime behaviour inside the workflow itself.

Key terms

• Workflow Blast Radius: Workflow blast radius is the amount of damage a compromised workflow can cause before it is stopped or contained. In identity and security terms, it describes how far a malicious action, bad automation step, or stolen credential can spread across systems, data, and permissions within a process.
• Immutable Action Pinning: The practice of referencing GitHub Actions or similar build steps by a fixed commit SHA instead of a moving tag. It prevents a trusted workflow from silently changing after review and is a core supply chain control for reproducible pipeline behaviour.
• Release-Day Dependency Risk: The exposure created when teams adopt software packages immediately after publication, before the new code has been broadly observed or vetted. In CI/CD environments, that timing can let malicious or compromised dependencies enter the pipeline during the highest-risk window.
• Runtime Behaviour Monitoring: Runtime behaviour monitoring is the practice of watching what an identity actually does during execution, not just what it was configured to do. For AI agents, this means tracking tool calls, session activity, data volume, and unusual action sequences so semantic abuse can be detected in flight.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of delegated access and lifecycle control. It helps security, IAM, and platform teams align non-human identity controls with broader programme risk.