Verizon DBIR 2026 shows exploitability now drives product security

At a glance

What this is: Cycode’s analysis of the 2026 Verizon DBIR argues that product security has entered a new phase where exploitability, not discovery, is the central problem.

Why it matters: This matters because IAM, NHI, and software delivery controls are now part of the same exposure chain, so teams need correlated visibility across identities, pipelines, secrets, and runtime systems.

By the numbers:

• The 2026 Verizon DBIR says vulnerability exploitation now accounts for 31% of all confirmed breaches, up from 20% last year.
• Median time to patch has increased from 32 days to 43 days, a 34% year-over-year rise.
• Third-party involvement now appears in 48% of breaches, a 60% increase over the prior reporting period.
• 19% of companies say they know exactly where, where their AI-generated code is being used.

👉 Read Cycode's analysis of the 2026 Verizon DBIR for product security teams

Context

Product security teams are no longer dealing with a single software delivery chain. The emergence of agentic development means code now arrives through both the traditional SDLC and AI-assisted workflows, which expands exposure across repositories, pipelines, identities, secrets, and runtime systems.

The core governance problem is not simply finding more vulnerabilities. It is separating exploitable risk from background noise fast enough to stop attackers from using the shortest path into production. That creates a real identity intersection because developer accounts, CI/CD credentials, cloud identities, session tokens, and non-human identities now sit on the same attack surface.

Cycode’s framing is typical of the current market: many teams can describe their findings, but fewer can prove which ones matter in their environment or close them at attack speed.

Key questions

Q: How should security teams prioritise vulnerabilities when AI speeds up attack discovery?

A: They should prioritise by exploitable context, not by severity alone. A weakness on an exposed, reachable, and privileged asset deserves more attention than a higher-scoring issue that cannot be reached. For cloud and NHI programmes, the practical test is whether fixing the issue will materially shrink attack paths and blast radius.

Q: Why do developer and non-human identities change product security risk?

A: Developer and non-human identities connect source code, pipelines, cloud consoles, and runtime systems into one compromise path. When those identities carry standing privilege or long-lived credentials, attackers can move from initial access to production faster than traditional AppSec workflows can react. Identity governance becomes part of product security, not a separate function.

Q: What breaks when identity governance is separated from data security?

A: Governance becomes blind to whether an approved identity can actually reach sensitive records. Reviewers may certify access without seeing exposure, while security teams may classify data without knowing which identities can use it. That split creates a gap where least privilege is assumed but not proven.

Q: Who is accountable when third-party code or AI tooling expands breach exposure?

A: Accountability sits with the owning product security and governance teams, because third-party involvement is now part of the software trust boundary. Organisations need clear ownership for dependency risk, AI tooling approval, and identity permissions across the delivery chain. If those controls are fragmented, no one can close the loop fast enough.

Technical breakdown

Why exploitability now matters more than raw vulnerability discovery

The report’s central shift is that vulnerability discovery has become abundant, while decision quality has become scarce. Large language models can surface weaknesses faster than human researchers, but product security teams still need context to know whether a flaw is reachable, chained, or exposed in their own environment. That changes the technical unit of work from scanning to prioritisation, combining code analysis, dependency awareness, runtime exposure, and ownership data. In practice, exploitability is a correlation problem, not just a detection problem.

Practical implication: focus triage on reachability, exposure paths, and asset ownership instead of treating every finding as equally urgent.

How the agentic development lifecycle expands the attack surface

The article treats the agentic development lifecycle as a parallel supply chain, not a niche add-on. AI copilots, models, and agents can create code, move data, and interact with pipelines at machine speed, which means security controls must account for both human and machine actors in the delivery process. That broadens the governance scope to include AI tools, model outputs, pipeline permissions, and the secrets those systems touch. For IAM teams, this is where non-human identities become operationally central, because machine-to-machine access now influences software trust boundaries.

Practical implication: inventory AI tooling and map every machine identity that can write, approve, or deploy code.

Why developer identities and secrets are now production-risk controls

Developer accounts, CI/CD credentials, tokens, cloud identities, and repository access no longer represent separate control domains. They are a single compromise path from social engineering or token theft to production access, especially when the same identity can move across GitHub, Slack, pipelines, and cloud consoles. The governance weakness is persistent privilege and weak correlation between identity events and software delivery events. That is why identity security and application security are converging around privilege scope, token hygiene, and lifecycle control rather than treating credentials as a back-office issue.

Practical implication: apply lifecycle controls to developer and machine identities with the same rigor used for production privileges.

Threat narrative

Attacker objective: The attacker wants the fastest viable route from a weakness in software or identity control to production access and downstream business impact.

1. Entry occurs through vulnerability exploitation, because attackers increasingly reach production through exposed weaknesses rather than stolen credentials.
2. Escalation follows when that weakness is chained to overly broad developer, pipeline, or cloud permissions, including non-human identities that can move across systems.
3. Impact is production compromise, data exposure, or supply chain contamination, with the attacker using the shortest exploitable path rather than the deepest one.

NHI Mgmt Group analysis

Exploitability is replacing vulnerability volume as the real security metric: The DBIR trend reinforces a market shift that security leaders should already be acting on. Organisations do not fail because they have no findings. They fail because they cannot distinguish exploitable exposure from static noise quickly enough to intervene. That makes correlation across code, cloud, identities, and runtime the decisive control pattern, especially where non-human identities can move from code to production.

Agentic development creates a parallel governance problem, not just a faster engineering stack: AI copilots and agents are not just tools that accelerate code creation. They introduce new control points for model outputs, machine-authored code, and delegated actions inside delivery pipelines. That is where identity governance intersects directly with application security, because machine identities, tokens, and scoped approvals now influence software trust. Practitioners should treat ADLC governance as a first-class operating model.

Standing trust in developer and pipeline identities is becoming the weakest link: The article shows why persistent access inside delivery systems is now a production risk, not an administrative inconvenience. When credentials, tokens, and cloud permissions survive longer than the work they enable, attackers inherit a ready-made path to production. The named concept here is delivery-path privilege sprawl: the accumulation of broad or persistent access across development systems that turns one compromise into many.

Third-party and supply-chain exposure is no longer peripheral to product security: Nearly half of breaches involving third parties means the security boundary now extends beyond internally written code. That does not just increase vendor risk. It changes the governance model for software trust, because dependencies, APIs, AI tools, and machine identities all participate in the same exposure chain. Product security programmes that still separate application risk from identity risk are working with an outdated boundary.

Security teams now need attack-speed decisioning, not just better visibility: The report’s real lesson is that remediation lag is now a strategic liability. If attackers compress the time from discovery to exploitation, then the control objective becomes time-to-decision and time-to-containment. That changes how CISOs should measure product security maturity. The question is not how many issues were found, but how many exploitable paths were closed before they were used.

What this signals

Delivery-path privilege sprawl: product security programmes should expect the boundary between AppSec and IAM to keep collapsing as AI-assisted development spreads. The practical response is to treat developer credentials, CI/CD roles, and machine identities as one governed lifecycle, not three separate inventories.

The immediate programme signal is that remediation metrics need to change. If exposure can be discovered faster than it can be closed, then teams should track exploitability windows, ownership clarity, and identity-linked blast radius alongside vulnerability counts.

Practitioners should also prepare for more control overlap between software supply chain management and NHI governance. The next maturity jump is not another scanner, but a policy model that knows which identities can create code, move secrets, and deploy workloads.

For practitioners

• Correlate exploitability across code and runtime Prioritise vulnerabilities only when you can link them to reachable services, active secrets, and privileged paths into production. Use the shortest path to impact as the triage lens, not the raw severity score.
• Inventory machine identities inside delivery pipelines Map CI/CD service accounts, tokens, cloud roles, and AI tooling permissions together so you can see where non-human identities can write, approve, deploy, or exfiltrate.
• Apply lifecycle controls to developer access Set explicit expiry, rotation, and offboarding rules for developer credentials and pipeline tokens, especially where those identities can reach source control and cloud consoles.
• Unify third-party and supply-chain risk views Track external code, APIs, AI tools, and downstream dependencies in the same exposure model so third-party involvement is not treated as a separate security queue.
• Measure time to remediation by exposure class Report how long it takes to close exploitable paths, active secrets, and identity-linked weaknesses separately so leadership can see where attack windows remain open.

Key takeaways

• The DBIR points to a shift from vulnerability discovery to exploitability governance, which changes what product security teams must measure.
• AI-assisted development and machine identities widen the attack surface, so identity control now sits inside the software supply chain.
• Teams that shorten exposure windows across code, secrets, and credentials will outperform teams that only increase scan volume.

Key terms

• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
• Delivery-path privilege: The effective authority held by systems that move software from source to production, including registries, CI/CD jobs, publishing tokens, and agent workflows. It matters because attackers often target the path that delivers change, not the application that receives it.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Cycode's full article covers the operational detail this post intentionally leaves for the source:

• A breakdown of the five DBIR takeaways as Cycode frames them for product security leaders.
• Cycode's view of how agentic development changes the software supply chain and risk correlation model.
• Examples of how AI-generated code and shadow AI create governance gaps in day-to-day development workflows.
• The vendor's framing of why identity compromise now functions as infrastructure compromise in modern delivery systems.

👉 Cycode's full post expands on the DBIR takeaways, the agentic supply chain, and the identity paths attackers are targeting.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect lifecycle control to real-world exposure reduction.