Topic starter
19/08/2026 3:47 pm
TL;DR: Datadog’s State of DevSecOps 2026 report reinforces that CI/CD pipelines and GitHub Actions remain heavily exposed to supply chain abuse, with StepSecurity arguing that unpinned actions, release-day dependencies, and runtime behaviour all widen the blast radius of compromised workflows. The governance gap is no longer visibility alone but control over what can execute, when it can execute, and what it can reach.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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