In a recent TFiR interview, Swapnil Bhartiya spoke with Andrew Krug, Head of Security Advocacy at Datadog, about the findings from Datadog’s third annual State of DevSecOps report and how the shift from stability to velocity has reshaped application security risks.

From Uptime to Velocity: The Hidden Cost of Moving Fast

The way engineering teams measure success has fundamentally changed. What was once a culture of stability—where uptime leaderboards tracked how long servers had been running—has evolved into a velocity-first environment where release cadence is king. That shift, Krug explains, has created a new kind of technical debt.

Q: What surprised you most in this year’s findings compared to previous Datadog State of DevSecOps reports?

Andrew Krug: “When I started my career, we measured success based on stability. We literally had leaderboards of how long servers had been up. Since moving to velocity as a measure of success, we’ve seen teams accumulate vulnerabilities as a result of that velocity. The big one is that most organizations already have some vulnerable dependency in their environment—they just really don’t know it yet. That’s reflected in the report’s facts around vulnerabilities by ecosystem, and I think that continues to surprise me. As we add more language runtimes and more data year over year, we’re really not seeing a ton of change in the trends from year one to year three.”

The Triage Problem: Drowning in Findings

With 87% of organizations running exploitable vulnerabilities in production, the question isn’t whether teams want to remediate. It’s whether they can find the needle in the haystack. Traditional vulnerability management tools flag everything as critical, creating alert fatigue and leaving security teams paralyzed.

Q: What are the most common barriers preventing teams from remediating these vulnerabilities?

Andrew Krug: “Teams, in general, are just drowning in findings today. Number one is the triage problem. Number two is, inside of that prioritized triage—because a lot of products on the market right now are doing AI-assisted triage—providing that secondary tier the context it needs to help your teams prioritize what’s next. Something that’s public in production and has a reachable exploit is going to be a higher priority than others. It’s really finding the needle in the haystack for these vulnerability remediation teams that’s slowing them down. It’s not that most teams don’t have a desire to patch vulnerabilities—they’re just dealing with this massive list on a daily basis.”

Runtime Context: The Missing Layer in Vulnerability Prioritization

Datadog’s research found that only 18% of vulnerabilities labeled critical remain critical once runtime context is applied. This context includes code reachability, public exposure, and whether an exploit path actually exists. Without it, teams are operating blind.

Q: How should security teams rethink their prioritization approach when almost everything gets labeled as critical?

Andrew Krug: “I like to say, ‘if you label everything critical, nothing is actually critical,’ which is what a lot of vulnerability management products do. It’s very easy to just take CVEs and map them to a criticality rating based on something like a CVSS score. This is where I think Datadog’s approach is actually quite unique, in that we use 100% of the runtime context that we can to dynamically adjust that severity.

Code reachability is a big part of that. Is there actually a potential path to exploitation? Is this attached to a load balancer, or does it have a public IP that’s accessible from the outside? We have a ton of context from just sitting in the position that Datadog does in the environment to calculate that in a way that’s accurate, using data from things like the application’s runtime and the cloud control plane.

When we talk about going back to the initial point on the triage problem, the data really supports that by showing that if you have this runtime context data, you’re able to triage so much more effectively than you would without it.”

The End-of-Life Problem: Why Organizations Can’t Upgrade

Services using end-of-life language versions face exploitable vulnerabilities in 50% of cases, compared to 31% for supported versions. Despite the clear risk, many organizations remain stuck on outdated runtimes. The reason, Krug argues, is the pace of breaking changes in modern language ecosystems.

Q: Why are organizations still running end-of-life versions when the risk is this obvious?

Andrew Krug: “I don’t have the data to back this up in the report—I only have my opinion as a former practitioner—which is that if we look at the pace of innovation and the rate of change in ecosystems, the number of breaking changes in the language itself prevents folks from moving from one major version of a runtime to another without a significant lift. I think we see that in the Ruby ecosystem. The number one ORM framework isRuby on Rails, and the pace of innovation in Ruby on Rails really picked up as it approached version 6. It was a significant effort to migrate from one major version to another, and the long-term support versions of those runtimes just lagged behind.

What we see is a technical debt crisis in the way folks are building on top of these things that are core foundations for what their business is doing, and that is more pronounced than ever now that it’s super easy to add features to basically anything with agentic coding models.”

Adopting Dependencies Too Fast: The 24-Hour Problem

Datadog’s report found that 50% of organizations adopt new library versions within 24 hours of release. This raises a critical question: are teams practicing disciplined hash pinning, or are they simply pinning to “latest” and hoping for the best?

Q: 50% of organizations adopt new library versions within 24 hours of release. What’s the actual risk here, and how do you balance staying current without introducing malicious dependencies?

Andrew Krug: “We could speculate on this in a fun way and ask ourselves: why are these organizations adopting those new library versions so quickly? Is it because they have a high degree of maturity and they’re just able to get a release out in 24 hours? Or do we have a case where 50% of organizations are simply pinning to latest and they’re not doing things like hash pinning in the way that they build their app?”

GitHub Actions Security: A No-Brainer Fix

As organizations shifted left and moved build processes into CI/CD pipelines like GitHub Actions, they introduced new supply chain risks. Recent compromises by threat actors like TeamPCP have highlighted the danger of running untrusted code in highly privileged environments.

Q: Based on the trends you’re seeing, what concrete steps should security and engineering leaders prioritize in the next 12 months?

Andrew Krug: “There’s quite a lot of guidance in the report, and I would encourage anyone to go check out the full report. We did focus a fairly significant portion of it on GitHub Actions this year, and I think there’s been a ton of attention focused on GitHub Actions, especially with the recent set of supply chain compromises from threat actor groups like TeamPCP.

There is one piece of guidance in here that I think is a no-brainer that everybody should be doing, which is pinning dependencies in GitHub Actions to the full-length hash rather than simply taking the off-the-shelf latest version to run in CI. If you think about what we’re doing in CI today, when we shifted everything left, we put this massive responsibility on platforms like GitHub Actions, where you might not have as much control or observability because they are third-party hosted runners. So it’s up to you to really put the right guardrails on them to ensure that they are building in a way that’s deterministic and reliable.”

AI Agents and Intent-Based Security: Reasons for Optimism

Despite the challenges, Krug remains optimistic about the future of security. AI agents are accelerating workflows that once took teams months, and the shift toward intent-based security—where teams describe desired outcomes rather than manual configurations—is making complex systems more manageable.

Q: Are you happy with the state of security in 2026?

Andrew Krug: “There are always things that surprise me in breach notifications each year, but I am optimistic for the future of security teams. In EMEA, there is great legislation that encourages good security hygiene behaviors. We also see that a lot in APAC as well. But really, the thing that makes me optimistic for the future is how AI agents are accelerating security workflows. They’re able to identify, triage, and remediate issues in a way that would take entire teams maybe months to act on. I’m generally optimistic about the future as we move into a space where we can think about security as describing our intent for a complex system. Intent-based security makes me very happy and highly optimistic for the future.”

Watch the full TFiR interview with Andrew Krug here