Topic starter
19/08/2026 3:47 pm
TL;DR: CI/CD exposure stays common in Datadog's 2026 DevSecOps data, StepSecurity argues, because unpinned actions, fast dependency adoption, and exploitable services keep widening workflow blast radius. Pipelines need tighter governance over provenance, privilege, and runtime behaviour before secrets and release paths are pulled into compromised jobs.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “Datadog's DevSecOps 2026 Report Validates What We've Been Building”.
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.
- 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.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
- Add cooldown controls for fresh dependencies Block new packages and release-day dependencies for a short review window before they can enter build pipelines.
- Restrict workflow secret access by privilege scope Limit each runner to the smallest secret set and deployment target it actually needs.
Bottom line: CI/CD pipelines have become delegated execution environments, so compromise in the build layer can expose secrets, artifacts, and downstream release paths.
Glossary terms: Workflow Blast Radius, Immutable Action Pinning, Release-Day Dependency Risk, Runtime Behaviour Monitoring
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
19/08/2026 4:23 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CI/CD pipeline exposure in DevSecOps is still a governance gap