Most writing on DevOps security restates the same checklist: shift left, scan things, manage secrets, monitor everything. The principles are correct and almost useless on their own, because they tell you nothing about where risk actually concentrates, what attackers are exploiting this year, or which of these controls move the numbers your board cares about. This piece keeps the same DevSecOps fundamentals the original article covered, but grounds each one in what the 2024 industry data shows - so an engineering director running a high-scale or regulated estate can decide where to spend the next quarter, not just nod along.
The threat model moved, and it moved toward your pipeline
DevSecOps - integrating security into the DevOps lifecycle rather than bolting it on after development - is not new advice. What changed is the urgency behind it. Verizon's 2024 Data Breach Investigations Report found that exploitation of vulnerabilities as an initial access vector grew 180% year over year, driven heavily by mass-exploited zero-days like MOVEit. The implication is direct: the window between a vulnerability becoming public and being exploited at scale is now short enough that periodic, out-of-band security review cannot keep up. Vulnerability scanning and remediation have to live inside the CI/CD pipeline, on every change, because that is the only cadence that matches the threat.
The same report is blunt about the second shift. Software-supply-chain and third-party involvement appeared in roughly 15% of breaches, a 68% jump over the prior year. Your attack surface is no longer mostly your own code. It is everything your build pulls in.
Your dependency graph is where the risk actually lives
This is the point where generic advice fails hardest. "Scan your dependencies" sounds like hygiene; the data says it is the main event. Datadog's State of DevSecOps 2024, drawn from tens of thousands of applications and container images, found that 90% of Java services carry at least one critical or high-severity third-party-library vulnerability, against a 47% average across other languages. More importantly for how you scan: 63% of those high and critical Java vulnerabilities come from indirect, transitive dependencies - the libraries your libraries pull in, which never appear in your own manifest and which a naive first-party scan will miss entirely.
The operational consequence is specific. Software composition analysis has to resolve the full transitive tree, and you have to scan the built container image, not just the source repository, because that is where the real runtime dependency set is assembled. If your security testing stops at your own code and direct dependencies, you are looking at a minority of your exposure.
Automation gaps, not missing tools, are the weak link
The principles around immutable infrastructure, security as code, secrets management and least-privilege access tend to be treated as settled. The data says they are widely unsettled in practice. Datadog found that 38% of AWS-using organisations still performed sensitive production actions manually through the console - ClickOps - rather than through Infrastructure as Code. Manual production changes are precisely what defeats immutable infrastructure and reproducible, reviewable controls: they create drift no scanner can see and leave no audit trail.
Credentials are the same story. Only 37% of GitHub Actions users relied exclusively on short-lived credentials; the remaining 63% still used long-lived IAM keys, which are the single most reliable thing for an attacker to find in a leaked secret or a compromised build. If you are going to prioritise one infrastructure control this year, move CI/CD off long-lived credentials and onto short-lived, federated identity. That one change neutralises a large class of supply-chain and secrets-exposure incidents.
Continuous monitoring is a prioritisation problem, not a volume problem
The instinct when you turn on scanning is to treat every critical CVE as a fire. That instinct will bury your team and stall delivery. Datadog's data on attack noise is striking: of tens of millions of malicious requests from automated scanners, only 0.0065% actually triggered a vulnerability. The overwhelming majority of what hits you is harmless background noise.
The same logic applies to your own backlog. When runtime context is applied - is the vulnerable code actually loaded, reachable, and exposed - 63% of organisations that appeared to have critical CVEs had none left. A scanner that reports a thousand criticals is not giving you a security posture; it is giving you a triage problem. Continuous monitoring earns its keep when it ranks by exploitability and reachability, so engineers spend their limited remediation time on the handful of issues an attacker could actually use.
Speed of remediation is the metric that proves the pipeline works
Shift-left and incident response are easy to claim and hard to verify. There is a clean metric for whether your pipeline genuinely shortens exposure: how fast you close known-exploited vulnerabilities. Verizon found organisations took an average of 55 days to remediate half of the critical vulnerabilities on CISA's Known Exploited Vulnerabilities catalogue, and 8% were still unpatched a year after disclosure. The KEV list is the subset that is being actively exploited in the wild. Fifty-five days to fix half of those is the gap a DevSecOps pipeline exists to close. If you want one number to govern your security investment, track time-to-remediate for KEV-listed issues and drive it down; everything else in this article is in service of that.
The new front: securing AI-assisted delivery
One angle the original article predates entirely. The 2024 DORA report, drawing on more than 39,000 respondents, found 75.9% of teams now use AI in their work, while around 40% have little or no trust in AI-generated code - and AI tends to enlarge change batches, which raises change-failure risk. Larger, faster, less-trusted changesets are exactly the conditions under which security review gets skipped. AI-assisted development does not remove the need for the controls above; it raises the premium on having them automated and in the pipeline, because human review will not scale to the new change volume.
What good looks like
The teams handling this well share a recognisable shape, and it maps cleanly onto the fundamentals:
- Security gates run on every change, in CI/CD. Dependency, container and secrets scanning are pipeline stages, not periodic projects - because a 180% jump in vulnerability exploitation does not wait for your next review cycle.
- Scanning resolves the full transitive tree and the built image. With 63% of critical Java vulnerabilities hiding in indirect dependencies, anything less misses most of the exposure.
- Production changes go through Infrastructure as Code, on short-lived credentials. No ClickOps, no long-lived IAM keys - the two automation gaps the data flags as most common.
- Findings are ranked by runtime reachability, not raw count. Engineers fix what is exploitable, which is a fraction of what a scanner reports.
- Remediation speed for known-exploited vulnerabilities is measured and improving. That single number is the honest test of whether the pipeline is working.
DevOps security is not a separate phase and never was - but treating it as an integral part of the pipeline is now a measurable business priority backed by hard numbers, not a slogan. DORA's 2024 deep dive on security exists precisely because supply-chain breaches raised the stakes, and it points the same way the rest of the data does: platform engineering and internal developer platforms can enforce security, compliance and governance without slowing developers down. That is the work. At Expeditious Software we build DevSecOps and platform engineering into the delivery platform itself, so security is something your pipeline produces as a byproduct of shipping, not something you reconstruct under deadline. If you want to pressure-test your current posture against these numbers, talk to our team.
