DevSecOps tools fail when findings outpace developer action

At a glance

What this is: This is an analysis of DevSecOps tooling choices, showing that tool coverage only matters when findings land in the right workflow with the right risk context.

Why it matters: It matters because IAM, NHI, and platform teams increasingly need to decide where security checks sit in the delivery chain and how identity, exposure, and runtime context change prioritisation.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Orca Security's analysis of DevSecOps tool stacks and workflow fit

Context

DevSecOps tools move security checks into pull requests, CI/CD pipelines, registries, and runtime monitoring so teams can catch issues before they become production problems. The challenge is not whether scanners exist, but whether they surface the right risk at the right stage and send it to the team that can act on it.

For identity practitioners, this is really a governance question: code, container, and runtime findings only become usable controls when they are tied back to workload identity, privileges, exposure, and data sensitivity. That is where pipeline security starts to overlap with NHI governance, because a vulnerable artefact is only one part of the attack path.

Key questions

Q: How should teams choose DevSecOps tools for CI/CD pipelines?

A: Start with the risk class you can catch earliest and with the least friction. Put IaC scanning in pull requests, dependency scanning in builds, container scanning in registries, and runtime detection in production. Then check whether each tool sends owner-ready findings into the workflow the engineering team already uses.

Q: Why do DevSecOps tools create noise when teams already have many scanners?

A: Because detection without ownership and context does not produce action. When findings arrive in separate consoles without exposure data, identity context, or a clear owner, teams defer remediation. The result is alert volume without a meaningful reduction in attack paths.

Q: How do security teams know if DevSecOps controls are actually working?

A: Look for fewer unresolved findings, faster routing to the correct owner, and fewer high-risk issues that survive from code to runtime. If the same class of issue keeps reappearing in production, the control exists only as a scanner, not as an operational safeguard.

Q: What should teams do when a DevSecOps finding also affects identity or data exposure?

A: Escalate the issue based on blast radius, not scanner severity alone. A vulnerability on an exposed workload with broad access to sensitive data deserves more urgency than the same issue in an isolated environment. Context is what turns a finding into a decision.

Technical breakdown

Where DevSecOps tools fit in the delivery pipeline

DevSecOps tools are control points placed across the software delivery lifecycle. IaC scanners catch misconfigurations before merge, dependency scanners catch known CVEs during build, container scanners inspect images in registries, and runtime tools watch what workloads actually do after deployment. SBOM tools inventory what is inside an artefact, while signing tools verify that the artefact came from the expected build identity. The technical point is sequencing. A control that only runs after release cannot prevent a bad configuration from reaching production, and a control that only scans code cannot detect runtime abuse.

Practical implication: Map each risk class to the earliest viable control point and reject tools that cannot operate in that stage.

Why scanner coverage and workflow ownership both matter

Coverage without ownership creates noise. A scanner can detect a public bucket, a vulnerable package, or a suspicious process, but if the finding cannot be routed to the code owner, platform owner, or workload owner, remediation stalls. This is why output format, CI/CD integration, and ticketing hooks matter as much as detection logic. DevSecOps becomes effective when findings carry enough context to assign the fix to the team that owns the asset and when that team sees the issue in its normal workflow rather than in a separate security console.

Practical implication: Require every tool to produce owner-ready findings with clear routing, not just alerts.

How cloud context changes the meaning of a DevSecOps finding

A finding is rarely equally urgent everywhere. A vulnerable image running on an internet-facing workload with broad identity permissions and access to sensitive data is materially different from the same image in an isolated test environment. That is why contextual platforms layer exposure, identity, and data sensitivity on top of pipeline findings. The architecture does not replace specialised scanners. It gives their output a risk ranking that reflects how an attacker would actually move through the environment.

Practical implication: Prioritise tools and workflows that connect build-time findings to live exposure and identity context.

Threat narrative

Attacker objective: The attacker aims to turn a pipeline weakness into production access, data reach, or secret exposure before teams can act on the finding.

1. Entry occurs when a vulnerable container image, exposed secret, or misconfigured infrastructure definition reaches deployment through the software delivery pipeline.
2. Escalation happens when the workload runs with broad identity permissions or reaches sensitive data, turning a routine flaw into an exploitable access path.
3. Impact follows when the issue becomes part of a larger attack path that allows secret theft, lateral movement, or data exposure in production.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DevSecOps tooling is a prioritisation problem before it is a detection problem. The article’s own stack shows how easy it is to accumulate scanners for IaC, dependencies, containers, runtime, and supply chain integrity without solving the real issue of which findings matter first. When teams cannot connect a finding to exposure, identity, and data sensitivity, they create more alerts but not more control. Practitioner implication: the governance model must rank findings by blast radius, not by source tool.

Identity context is the missing layer in many DevSecOps programmes. Orca Security’s argument that cloud risks become more urgent when tied to identities and sensitive data reflects a broader NHI reality. A vulnerable workload with low privilege is not the same risk as a vulnerable workload that can assume broader access, and that distinction is often invisible in isolated scanner output. Practitioner implication: code security and identity governance need a shared prioritisation model.

Runtime security closes the gap left by build-time optimism. Static checks can stop known bad artefacts, but they cannot tell you what a workload actually does after it starts. Runtime tools such as Falco and Tetragon matter because they watch process execution, network activity, and file access in the live environment. Practitioner implication: if your programme stops at CI/CD, it is blind to the stage where attackers often convert a defect into impact.

DevSecOps silos persist because each tool class solves a different failure mode. IaC scanners, SCA tools, container scanners, and signing tools are not interchangeable, and treating them as such creates false confidence. The field needs a control architecture that aligns each tool to a risk class and a workflow owner. Practitioner implication: evaluate DevSecOps maturity by how well the stack reduces unresolved attack paths, not by how many scanners are installed.

Deployment context is the named concept that changes the economics of remediation. A finding that lands with no information about exposure, identity, or data sensitivity is expensive to triage and easy to ignore. Once the same finding is tied to a reachable workload and a meaningful access path, the remediation decision becomes much clearer. Practitioner implication: the next step in DevSecOps maturity is not another scanner, but a context layer that makes findings actionable.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For deeper control alignment, see the Ultimate Guide to NHIs - Standards for the framework baseline that helps teams connect pipeline controls to identity governance.

What this signals

Deployment context is becoming the deciding factor in DevSecOps prioritisation. Teams that only see scanner output will continue to drown in low-confidence findings, while teams that attach exposure and identity context will move faster on the issues that can actually become incidents. The practical shift is from finding more defects to reducing the number of defects that can be exploited.

With 6 distinct secrets manager instances on average in the ecosystem data from The State of Secrets in AppSec, fragmentation is already a governance problem, not just a tooling problem. DevSecOps programmes that cannot unify secrets, image, and workload context will struggle to prove whether they are reducing risk or simply redistributing it.

Contextual triage is the next maturity step for pipeline security. If a finding cannot be tied to a workload identity, a reachable surface, or a data boundary, it will be deprioritised in practice even if it looks severe on paper. That is why future programmes will be judged on remediation quality, not scanner count.

For practitioners

• Map each risk class to a control stage Place IaC checks in pull requests, dependency scanning in build, image scanning in registries or CI, and runtime detection in production so the earliest practical control catches the issue.
• Tie every finding to an owner and asset Require tools to identify the code owner, image owner, or workload owner so the ticket lands with the team that can fix it without security acting as a manual relay.
• Add identity and exposure context to triage Prioritise findings using workload identity, internet exposure, and sensitive data access so teams can separate routine hygiene issues from genuine attack paths.
• Use runtime controls for what build tools cannot see Pair static scanners with Falco or Tetragon style runtime detection so suspicious process execution, file access, and network behaviour are visible after deployment.
• Verify supply chain integrity before admission Use signing and SBOM generation to confirm what entered the artefact and block unsigned or unverified images before they run in sensitive environments.

Key takeaways

• DevSecOps programmes fail when they add scanners faster than they improve routing, ownership, and risk context.
• Build-time checks are necessary but not sufficient because runtime behaviour and identity exposure can turn a minor flaw into a major incident.
• The most effective control model ties each finding to the earliest feasible stage and the team that owns the asset, not to a separate security queue.

Key terms

• DevSecOps tool stack: A DevSecOps tool stack is the set of scanners, policy controls, signing tools, and runtime detectors used across software delivery. Its value depends on where each control sits in the pipeline and whether findings reach the team that owns the asset.
• Software bill of materials: A software bill of materials is an inventory of the components inside a build artefact, image, or filesystem. It helps teams understand what is present so they can assess vulnerability exposure, trace supply chain risk, and compare released artefacts against approved builds.
• Runtime security: Runtime security monitors what a workload actually does after it starts running. It detects process execution, file access, and network behaviour that static scanners cannot observe, which makes it essential for catching live abuse rather than only pre-deployment defects.
• Deployment context: Deployment context is the surrounding information that determines how urgent a finding really is. It includes workload exposure, identity permissions, and data sensitivity, which together show whether a flaw is merely technical debt or a viable attack path.

Deepen your knowledge

DevSecOps tool coverage, prioritisation, and identity context are core themes in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to connect pipeline findings to governance outcomes, it is a practical place to start.

This post draws on content published by Orca Security: DevSecOps tools guide and workflow analysis. Read the original.