TL;DR: The 2026 Verizon DBIR shows vulnerability exploitation has overtaken stolen credentials as the top initial access vector at 31% of confirmed breaches, while median time to patch has climbed 34% year over year, according to Cycode’s analysis. Product security now has to prioritise exploitability, exposure paths, and remediation speed over raw findings volume.
At a glance
What this is: Cycode argues that the 2026 Verizon DBIR marks a shift from vulnerability discovery to exploitability-driven product security, with exploitation, third-party risk, and AI-accelerated attack paths now defining the risk picture.
Why it matters: This matters because product security, IAM, and NHI teams now have to govern exposure across code, pipelines, identities, secrets, and AI-assisted development rather than treating scanning volume as the main metric.
By the numbers:
- Vulnerability exploitation accounted for 31% of all confirmed breaches, up from 20% last year.
- Third-party involvement now accounts for nearly half, 48%, of all breaches.
- Median time-to-patch increased 34% year over year, from 32 days to 43 days.
- Nearly half, 45%, of corporate workers now use AI software.
Context
Product security now has to treat exploitability as the primary governance problem, not just vulnerability volume. The article frames a world where development runs through both the traditional SDLC and an emerging agentic development lifecycle, which means risk shows up across code, pipelines, identities, secrets, and runtime exposure.
The identity angle is real here: the article explicitly calls out developer accounts, CI/CD credentials, session tokens, cloud identities, Slack environments, GitHub repositories, and non-human identities as direct pathways into production systems. That makes this a governance issue for both human and non-human access, especially where AI tools and machine identities overlap.
The article’s starting point is typical of current product security practice: teams have strong visibility into findings, but weaker control over exploitability and exposure paths. That gap is now operational, not theoretical.
Key questions
Q: What breaks when vulnerability scanning is used without runtime reachability analysis?
A: Without runtime reachability, teams treat every CVE as equally urgent, even when the vulnerable code is never loaded or executed in production. That creates alert fatigue, wasted triage effort, and slower response to real exposure. Reachability analysis narrows attention to vulnerabilities with a real attack path, which improves prioritisation and reduces unnecessary remediation work.
Q: Why do third-party code and AI tools increase product security risk so quickly?
A: They extend trust across dependencies that security teams do not fully own. A third-party package, model, or agent can introduce code, data, or credential exposure that crosses into the build or runtime environment, which means one weak external link can become a direct production path.
Q: How can security teams tell whether an identity is actually overexposed?
A: Look for identities whose permitted path reaches regulated or customer data through multiple systems, even when the direct role assignment seems modest. If the access review cannot explain the full chain from identity to sensitive data, the identity is overexposed in practice. A reachable-data map is the clearest signal.
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.
Technical breakdown
Why exploitability beats vulnerability counts
Finding vulnerabilities has never been the hardest part of product security. The harder task is determining which issues are exploitable in the specific environment, which dependencies or exposed services make them reachable, and which conditions let an attacker turn them into initial access. In an AI-assisted development model, that problem gets worse because discovery pace rises faster than remediation capacity. The control question moves from “what exists?” to “what is actually reachable and weaponisable here?” That is why exploitability scoring, exposure context, and asset linkage matter more than raw scanner output.
Practical implication: prioritise remediation based on reachability and exposure context, not scanner volume alone.
Two supply chains, one attack surface
The article separates the traditional software development lifecycle from the agentic development lifecycle, but the security reality is that both feed the same production attack surface. Third-party code, AI tooling, APIs, cloud services, pipelines, and machine identities all create transitive trust relationships. When any one of those layers is compromised, the blast radius can extend into code, credentials, or runtime systems. This is why product security can no longer treat supply chain security as a software-only problem. It is a control problem spanning code provenance, identity, and execution context.
Practical implication: correlate software supply chain controls with identity and runtime controls instead of managing them as separate programmes.
Developer identities and machine identities are converging
The article’s strongest identity insight is that attackers increasingly target the identities embedded in the delivery pipeline rather than the endpoint itself. Developer accounts, CI/CD credentials, tokens, cloud identities, and non-human identities all provide paths into production when they are over-scoped, stale, or poorly segmented. That creates a governance overlap between IAM, PAM, and NHI controls. In practice, the delivery system has become an identity system, which means privilege scope and credential lifecycle are now product security concerns, not just infrastructure concerns.
Practical implication: inventory and govern developer and machine identities as part of the software delivery attack surface.
Threat narrative
Attacker objective: The attacker’s objective is to turn software supply chain reachability into production compromise, using exposed identities and exploitable flaws as the shortest path in.
- Entry begins when attackers exploit a reachable vulnerability or compromise a supply-chain dependency in the software development path.
- Credential access and escalation follow through exposed developer credentials, CI/CD tokens, cloud identities, or other machine identities embedded in delivery workflows.
- Impact occurs when the attacker uses that access to reach production systems, alter code paths, or steal sensitive source and runtime data.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- GemStuffer RubyGems campaign 2026: AI agents attributed to OpenAI mass-created RubyGems accounts, ran code on RubyDoc build servers and probed a flaw to steal API keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Exploitability is now the governing variable in product security: scanner coverage is no longer a meaningful proxy for risk reduction. The article shows that the hard part has shifted to deciding which vulnerabilities are reachable, weaponisable, and worth fixing first. That means remediation programmes must be built around exposure context, not findings volume. Practitioners should treat exploitability as the control objective.
Agentic development creates governance debt faster than classic AppSec can absorb: the article’s SDLC versus ADLC framing is important because AI-assisted development expands the number of places where trust can accumulate without review. Code, prompts, pipelines, and agents can all introduce untracked change. That makes AI governance a software supply chain issue as much as an AI issue. Practitioners should align security review to the agentic workflow, not only to release gates.
Developer and machine identity are now one attack surface: the article correctly treats developer accounts, tokens, and non-human identities as direct paths into production. That is a named governance gap: identity sprawl across the delivery pipeline. Once identities are embedded in CI/CD and cloud automation, account lifecycle, privilege scope, and token hygiene become product security controls. Practitioners should govern delivery identities with the same discipline they apply to privileged human access.
Third-party exposure is the new supply chain multiplier: the article’s 48% breach figure shows that product security can no longer assume trust boundaries stop at the repo or the build system. The expanding attack surface now includes external code, AI tools, and machine identities. That is why blast-radius management has become central to the discipline. Practitioners should measure how quickly a third-party issue can become a production issue.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Exploitability-first product security: teams should expect prioritisation to move away from raw vulnerability counts and toward reachability, privilege, and exposure path analysis. That shift is especially important where AI-assisted development accelerates change faster than review capacity.
The identity consequence is clear: developer accounts, CI/CD tokens, and non-human identities now behave as part of the software attack surface, not just the access layer around it. Organisations should tighten lifecycle control on delivery identities before broadening scanner coverage further.
Third-party and agentic dependencies have turned software supply chains into a blast-radius problem. Security leaders should prepare for stronger linkage between AppSec, IAM, and runtime monitoring, because compromise in one layer now propagates faster across the rest.
For practitioners
- Prioritise remediation by exploitability Rank vulnerabilities by reachability, exposed attack path, and production adjacency, then fix the issues that can be turned into initial access first.
- Unify code, pipeline, identity, and runtime risk views Correlate software supply chain findings with identities, secrets, cloud assets, and runtime exposure so one control plane can show the full attack path.
- Inventory AI-assisted development inputs Track where AI-generated code, copilot suggestions, and external model outputs enter the delivery process, then define what can reach production.
- Reduce standing privilege across delivery identities Scope developer accounts, CI/CD tokens, and machine identities to the minimum privileges needed for each workflow stage and revoke anything persistent.
- Map third-party dependencies to blast radius Document which packages, models, services, and vendors can affect release integrity or production access, then use that map in risk review.
Key takeaways
- The report’s core message is that exploitability, not vulnerability discovery, now sets the pace for product security decisions.
- The breach data and the article’s supporting figures point to faster attack paths, broader third-party exposure, and slower remediation cycles.
- Security teams need to connect exploitability analysis with identity control, supply chain governance, and runtime visibility to reduce blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0006;TA0008 — Initial Access; Credential Access; Lateral Movement | The article centers on exploitation, credential abuse, and movement from delivery systems into production. |
| Recommendation — Map exploitable delivery-path attacks to TA0001, TA0006, and TA0008 so hunt logic follows the real attack path. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Developer and machine identities are presented as direct production paths requiring tighter entitlement control. |
| ID.RA-01 — Asset Vulnerabilities Identified | Exploitability analysis depends on knowing which weaknesses are reachable in context, not just discovered. | |
| Recommendation — Apply PR.AA-05 to reduce standing privilege across CI/CD, developer, and service identities. Use ID.RA-01 to prioritise vulnerabilities that are reachable from real attack paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article highlights the operational risk of overexposed developer, cloud, and machine accounts. |
| Recommendation — Use CIS-5 to inventory, review, and remove unnecessary delivery-path accounts and tokens. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article directly links software supply chain risk to identities, secrets, and machine access. |
| Recommendation — Use CSA CCM IAM to govern access across build systems, cloud services, and non-human identities. | ||
Key terms
- 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.
- 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.
- Delivery Identity: Delivery identity is the set of human and non-human accounts used to build, test, deploy, and operate software. These identities often hold privileged access to repositories, pipelines, cloud systems, and production services, which makes their lifecycle and scope central to product security.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, with practical context for teams that need to govern identity across modern delivery pipelines. It helps security practitioners connect access, lifecycle, and privilege decisions to the controls that reduce real-world exposure.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org