Datadog has published its State of DevSecOps 2026 report, drawing on telemetry from hundreds of thousands of production services across its customer base. The findings are a detailed account of the gap between the security posture engineering teams believe they have and the reality visible in production. The headline number is stark: 87 percent of organisations have at least one service in production running a known, exploitable vulnerability. Those vulnerabilities affect 40 percent of services across the entire dataset.
The report does not describe a wave of novel threats or sophisticated attacker techniques. It describes the compounding effect of ordinary operational pressure: dependencies that are not updated, pipelines that are not pinned, language runtimes that are not retired on schedule, and a broader pattern of security debt accumulating faster than it is being paid down.
The dependency problem
The median software dependency in production is now 278 days behind the latest major version of the library it came from. That figure was 215 days in last year’s equivalent report. The direction of travel is not improvement.
Dependency lag of this magnitude is not primarily a failure of awareness. Security tooling such as Dependabot, Renovate, and similar automated pull-request generators has become a standard part of modern CI/CD pipelines. The lag exists despite those tools being present in many of the organisations represented in the dataset. The problem is one of prioritisation and throughput: automated dependency update PRs are routinely deprioritised in favour of product work, accumulate, and eventually either get merged in large batches or are silently closed as stale.
The operational consequence is that the exploitable vulnerability is already present when the attack happens. Organisations are not typically breached through a zero-day in a well-maintained dependency. They are breached through a vulnerability that was patched months ago in a library they did not update because no one had time to review the automated PR.
The 278-day figure also creates a specific risk exposure for supply chain attacks. When a dependency is many major versions behind, it is often also running under a release that the upstream maintainer no longer patches. The report found that 42 percent of services rely on libraries that are no longer actively maintained. For those libraries, no patch is coming regardless of when the team decides to prioritise the update.
The GitHub Actions pinning failure
The CI/CD finding in the report is one that deserves wider attention than it has received. Datadog found that only 4 percent of organisations pin third-party GitHub Actions to a full-length commit SHA. 71 percent leave third-party actions completely unpinned, meaning they reference a tag such as @v3 or @latest without any mechanism to verify that the code behind the tag has not changed.
This is a well-understood attack surface that has been the subject of documented supply chain incidents. When a third-party GitHub Action is referenced by a mutable tag, control over what code actually runs in your pipeline belongs to whoever controls the upstream repository. If that repository is compromised, whether through a credential theft, a social engineering attack on a maintainer, or a typosquatting package, the attacker can inject arbitrary code into every CI/CD pipeline that references the action on the next pipeline run. That code executes with the permissions of your GitHub Actions runner, which in most environments means access to repository secrets, cloud credentials, and deployment tokens.
The scale of unpinned action usage in the Datadog dataset is notable because this is not a subtle or obscure risk. GitHub’s own documentation recommends SHA pinning for third-party actions used in security-sensitive contexts. The StepSecurity project has built tooling specifically to automate the migration from tag-based to SHA-based pinning. The risk is documented, mitigated tooling exists, and 71 percent of organisations are still exposed.
Language runtime end-of-life
Services running on end-of-life language runtimes face exploitable vulnerabilities in 50 percent of cases. For services on currently supported runtimes, that figure is 31 percent. The delta, roughly 19 percentage points of additional vulnerability exposure, quantifies the specific cost of running on an unsupported runtime.
End-of-life runtimes do not receive security patches from upstream maintainers. Vulnerabilities discovered in the runtime itself cannot be addressed without a runtime upgrade. In environments where a major version upgrade requires application-level testing and potentially dependency updates, the path from identifying the end-of-life risk to resolving it can run into months of engineering work. The Datadog data suggests many organisations are not completing that path.
What the supply chain attack pattern looks like
The combination of outdated dependencies, unpinned CI/CD actions, and end-of-life runtimes creates a layered attack surface that attackers are actively exploiting in 2026. The pattern seen in multiple incidents documented this year follows a consistent structure.
An attacker identifies a widely-used open source package or GitHub Action with a maintainer using a reusable credential that can be phished or brute-forced. Access to the maintainer account is used to push a malicious update under the existing version tag or to publish a new release that reaches organisations through automated dependency update tools. Because the update arrives through a trusted channel, it bypasses many of the detection controls that would flag unexpected network connections or unusual process behaviour.
The payload in these supply chain attacks is typically credential harvesting. CI/CD environments contain cloud provider credentials, repository tokens, and deployment keys. Extracting those credentials through a malicious package or action gives an attacker access to the full environment without needing to exploit any vulnerability in the deployed application itself.
Practical steps for engineering and platform teams
The Datadog report does not prescribe specific tools. The findings across the dataset suggest the most impactful changes are structural rather than tool-dependent.
Treat dependency currency as an engineering metric, not a security task. Dependency update PRs that sit unreviewed for weeks become a backlog that is impossible to clear. Teams that assign specific sprint capacity to dependency maintenance, even as little as a few hours per sprint, consistently show lower vulnerability exposure than teams that treat updates as a background task to be handled when time permits.
Audit your GitHub Actions workflow files for unpinned third-party references. This is a one-time audit task. Tools such as StepSecurity Harden-Runner and pin-github-action from the Modus Create team can automate the identification and conversion of unpinned actions to SHA-pinned equivalents. The resulting workflow files are more verbose but the change is mechanical and the risk reduction is immediate.
Establish and enforce an end-of-life runtime policy. If your organisation does not have a documented policy for runtime version support, establishing one is a higher-priority activity than most of the security tooling categories that typically occupy DevSecOps roadmap conversations. A policy that requires migration away from end-of-life runtimes within a defined window, backed by CI gates that block deployment of services on unsupported versions, addresses the 19-percentage-point vulnerability gap the Datadog data documents.
Run software composition analysis in CI, not only as a pre-deployment gate. SCA tooling that runs on every pull request, with failure conditions tied to CVSS scores and exploitability status, catches vulnerability introductions at the point they enter the codebase rather than after they have been in production for 278 days.
The wider context
The Datadog findings are consistent with other industry data from 2026. The Verizon Data Breach Investigations Report published earlier this year documented a significant increase in vulnerability exploitation as a breach vector, overtaking credential theft for the first time in the report’s history. The Black Duck Open Source Security and Risk Analysis report published in May 2026 found that the number of open source vulnerabilities in AI-generated code components has doubled year on year.
The common thread is that development velocity has increased faster than security practices have adapted. AI coding tools are generating more code, more dependencies are being incorporated into more projects, and CI/CD pipelines are running more frequently. Each of those trends increases the volume of code that needs to be reviewed, the number of dependencies that need to be tracked, and the number of pipeline runs where a compromised action could cause harm. The security practices that were adequate for a slower-moving development process are not scaling with the process itself.
If your engineering team needs help auditing GitHub Actions workflows for supply chain exposure, establishing dependency management policies, assessing CI/CD pipeline security posture, or designing a DevSecOps programme that keeps pace with your development velocity, contact Excello Digital. We work with engineering teams across Europe to build security practices that are proportionate to the threat environment and sustainable under operational pressure.