Security spend is rising, but risk reduction still lags

At a glance

What this is: This blog argues that rising security spend does not reduce risk when teams optimise for alert volume, severity scores, and disconnected tools instead of exploitability and remediation.

Why it matters: It matters to IAM practitioners because the same governance failure appears in identity, NHI, and application programs when prioritisation, lifecycle control, and operational ownership are fragmented.

By the numbers:

• The average enterprise now runs 50 security tools, and most teams added more last year than the year before.
• 95–98% of AppSec findings do not require immediate action, so teams are triaging noise rather than risk.

👉 Read Appknox's analysis of why security investment is not reducing risk

Context

Security investment only reduces risk when teams can distinguish exploitable exposure from background noise. This article is about that governance gap in application security, where more tools, more dashboards, and more alerts can still leave mobile and API risk unmanaged. The same pattern shows up in identity programs when access review, privilege governance, and remediation ownership are split across teams and workflows.

For identity practitioners, the useful bridge is not the product category but the operating model. NHI and IAM programs fail in the same way when controls generate findings without changing access, when lifecycle events are not tied to remediation, and when teams lack a shared view of what is actually exploitable. That is why risk reduction depends on control correlation, not isolated coverage.

Key questions

Q: How should security teams decide what to fix first when alerts keep multiplying?

A: Teams should prioritise findings by exploitability, reachable impact, and business criticality, not by raw severity or alert count. A high-score issue that cannot be reached is usually less urgent than a moderate issue on an exposed path with active abuse potential. The aim is to reduce risk, not to clear a queue.

Q: Why do more security tools sometimes increase incident risk?

A: Because more tools often create more queues, more false positives, and more handoffs. When engineers lose trust in alerts or have to wait across multiple systems, they bypass controls or ship before issues are fully resolved. The risk is not coverage alone, but delayed and fragmented decision-making.

Q: What breaks when remediation is separated from detection?

A: Findings lose urgency when they are detached from the team, workflow, and fix path that can act on them. That delay lets attackers exploit issues before action is taken, especially in fast-changing environments. Effective security programs measure time to effective fix, because a finding that never changes the environment does not reduce risk.

Q: How can security leaders tell whether their program is reducing risk or just generating reports?

A: They should track whether exploitability-weighted findings are declining, whether high-risk issues are fixed faster, and whether new assets are entering governance before they become blind spots. If dashboards look busy but exposure stays flat, the program is reporting activity rather than reducing risk.

Technical breakdown

Why severity scores do not equal exploitability

Severity scoring estimates how bad a vulnerability could be in isolation. Exploitability asks whether a realistic attacker can weaponise it in your environment, through your actual attack paths, with the access and timing available today. In practice, teams often treat a high score as a decision, when it is only a signal. That creates false urgency in low-risk areas and hides low-scoring issues that combine into a viable attack chain. Practical implication: prioritise based on exploitability context, not severity alone.

Practical implication: use exploitability-weighted triage to decide what gets fixed first.

How tool sprawl creates blind spots in mobile and API security

Tool sprawl is not just duplication. Each scanner, monitor, or platform sees a narrow slice of the environment and generates its own taxonomy, which makes correlation difficult. Mobile apps, third-party SDKs, and exposed APIs often sit outside the coverage model that web-first tools were built for, so drift accumulates between releases. The result is an illusion of coverage, where the stack looks broad but the actual attack surface is only partially visible. Practical implication: map tools to exposed assets, not to procurement categories.

Practical implication: inventory the attack surface first, then test whether each control actually reaches it.

The remediation gap is where risk accumulates

Detection is only useful if a finding reaches the team that can fix it, in a form they can action quickly. When security findings live in reports, spreadsheets, or separate queues, remediation slows or never happens. The article’s core point is that the risk window is now defined less by discovery and more by handoff speed, contextual guidance, and ownership. That is a governance problem as much as a technical one. Practical implication: measure time from finding to effective fix, not just time to detection.

Practical implication: build fix-path ownership into your vulnerability and identity workflows.

Threat narrative

Attacker objective: The attacker aims to exploit unprioritised, cross-layer weaknesses before defenders can turn findings into remediated control changes.

1. Entry begins with exposed mobile APIs, third-party SDK paths, or other unmanaged attack surface that bypasses the main security stack.
2. Escalation occurs when security teams cannot correlate findings across tools, so exploitable weaknesses remain prioritised as isolated, low-urgency alerts.
3. Impact follows when remediation arrives too slowly to matter, allowing attackers to weaponise the gap before fixes are deployed.

NHI Mgmt Group analysis

Security investment without governance correlation becomes control theatre. More tools do not automatically create lower risk when each tool produces its own queue, metric, and remediation path. The article shows that enterprises can spend heavily while still failing to turn findings into action. In identity programs, the same failure appears when IAM, PAM, and NHI controls are measured independently instead of as one lifecycle. Practitioners should treat correlation as a control objective, not a reporting feature.

Exploitability is the missing decision layer in modern security programs. Severity tells teams what looks bad; exploitability tells them what is likely to matter in the real environment. That distinction matters across application, cloud, and identity governance because attackers chain conditions, they do not respect product silos. In NHI and IAM operations, the equivalent mistake is to prioritise entitlement counts or review completion instead of effective exposure. Practitioners should align remediation around realistic abuse paths.

Attack surface drift is a governance problem, not just a testing problem. New APIs, SDKs, releases, and integrations create risk between scheduled reviews, which means the environment changes faster than control assurance. That pattern also maps to identity lifecycle drift, where access and secrets remain valid after the business reason for them has moved on. The named concept here is remediation latency debt: the longer the gap between discovery and effective fix, the more risk accumulates outside the security program’s reach. Practitioners should shorten that gap before it becomes operationally expensive.

Mobile and API security failures often expose identity blind spots. This article is about AppSec, but the deeper governance issue is that authentication flows, session handling, and third-party integrations are identity problems as much as code problems. When mobile or API controls are detached from identity governance, teams miss where credentials, tokens, and access decisions actually live. Practitioners should bring IAM, application security, and runtime validation into the same control conversation.

What this signals

Remediation latency debt: when discovery, triage, and fix live in separate systems, risk accumulates faster than security teams can clear it. The practical response is to align vulnerability management, identity governance, and application ownership around one remediation clock, not three different reporting cycles.

For identity and NHI programmes, the warning is familiar: visibility without lifecycle control creates the same false confidence as a scanner with no fix path. Teams should watch for exposed access paths, stale entitlements, and findings that remain open because no workflow owns them end to end.

The broader trend is toward exploitability-led governance, where security leaders will be expected to prove that a control changes exposure rather than merely records it. That shift aligns with the NIST Cybersecurity Framework 2.0 and with operational identity controls that can demonstrate real reduction in attack surface.

For practitioners

• Measure exploitability, not just severity Rebuild prioritisation so that every finding is ranked by reachable attack path, exposed asset, and realistic attacker capability. Use severity as input, but require an exploitability decision before work enters the remediation queue.
• Map controls to the full attack surface Inventory mobile apps, APIs, SDKs, and runtime paths, then verify which tool actually sees each asset. Where no control reaches a path, treat it as unmanaged exposure rather than covered risk.
• Collapse the handoff between security and fix teams Create a single remediation workflow that sends findings with context, ownership, and fix guidance directly to the team that can change the code, configuration, or access state. Track time to effective fix, not ticket closure.
• Treat identity-controlled paths as part of AppSec Include authentication flows, tokens, and third-party integration points in application risk reviews, because those are often the places where exposed access becomes exploitable.

Key takeaways

• Security spend does not reduce risk when tools are disconnected from prioritisation, ownership, and fix execution.
• Exploitability, remediation speed, and cross-layer correlation matter more than alert volume or severity scores.
• Identity, application, and workflow governance need to operate together if teams want measurable risk reduction.

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.
• Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.
• AI attack surface drift: The expansion or change in an AI system’s risk profile after launch because of new data, prompts, integrations, tools, or model updates. It is the reason AI security must be monitored continuously rather than approved once and forgotten.
• Tool Sprawl: Tool sprawl is the accumulation of overlapping systems that each solve part of the same identity or operations problem. In practice, it creates duplicate workflows, inconsistent policy enforcement, and more manual reconciliation, which weakens confidence in access decisions and slows down secure scaling.

What's in the full article

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

• How KnoxIQ validates exploitability and generates proof-of-concept evidence for prioritisation
• The mobile and API-specific scenarios Appknox uses to separate signal from noise
• Examples of developer-ready remediation guidance that shorten the handoff from security to engineering
• The article's full breakdown of where Appknox sees the biggest remediation bottlenecks in practice

👉 Appknox's full post expands on the remediation gap, exploitability prioritisation, and mobile and API coverage blind spots.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is a practical fit for security practitioners who need stronger control over access, remediation, and governance decisions.