DevSecOps vulnerability management needs clearer decision layers

At a glance

What this is: This is a framework post on DevSecOps vulnerability management that breaks the lifecycle into identification, observability, and management across the SDLC.

Why it matters: It matters to IAM and NHI practitioners because the same control gap appears in secrets, service accounts, and other non-human access paths when findings are not prioritized and owned.

👉 Read GitGuardian's DevSecOps vulnerability management architecture series

Context

DevSecOps vulnerability management is the process of finding, prioritizing, and fixing security issues inside software delivery before they become production exposure. In practice, that problem now includes non-human identity governance because secrets, service accounts, tokens, and deployment credentials often travel through the same development systems as application code.

The article’s core point is that no single scanner or team can manage this risk alone. Identification surfaces the issues, observability turns noisy findings into decision-ready context, and management assigns the work to product owners and leaders. That starting position is typical for mature security programs, but many organisations still collapse those stages into one overloaded security queue.

Key questions

Q: How should security teams prioritise vulnerability findings in DevSecOps?

A: Security teams should prioritise findings by exposure, exploitability, business criticality, and ownership, not by severity labels alone. A useful prioritisation model also deduplicates repeated alerts and groups related issues so product owners can act on a single business problem instead of many noisy technical entries.

Q: What is the difference between detection and observability in vulnerability management?

A: Detection finds the issue, while observability explains its significance in context. Detection produces alerts from scanners or tests. Observability adds ownership, deduplication, exposure, and business impact so decision-makers can decide whether the issue needs immediate remediation, scheduled work, or accepted risk.

Q: Why do NHI risks complicate DevSecOps governance?

A: NHI risks complicate DevSecOps governance because the same delivery systems that ship software also create, store, and move credentials. If secrets, tokens, or service accounts are not tracked with clear ownership and lifecycle controls, they become hidden access paths that outlive the code that depends on them.

Q: When should security teams escalate vulnerability work to leadership?

A: Security teams should escalate when a finding threatens business-critical systems, violates agreed service levels, or cannot be remediated within the normal product backlog. Escalation is also appropriate when a shared credential, exposed secret, or widely reused dependency creates a large blast radius that exceeds the team’s normal risk tolerance.

Technical breakdown

Identification across code, dependencies, and secrets

Identification is the stage where teams discover where security issues enter the software lifecycle. The article correctly treats source code, third-party dependencies, infrastructure-as-code, containers, deployment environments, and secrets as distinct surfaces because each creates different failure modes. For example, SAST and DAST focus on application logic, SCA tracks vulnerable libraries, IaC scanners catch misconfigurations, and secrets detection looks for leaked credentials in repositories and build systems. For NHI governance, this matters because secrets and service credentials often bypass traditional app scanning and need dedicated discovery controls.

Practical implication: Use separate detectors for each SDLC surface instead of assuming one scanner can cover code, secrets, and deployment risk.

Observability for vulnerability prioritization

Observability is the translation layer between raw findings and business action. A high-volume alert feed is not useful unless teams can deduplicate findings, group them by product or owner, and rank them by exposure, exploitability, and business criticality. The article’s point about “critical” losing meaning is well taken: severity labels alone do not create urgency. For NHI and IAM teams, observability should also surface which credentials are shared, long-lived, overprivileged, or used across multiple systems, because those traits drive blast radius more than raw count.

Practical implication: Build a single prioritization view that combines technical severity with ownership, exposure, and business context.

Management, SLOs, and security ownership

Management is where vulnerability work becomes a decision about time, risk, and accountability. The article frames product owners, engineering managers, and security teams as joint participants, which is the right model for modern DevSecOps. Security should not own every fix, but it must own escalation criteria, policy guidance, and verification of imminent threats. In NHI terms, the same model applies to secret rotation, offboarding, and access review: if those tasks are not tied to explicit ownership and service-level expectations, they will drift indefinitely.

Practical implication: Assign remediation ownership to product teams, then define SLOs that make security work measurable and enforceable.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 vulnerability management is now an identity governance problem as much as an application security problem. The article focuses on code, dependencies, and deployments, but the same lifecycle logic applies to non-human identities because secrets, tokens, and service accounts move through the same delivery systems. When those artifacts are not discovered, prioritised, and assigned, they become unmanaged access paths rather than isolated technical findings. Practitioners should treat NHI visibility as part of vulnerability management, not a separate programme.

The real control failure is not detection, it is translation. Teams already have scanners, dashboards, and ticket queues, but they often do not have a shared model for deciding what gets fixed first. That is the same reason NHI leaks persist: exposure data exists, yet ownership and urgency remain unclear. A mature programme turns technical findings into business decisions with clear thresholds, escalation paths, and remediation expectations.

Identity blast radius is the right named concept for this problem space. The article’s multi-stage lifecycle shows that one exposed secret or overused credential can affect many applications, teams, or deployment paths. That blast radius expands when observability is fragmented and management is delegated without policy. Practitioners should measure how far a single NHI compromise can travel across delivery systems, then reduce that reach before increasing automation.

Security teams should stop treating vulnerability scoring as a finish line. Scores are only useful if they drive ownership, service levels, and training decisions. In a DevSecOps model, the best evidence is not how many findings were generated but how many were translated into action by the team that owns the product. The discipline for NHI governance is the same: measure, assign, enforce, and retrain.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most programmes still lack the inventory needed for consistent lifecycle control.
• For lifecycle governance detail, see the NHI Lifecycle Management Guide, which is the natural next step when teams need to move from detection to ownership.

What this signals

The programme signal here is straightforward: if vulnerability management does not include non-human identity inventory, remediation will keep lagging behind discovery. That is why lifecycle controls matter as much as scanners, and why the OWASP Non-Human Identity Top 10 remains a useful reference for teams trying to convert alert volume into actual control coverage.

Identity blast radius: when one secret, token, or service account can affect multiple applications, the organisation has a governance problem, not just a remediation problem. With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the next maturity step is to measure how far a compromise can spread before asking how fast a team can patch it.

For practitioners

• Map NHI and vulnerability ownership to delivery teams Define which product team owns each class of finding, including leaked secrets, misconfigured pipelines, and overprivileged service accounts. Use that ownership map to prevent security from becoming the default remediation queue.
• Separate detection by SDLC surface Run distinct controls for code, dependencies, IaC, containers, deployment, and secrets so findings are not conflated into one generic backlog. This makes it easier to route issues to the right fixer and measure coverage gaps.
• Create prioritisation rules that reflect blast radius Score findings by exposure, reuse, privilege, and operational reach, not severity labels alone. A duplicated secret or shared service account should outrank a noisy low-impact issue when remediation capacity is limited.
• Set remediation SLOs for identity-related findings Tie secret rotation, offboarding, and access review to measurable service-level expectations, then escalate when teams miss them. The goal is to make identity hygiene a normal part of delivery rather than a periodic cleanup task.
• Use training data to target weak spots Review recurring findings by team and type, then feed that pattern into targeted coaching for developers and product owners. Training works best when it is tied to the exact classes of mistakes teams keep repeating.

Key takeaways

• DevSecOps vulnerability management only works when detection, prioritisation, and ownership are treated as separate control layers.
• Non-human identities belong in the same governance model because secrets and service accounts create the same remediation and escalation problems as code flaws.
• Teams should measure blast radius, assign explicit ownership, and tie remediation to service levels so security work competes fairly with feature delivery.

Key terms

• DevSecOps vulnerability management: DevSecOps vulnerability management is the process of finding, ranking, and fixing security issues inside software delivery workflows. It combines scanners, ownership models, and risk decisions so remediation becomes part of engineering operations rather than a separate security queue.
• Observability layer: The observability layer is the translation point between raw security findings and decision-ready context. It deduplicates alerts, groups them by owner or product, and adds exposure and business data so non-security leaders can decide what to fix first.
• Security service level objective: A security service level objective is a measurable target for remediation or control performance, such as fixing a class of issues within a defined window. It turns security work into an agreed operational expectation that can be tracked, escalated, and reviewed like any other delivery commitment.
• Identity blast radius: Identity blast radius is the range of systems, teams, or workflows that could be affected if a non-human identity is exposed or misused. It is a practical way to judge how much damage a credential can cause when it is shared, long-lived, or overprivileged.

What's in the full article

GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of the three-stage vulnerability management diagram with the author’s own implementation perspective.
• Examples of how the author structures roles and responsibilities across engineers, product owners, managers, and security staff.
• Illustrative SLO examples for vulnerability remediation, including how teams may decide when to escalate risk.
• The next post in the series, which shifts from vulnerability management to secure-by-design pipeline controls.

👉 GitGuardian's full post covers the stage-by-stage model, role split, and remediation SLO examples.

Deepen your knowledge

DevSecOps vulnerability management and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to connect secrets, access, and remediation ownership, it is worth exploring.