TL;DR: Low and medium severity issues can combine into a critical attack path, and Cycode argues that severity scoring alone misses that risk because each finding is judged in isolation, not as part of a route. The implication is that remediation has to become chain-aware, or attackers and AI-assisted tooling will keep turning backlog noise into breach paths.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cycode's blog post: Individually low- or medium-severity findings can combine into a critical attack path that severity scoring alone will miss.
Why it matters: IAM, NHI, application security, and cloud teams need to assess linked weaknesses across identities, secrets, pipelines, and infrastructure rather than triaging each finding in isolation.
Context
Attack chaining is a prioritisation problem as much as a vulnerability problem. A finding that looks tolerable on its own can become materially worse when it unlocks the next step in an attacker route, especially across code, infrastructure, secrets, and identity controls. In practice, that means conventional scoring systems can understate the risk in environments where the real danger comes from relationships between findings rather than from any single issue.
The identity angle is especially important in software factories and cloud estates because secrets, service accounts, pipeline permissions, and workload access often sit outside the queue that security teams review as application vulnerabilities. When those non-human identities are part of the path, the control failure is not just weak configuration. It is the absence of a way to evaluate how credentials, privilege, and reachability combine into an exploitable route.
Key questions
Q: What breaks when security findings are prioritised only by static severity scores?
A: Static severity scores can miss whether a weakness is actually reachable, exposed, or mitigated by surrounding controls. That means teams may overreact to low risk issues and underreact to vulnerabilities that are live in production. Good prioritisation combines code context, deployment context, and exploit likelihood so the queue reflects real risk rather than abstract labels.
Q: Why do lower-severity findings sometimes deserve higher priority than critical ones?
A: Because exploitability depends on context. A lower CVSS finding on an internet-facing authentication API can be far more dangerous than a higher-scored flaw in an internal-only library that is never called. Prioritisation should reflect exposure, reachability, and business impact, not just the severity number.
Q: How do security teams know if attack path analysis is working?
A: They should see fewer high-priority findings with unclear reachability and more fixes focused on routes that connect to privileged access or sensitive data. A working programme produces clearer remediation decisions, shorter time-to-fix for exploitable paths, and better alignment between AppSec, cloud security, and IAM teams.
Q: What should teams do when chained findings span application and identity controls?
A: Treat the path as one governance problem and assign ownership to the link that most reduces the attacker’s reach. That usually means fixing the credential, permission, or shared bypass that connects otherwise separate teams and tools. If the remediation plan stops at one scanner’s boundary, the chain probably survives.
Technical breakdown
Why severity scoring misses chained attack paths
CVSS describes one vulnerability in isolation. It tells you how hard a flaw is to reach and what it does to the affected component, but it does not model what that component can reach next, what credentials sit nearby, or whether another low-severity issue completes the route. That is why a medium finding can be harmless on its own yet decisive when paired with a leak, a missing control, or excessive privilege. The score travels unchanged into every queue and dashboard, while the attacker sees a path, not a number.
Practical implication: score individual flaws, but make remediation decisions from graph context, not from CVSS alone.
How attack chains form across code, identity, and infrastructure
In modern environments, many chain links are not classic CVEs. They are leaked secrets, weak reset flows, permissive IAM roles, root containers, and pipeline accounts that can modify shipped artefacts. These are often treated as separate hygiene issues by different teams, which is exactly why they persist long enough to be chained. Once one link yields a foothold, the next link often comes from a different control plane, not the same tool that found the first issue. That is why a chain-aware model must connect code, identity, and runtime reachability.
Practical implication: correlate secrets, IAM, CI/CD, and runtime findings in one model so cross-team attack routes become visible.
Why AI-assisted attackers make chaining more dangerous
AI changes the economics of chaining. What once required expensive manual reconnaissance can now be automated across a backlog of ignored weaknesses, especially when the attacker is looking for relationships between small defects rather than a single critical bug. Cycode points to this as the real shift: detection volume is rising faster than remediation capacity, so more exploitable combinations survive review. The result is not just more noise, but more attacker options for turning modest findings into complete compromise.
Practical implication: assume attackers can assemble overlooked weaknesses faster than your queue can be manually triaged.
Threat narrative
Attacker objective: The objective is to turn individually tolerable weaknesses into a reliable route to privileged access, account takeover, or compromise of production systems.
- Entry begins when an attacker identifies a low- or medium-severity weakness such as a leaked secret, missing CSRF check, or permissive reset flow.
- Credential access and control abuse follow when that weakness exposes tokens, bypasses a workflow, or unlocks a nearby service account or admin function.
- Escalation and lateral movement occur as the attacker chains additional findings across code, pipeline, or infrastructure boundaries to reach higher privilege.
- Impact is achieved when the path ends in account takeover, web shells, or access to shipped artefacts and connected environments.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
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
Attack chaining is a governance failure, not just a vulnerability issue: prioritisation models still assume the risk unit is one finding at a time. That assumption breaks when the attacker only needs a route, not a critical score. The practical conclusion is that remediation policy has to recognise relationships between findings across code, identity, and infrastructure.
Chain awareness is now an identity problem as much as an application problem: many of the links in a modern attack path are secrets, service accounts, pipeline permissions, and workload identities. Those are NHI governance objects, not just security misconfigurations, which means inventory, ownership, and privilege scope have to be part of attack-path analysis. Practitioners should treat machine identity reachability as a first-class risk signal.
Severity-first workflows create backlog camouflage: issues that look deferable in isolation can sit untouched for months while they quietly remain available for chaining. That is why the real control gap is not just missing remediation capacity, but missing correlation logic. Security teams should expect their highest-risk paths to be composed of ordinary findings spread across multiple tools.
Blast-radius management is the named concept here: the decisive question is not whether a vulnerability is medium or high, but how far it can reach once linked to adjacent weaknesses. Attack-chain analysis exposes how much of the environment becomes exposed by one overlooked link. Practitioners should measure reachable impact, not just component severity.
AI makes attack chaining cheaper and more repeatable: the same backlog that once required skilled manual analysis can now be mined for routes at machine speed. That shifts the programme from prioritising single findings to controlling exploitable combinations. Teams should re-centre remediation on path breaking, not queue sorting.
What this signals
Blast-radius management now matters more than score management: security teams should expect attackers to work from reachable paths, not from severity tables. The operational shift is to identify the links that collapse multiple options at once, especially shared bypasses, exposed secrets, and over-privileged machine identities.
Attack chains expose the limits of tool-centric remediation: when findings live in separate scanners, the route between them disappears. Programmes that want to reduce real exposure need a shared context layer across code, CI/CD, cloud, and identity data so path-breaking work can be assigned once, not rediscovered repeatedly.
For practitioners
- Build a chain-aware prioritisation model Correlate findings before scoring them so remediation decisions reflect reachable paths, not isolated severities.
- Map secrets and service accounts into the same graph as code flaws Include pipeline permissions, workload identities, and exposed credentials in the same analysis as application and infrastructure findings.
- Break attack paths at choke points Prioritise fixes that remove shared bypasses, credential exposure, or privilege shortcuts that unlock multiple later links.
- Review AI-generated code and dependencies as a path source Treat generated code, hallucinated package names, and copied templates as a growing source of chain links that can connect to runtime exposure.
Key takeaways
- Low and medium findings can still form a high-risk route when the attacker can chain them across identity, code, and infrastructure boundaries.
- The real blind spot is not detection of individual flaws but the failure to correlate how those flaws combine into a reachable path.
- Practical remediation starts with breaking shared bypasses, exposed secrets, and over-privileged access that let one issue unlock the next.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centers on chained exploitation paths that move from access to wider compromise. |
| Recommendation — Map chained findings to TA0006 and TA0008 so you can break the credential and movement links first. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Over-privileged service accounts and pipeline permissions are core links in the attack paths described. |
| Recommendation — Review entitlements under PR.AA-05 to remove access paths that turn small flaws into reachable chains. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and service-account governance is central to the chain examples involving secrets and privileged access. |
| Recommendation — Apply CIS-5 to inventory, review, and revoke accounts that can extend a low-severity issue into compromise. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Leaked credentials and hardcoded secrets are explicitly identified as common chain links. |
| NHI-05 — Overprivileged NHI | The article repeatedly shows how excess machine privilege turns modest flaws into higher-risk routes. | |
| Recommendation — Scan for NHI-02 exposures and revoke leaked secrets before they can be combined into a path. Reduce NHI-05 exposure by trimming machine privileges that make adjacent weaknesses exploitable. | ||
Key terms
- Manual Attack Chaining: The human-led process of combining separate weaknesses into a viable intrusion path. It is essential when the most important risk comes from business logic, access relationships, or multi-step privilege abuse that automated scanners do not reliably reconstruct.
- Toxic Risk Combinations: Toxic risk combinations are unsafe interactions between datasets, access permissions, and AI workflows that only become problematic when combined. Individually they may appear harmless, but together they can expose sensitive information, enable re-identification, or create unintended inferences that traditional controls may miss.
- 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.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect identity controls to wider security governance across cloud, application, and AI-adjacent environments.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org