Kennedy Toomey
We recently released the 2026 State of DevSecOps study, in which we analyzed tens of thousands of applications and their respective supply chain and build system dependencies. Our research revealed trends in security posture and best practices across the software development life cycle. In particular, we found that:
In this post, we outline several best practices that organizations should implement based on these findings, including to:
In addition, we explain how you can use Datadog Code Security and Cloud SIEM within the Datadog platform to improve your security posture and defend against threats.
CI/CD pipelines are the backbone of modern engineering, but they are also a prime target for attackers. Our research highlights that GitHub Actions is particularly vulnerable to supply chain attacks if not properly secured. Relying on tags such as @v1 or @latest for third-party actions means an attacker who compromises the repository can inject malicious code directly into your build pipeline. GitHub strongly recommends pinning actions to a specific, immutable commit SHA.
# the secure way: pinning to a commit SHA
uses: thollander/actions-comment-pull-request@b07c7f86be67002023e6cb13f57df3f21cdd3411
# the insecure way: pinning to a tag
uses: thollander/actions-comment-pull-request@v2
Because this can be tedious to update manually, GitHub’s Dependabot has the capability to create pull requests that will update the hash to the latest version on a regular cadence.
Datadog Infrastructure as Code (IaC) Security provides comprehensive visibility into your CI/CD configurations. Datadog includes out-of-the-box IaC rules for GitHub Actions that automatically scan your workflow files and flag risky configurations, such as failing to pin actions to a specific commit hash, so you can secure your pipelines before code ever reaches production.
DevOps Research and Assessment (DORA) metrics are traditionally used to indicate the velocity and stability of software delivery, but we found that improvements in software delivery performance are decidedly correlated with stronger security posture. High-performing teams deploy frequently and with shorter lead times without increasing failures, indicating a delivery process that is both efficient and resilient. Research and industry practice show that teams with higher DORA metrics not only ship code faster but also recover from failures more quickly. This creates smaller windows of exposure for vulnerabilities and faster feedback loops for patching and upgrades.
When applied to dependency management, this means that teams with better DORA metrics can integrate library upgrades continuously, reducing the backlog of outdated or vulnerable packages and improving the overall security posture relative to services with lower DORA scores. By aligning deployment velocity with security goals, organizations benefit from a cycle where frequent, stable deployments support both rapid innovation and reduce risk.
To help teams act on insights surfaced through DORA metrics, Datadog provides an integrated suite of tools spanning performance monitoring, CI visibility, code quality analysis, and incident response. The DORA Metrics page centralizes all four key indicators—deployment frequency, change lead time, change failure rate, and time to restore service—in a single view, using clear visualizations to make performance trends and regressions easy to identify. Teams can also segment and filter metrics by attributes such as service, environment, or team, allowing them to tailor analyses to specific workflows and focus improvement efforts where they will have the greatest impact.
While keeping software up to date is crucial, blind automatic upgrades come with their own set of risks. We found this was true especially for AMIs and libraries.
Recent supply chain incidents demonstrate how quickly malicious dependencies can inflict widespread damage once introduced into the software ecosystem. Campaigns such as s1ngularity and both Shai-Huluds used malicious packages published to public registries, where they were unknowingly pulled into downstream projects. Automatic dependency updates and loosely pinned version constraints accelerated the spread, allowing compromised packages to propagate rapidly without manual intervention. What might have begun as a single malicious upload quickly cascaded into thousands of installations. This illustrates how modern development practices, particularly automated upgrades designed to improve velocity, can inadvertently amplify the blast radius of a supply chain attack when adequate guardrails are not in place.
For proactive supply chain defense, use open source CLI tools like GuardDog and Supply-Chain Firewall. GuardDog helps identify suspicious or malicious behavior in open source packages—such as obfuscation, data exfiltration patterns, or typosquatting indicators—before they are introduced into your codebase. The Supply-Chain Firewall can automatically block known malicious packages from being installed in development environments, preventing compromised dependencies from entering your software life cycle in the first place. The Supply-Chain Firewall is partially powered by Datadog’s open source malicious software package dataset, which is continuously updated by security researchers and GuardDog, tracking real-world supply chain campaigns. Together, they give organizations both visibility and preventative controls to reduce exposure to malicious dependencies upstream.
While often avoided due to the hassle of updating, pinning packages to a full-length commit SHA is recommended to reduce the risk of introducing malicious dependencies. Alternative safeguards can help create a protective buffer. For example, Yarn and pnpm now support configurations that enforce a minimum release age, delaying the installation of newly published package versions until they have been available for a defined period. Similarly, GitHub’s Dependabot offers a cooldown setting that postpones automated updates for the same purpose. This intentional delay preserves the benefits of staying current while reducing the likelihood of pulling in a freshly published malicious package. A cooldown of one week could prevent a majority of malicious dependencies from spreading.
minimumReleaseAge: 10080 # one week in minutes
npmMinimalAgeGate: "7d"
cooldown:
default-days: 7
Datadog Software Composition Analysis (SCA) helps teams identify known malicious packages before they make it into production by continuously analyzing dependencies across repositories and services. SCA detects vulnerable and suspicious packages using curated threat intelligence and vulnerability databases, enabling teams to surface risks early in development and in deployed applications. Through the Libraries (SCA) tab in Code Security, developers can search across services and directories to identify vulnerable or risky packages and understand where they are introduced.
In addition, the Security Research Feed provides timely alerts about emerging supply chain attacks, malicious package campaigns, and newly disclosed threats, along with visibility into whether your environment is affected. Together, these capabilities allow organizations to quickly detect, investigate, and remediate malicious dependencies.
Amazon Machine Images (AMIs) are vulnerable to name-confusion attacks, which highlights how a seemingly minor misconfiguration in how AMIs are selected can lead to serious compromise of cloud environments. In this attack, software that retrieves the latest AMI using the AWS ec2:DescribeImages API without explicitly specifying a trusted owner can be tricked into launching a malicious AMI published by an attacker with a carefully crafted name. Because anyone can publish an AMI to the public catalog, this name-confusion pattern can result in an attacker’s image being selected instead of the intended one, potentially granting remote code execution within the victim’s AWS account. This underscores that AMI selection is not just a convenience issue but a genuine supply chain threat vector requiring guardrails and detection.
In response to this research, AWS introduced the “Allowed AMIs” feature, which helps organizations restrict instance launches to trusted images—a particularly important safeguard when using community AMIs. For teams that want visibility into past usage, the open source whoAMI-scanner can generate reports identifying where unverified community AMIs have been deployed within an organization. Additionally, Investigator.cloud provides a way to analyze public AMIs and trace their lineage, offering deeper insight into image provenance and potential risk.
To detect when the most recent AMI is being used without an owner or filter, Datadog Infrastructure as Code (IaC) Security created a rule to check your Terraform code for this misconfiguration. Additionally, Datadog’s Cloud SIEM has a rule to alert you whenever the ec2:DescribeImages endpoint is queried without using owner identifiers and then followed by an ec2:RunInstances call by the same ARN.
Dependency vulnerabilities are widespread, and the sheer volume of findings across modern codebases can quickly overwhelm even well-resourced security teams. In many organizations, prioritization still relies heavily on Common Vulnerability Scoring System (CVSS) ratings. While CVSS provides a useful baseline for estimating theoretical severity, it does not account for how a vulnerability manifests within a specific environment. As a result, teams often treat every “critical” vulnerability as equally urgent, regardless of whether it is exploitable in practice.
Our research shows that only 18% of vulnerabilities initially labeled as critical should remain critical when evaluated with additional context; the remaining 82% can be downgraded based on factors such as runtime exposure, exploitability, and reachability. This gap highlights a fundamental challenge in vulnerability management: Severity alone does not equal risk. Without environmental context, security teams are left chasing high scores rather than meaningful threats.
We also found that 87% of organizations have a known exploitable vulnerability in deployed services, which is surprising given that many vulnerabilities are downgraded when no exploit is available. Even as improved severity scoring reduces noise by deprioritizing issues that lack real-world exploitability, a significant subset of vulnerabilities still meets the higher bar of being demonstrably exploitable. Organizations should focus on fixing vulnerabilities that are in production and have an exploit available.
Datadog’s updated severity scoring model addresses this problem by incorporating runtime context and exploit intelligence into vulnerability prioritization. The Datadog severity score refines traditional CVSS ratings to better reflect the actual risk posed to a given service or application. By accounting for whether a vulnerable dependency is in production, reachable in execution paths, or associated with active exploitation signals, the score provides a more accurate representation of urgency. The result is a clearer remediation roadmap that reduces noise, improves focus, and enables teams to allocate effort where it will have the greatest security impact.
To maintain high release velocity without compromising security, organizations need comprehensive visibility across their entire software lifecycle, from vulnerabilities in application code to misconfigurations in cloud infrastructure. They also need the context required to prioritize and remediate meaningful risks. Datadog brings these insights together in the same platform used to monitor system health and performance, eliminating operational silos and enabling teams to collaborate more effectively. By unifying security and observability, organizations can accelerate DevSecOps adoption while driving measurable improvements in security outcomes.
Check out our documentation to get started. If you’re not a customer, get started today with a 14-day free trial.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。