Application vulnerabilities are still the main breach path for attackers

At a glance

What this is: Cycode argues that application vulnerabilities remain a leading breach path, with web application attacks responsible for more than 40% of breaches in the cited Verizon data.

Why it matters: For IAM, PAM, NHI and application security teams, this reinforces that access controls and runtime visibility have to be paired with vulnerability governance, or attackers will keep using application flaws to reach data and privileges.

By the numbers:

• Web application attacks now represent more than 40% of all breaches, according to Cycode.
• The average cost to respond to an attack reached $4.88M around the world, according to Cycode.
• Companies take 277 days to identify and contain a breach on average, according to Cycode.
• AT&T said at least 109 million customer accounts were compromised in a July 2024 breach, according to Cycode.

Context

Application vulnerabilities are weaknesses in code, design, configuration, dependencies or runtime controls that let attackers reach data or functions they should not be able to access. In this article, the issue is not whether scanning matters, but why organisations still lose control even when scanning exists.

The governance gap is that many programmes treat vulnerability discovery as the end state, when the real problem is how findings are prioritised, assigned and remediated across applications, APIs and third-party dependencies. Where the article intersects with identity, it does so through authentication failures, exposed session handling and overprivileged access paths that turn a code flaw into an access-control failure.

Cycode’s examples show this is a broad enterprise problem, not a niche engineering issue. The AT&T case described here is a typical illustration of how an application flaw at a third-party provider can become a large-scale data exposure problem.

Key questions

Q: What breaks when application vulnerabilities are not remediated quickly?

A: Attackers gain more time to move from a small code weakness to data theft, privilege abuse or service disruption. In practice, long remediation cycles turn scanning into an inventory exercise while the exposed application remains reachable. The risk is highest when the flaw sits in an internet-facing app, API or third-party service that handles sensitive data or authenticated sessions.

Q: Why do application vulnerabilities create such high risk in modern software environments?

A: Application vulnerabilities create high risk because modern software is complex, heavily interconnected, and released on compressed timelines. Weaknesses can enter through design flaws, third party components, authentication controls, or data handling. Once exposed, attackers can gain unauthorised access, steal or alter data, or disrupt service, and the blast radius can extend across the software supply chain.

Q: How do security teams know whether vulnerability assessment is actually working?

A: Teams should look for short triage cycles, high-confidence findings, and a clear link between scan results and remediation action. A working programme reduces uncertainty around what to fix first. If the same issues keep reappearing or the queue is dominated by false alarms, the tool is not helping governance.

Q: Should teams treat third-party applications differently from internal ones?

A: Yes. Third-party applications and cloud services need the same remediation discipline, but they also require explicit supplier accountability because the enterprise may not control the code or patch timeline. Security teams should require evidence for fixes, validate exposure paths that cross provider boundaries and include supplier risk in the same prioritisation process as internal vulnerabilities.

Technical breakdown

How application vulnerabilities become breach paths

An application vulnerability is only useful to an attacker when it reaches a control boundary, such as authentication, session handling, input validation, authorisation or data handling. Injection flaws can turn untrusted input into code execution or database access, while authentication failures let attackers impersonate users or bypass login entirely. Misconfigurations, weak cryptography, exposed secrets and insecure deserialisation extend that path into broader compromise. In practice, the vulnerability is the opening, but the security failure is the organisation’s inability to bound what an exploited flaw can reach.

Practical implication: Map each vulnerability class to the business function it can expose, not just to its CVSS score.

Why scanning alone does not reduce application risk

Scanning finds issues, but it does not resolve the operational problems that determine whether those issues become breaches. Static, dynamic, interactive and composition testing each produce different signals, yet all of them depend on inventory quality, asset scope, triage discipline and ownership. If applications, APIs, microservices and dependencies are not inventoried, findings go missing. If remediation is not tied to timelines and accountable teams, the attack surface stays open long after discovery. This is why mature appsec programmes treat vulnerability management as a workflow, not a tool category.

Practical implication: Build ownership and remediation SLAs into vulnerability management so findings cannot stall between detection and fix.

How application flaws intersect with identity and access control

Many application breaches become identity failures after the first exploit. Broken authentication, exposed session tokens, missing MFA on sensitive functions, overprivileged service accounts and insecure API access all turn application defects into unauthorised access paths. Once a session or credential is compromised, the attacker often needs little else to move laterally or exfiltrate data. That makes application security and IAM inseparable at the governance layer: if the application can issue, accept or reuse trust without strong controls, identity policy becomes part of the attack surface rather than a defence.

Practical implication: Review authentication, session and API controls alongside application vulnerability findings, not as a separate programme.

Threat narrative

Attacker objective: The attacker wants unauthorised access to data or systems through the weakest exposed application path, then enough persistence or reach to maximise theft and impact.

1. Entry occurs through an application flaw, often in a third-party or internet-facing service that accepts untrusted input or exposes sensitive functions.
2. The attacker abuses the flaw to bypass authentication, read sensitive data, or execute commands, depending on the vulnerability class involved.
3. Once inside, the attacker can entrench access, extend reach through exposed sessions or privileged functions, and extract data at scale.
4. The impact is breach disclosure, customer notification, regulatory exposure, legal liability and prolonged recovery costs.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

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

Application vulnerability management is really governance of exploitability, not just code hygiene. The article shows that the security problem is not the existence of flaws but the time they remain exploitable while owners, priorities and remediation paths stay unclear. That is a control-governance issue as much as an engineering issue. Practitioners should treat vulnerability management as a lifecycle process tied to risk ownership.

The named concept here is breach-path latency. This is the period between vulnerability discovery, prioritisation and effective remediation, during which attackers still have a working route into the environment. When that latency is long, scanning becomes a reporting function rather than a risk-reduction control. Security teams should measure and shorten that window across code, dependencies and deployed services.

Identity controls become brittle when application flaws expose authentication and session trust. The article’s examples of broken authentication, session handling failures and overprivileged accounts show that many application breaches are actually access-control failures in disguise. This matters for IAM and PAM teams because the compromise path often starts in the application layer but ends in identity misuse. Practitioners should align appsec and identity governance around the same high-risk workflows.

Third-party applications and dependencies are now part of the enterprise attack surface. The AT&T example in the article is a reminder that exposure does not stop at the perimeter or the internal SDLC. Third-party cloud services, APIs and component chains can turn a single flaw into a large-scale breach. Security leaders should extend governance, review and remediation accountability to external providers and software supply paths.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

Breaches driven by application flaws are becoming a governance problem as much as an engineering problem. When application security is measured only by scan output, the organisation misses the operational question of whether risky findings are actually closed before attackers reach them. Security leaders should watch for teams that can generate findings faster than they can assign, prioritise and verify fixes.

Breach-path latency is the control gap that matters here. If discovery, triage and remediation are separated across different owners, attackers get a wide window to exploit exposed apps, APIs and third-party services. That window shrinks only when vulnerability management, identity governance and supplier oversight are treated as one workflow.

Application security and IAM now overlap at the point where broken authentication, session exposure and overprivileged functions turn a code defect into unauthorised access. Practitioners should expect more scrutiny on how application teams prove that sensitive functions, credentials and sessions are actually constrained in production.

For practitioners

• Implement risk-based vulnerability triage Score findings by exposure, exploitability, data sensitivity and reachable business function, then route only the highest-risk items into accelerated remediation.
• Build end-to-end asset inventory Maintain inventories of applications, APIs, microservices, dependencies and third-party integrations so scans cover the full attack surface, not only known production systems.
• Tie remediation to accountable owners Assign each material finding to a named team with a deadline, validation scan and closure evidence so issues cannot linger after detection.
• Review authentication and session controls together Check broken authentication, token exposure, MFA coverage and privileged access paths in the same review cycle as code and configuration findings.
• Extend control coverage to third parties Require suppliers and cloud providers to share remediation evidence for flaws that can affect customer data, APIs or privileged integrations.

Key takeaways

• Application vulnerabilities remain a direct route to breach impact because they expose authentication, data handling and business functions that attackers can exploit without defeating broader perimeter controls.
• The article cites more than 40% of breaches, $4.88M average response cost and 277 days to identify and contain, which together show how long application flaws can remain exploitable.
• The strongest mitigation is not more scanning alone, but a governance model that assigns ownership, prioritises by exposure and validates remediation across internal and third-party applications.

Key terms

• Application Vulnerability: A weakness in software code, design, configuration, or dependencies that can be exploited to break confidentiality, integrity, or availability. In practice, the business impact depends on whether the flaw reaches data, identity, session handling, or privileged functions.
• Broken Authentication: Broken authentication is a failure in how a system proves that a caller is who or what it claims to be. For APIs, that often means weak token handling, replayable credentials, or poor validation of delegated access, which allows unauthorised callers to act as trusted integrations.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• Basic Web Application Attack: A common attack pattern that targets public login pages on web applications such as email, banking, social media, or SaaS portals. Attackers use stolen credentials, brute force attempts, or both to gain access. The pattern often leads to account takeover, fraud, or deeper intrusion.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect application risk to identity and access governance across modern environments.