AppSec budget growth is shifting toward secure-by-design ROI

At a glance

What this is: This is an AppSec budgeting and operations analysis showing that higher spend does not automatically translate into better security outcomes.

Why it matters: It matters to IAM practitioners because the same governance problems that plague AppSec, fragmented controls, manual review, and weak policy enforcement, also undermine identity, NHI, and access programmes.

By the numbers:

• security as a percentage of IT spending has increased steadily over the past five years, from 8.6% in 2020 to 13.2% in 2024.
• Some research suggests that only 10-20% of cybersecurity technology is actually ever used.
• 50% of software developers spend 19% of their time each week on security tasks.

👉 Read OXSecurity's analysis of AppSec budget optimisation and secure-by-design ROI

Context

AppSec budget growth only matters if it changes how risk is managed. The core problem is not a shortage of tools or funding, but a mismatch between spend, operational reality, and the speed at which software is built and shipped. In practice, compliance-driven purchasing, fragmented tooling, and delayed remediation produce familiar governance failure modes that also appear in identity programmes.

For identity and NHI teams, the parallel is clear. When access, secrets, and policy enforcement are treated as after-the-fact checks rather than design constraints, organisations pay more to correct issues later and still carry residual exposure. That is why secure-by-design thinking, automation, and measurable control coverage matter across AppSec, IAM, and machine identity governance.

Key questions

Q: What breaks when AppSec budgets grow without better governance?

A: Budgets without governance usually produce tool sprawl, duplicate findings, and slow remediation. Teams spend more on licensing and reporting but still lack clear ownership of risk. The result is often worse decision quality, because security leaders can see more issues without reducing the time it takes to fix them.

Q: Why do fragmented security tools increase breach risk even when visibility is high?

A: Because attackers exploit the delay between detection and enforcement. A stack can generate many alerts while still failing to revoke access, isolate workloads, or block movement in time. High visibility without coordinated response creates an operational gap that functions like an attack surface.

Q: How can security teams know if contextual AppSec is working?

A: They should measure the share of findings that are reachable in production, the time from detection to owner assignment, and the percentage of backlog items that are closed without repeated re-triage. If those numbers improve, the programme is reducing noise rather than simply producing different noise.

Q: Which control model is better for AppSec, compliance-first or risk-based?

A: Risk-based control models are more effective because they align spending with the applications, data, and threats that matter most. Compliance still matters, but it should not dictate every investment. A programme that only optimises for audit outcomes often misses the operational gaps that attackers actually exploit.

Technical breakdown

Why tool sprawl inflates AppSec cost

Tool sprawl appears efficient because each product covers a narrow need, but in practice it creates duplicated licensing, duplicated alerts, and duplicated triage. When teams must correlate findings across scanners, posture tools, and ticketing systems by hand, the cost is not only financial. It also slows decision-making and weakens prioritisation. This is a governance problem as much as an operations problem because the organisation loses a single view of risk, ownership, and remediation status across the software lifecycle.

Practical implication: rationalise overlapping controls and make one system responsible for risk correlation and remediation tracking.

Why secure by design reduces downstream remediation

Secure by design shifts control left, meaning issues are identified before code reaches production or before architecture decisions become hard to reverse. The reason this reduces cost is simple: fixing defects earlier avoids the compounding work of re-testing, rollback, incident handling, and emergency patching. In AppSec, this often means embedding SAST, SCA, and secrets scanning into development workflows so that vulnerability discovery and policy enforcement happen during build and review, not after deployment.

Practical implication: move the highest-volume checks into CI/CD so remediation happens before release pressure turns into risk acceptance.

What ASPM changes in application security governance

Application Security Posture Management centralises findings across tools, correlates them, and helps teams prioritise what matters most. That architecture matters because AppSec teams do not usually fail from a lack of data, but from too much unprioritised data. ASPM also creates a stronger bridge between security and developers by turning findings into actionable remediation guidance rather than disconnected alerts. For identity teams, this is familiar: control visibility only becomes useful when it can drive lifecycle decisions, ownership, and enforcement.

Practical implication: use posture management to connect discovery, prioritisation, and policy enforcement instead of treating them as separate functions.

Threat narrative

Attacker objective: The attacker aims to exploit application weaknesses before they are detected and remediated, turning development speed and control fragmentation into breach opportunity.

1. Entry occurs when application weaknesses, exposed secrets, or supply chain flaws reach production through accelerated development pipelines. Escalation follows when fragmented tooling delays detection and remediation, allowing vulnerable code to persist across releases. Impact arrives when those weaknesses become the critical path to breach or large-scale software compromise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Compliance-led AppSec budgeting creates a false sense of control. When programmes optimise for passing audits rather than reducing exposure, spend becomes detached from actual risk. The article captures this tension clearly: buying for compliance can increase cost without improving decision quality. For identity and NHI teams, the same pattern appears when controls exist on paper but are not tied to lifecycle enforcement. The practitioner conclusion is to fund risk reduction, not checkbox coverage.

Tool sprawl is a governance failure, not just an efficiency problem. Fragmented scanners, posture platforms, and manual workflows create blind spots that slow remediation and obscure ownership. That makes policy enforcement weaker even when total spend rises. In identity programmes, the analogue is fragmented identity stores and disconnected secret management. The practitioner conclusion is to reduce control overlap and make accountability measurable end to end.

Secure-by-design is the only durable answer when release velocity rises. The article is right to treat late-stage fixing as an economic drain because downstream remediation compounds cost, delay, and technical debt. The same logic applies to NHI and IAM, where access, secrets, and privilege should be governed before deployment rather than inspected after exposure. The practitioner conclusion is to bake control checks into build and release paths, not into post-incident cleanup.

ASPM represents a broader shift from finding issues to governing decisions. Centralising findings matters only if it changes who owns remediation, how risk is prioritised, and when policy blocks release. That is the real lesson for identity security as well: visibility without enforcement is reporting, not governance. The practitioner conclusion is to treat correlation engines as decision systems, not dashboards.

Developer-centric security works only when it is policy-led. Giving builders more responsibility can improve speed, but only if policy enforcement is automated and reviewable. Otherwise, organisations merely move risk into a faster workflow. That matters for machine identity, secrets, and access governance too, where delegated control must remain auditable. The practitioner conclusion is to pair developer enablement with enforceable guardrails.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected.
• For a broader view of exposure patterns, The 52 NHI breaches Report shows how compromise often begins with unmanaged credentials and weak lifecycle control.

What this signals

AppSec and NHI governance are converging around the same operational truth: visibility only matters when it changes policy enforcement and ownership. For identity programmes, that means posture data, secret scanning, and access review signals should feed directly into lifecycle controls, not sit in separate reporting layers. The programme signal is clear, correlate control data into decisions or keep paying for noise.

Control debt: the longer organisations delay shifting security into build and release pipelines, the more expensive each defect becomes to fix. That is just as true for application weaknesses as it is for machine identities and privileged access paths. Teams should watch for rising exception rates, repeated remediation churn, and control failures that appear only after deployment.

Where AppSec teams are moving toward ASPM and automated triage, identity teams should expect similar pressure to prove that governance controls are both measurable and enforceable. The practical implication is that access, secrets, and policy exceptions need the same kind of correlation and prioritisation now common in modern application security operations.

For practitioners

• Rebuild AppSec spend around risk concentration Map budget lines to the applications, pipelines, and data paths that create the highest breach exposure, then cut spend that only satisfies compliance reporting. Use a risk assessment to justify where tool consolidation will improve both coverage and control quality. This is where budget decisions become defensible.
• Consolidate overlapping application security controls Reduce duplicate scanners and disconnected posture tools that force manual reconciliation across teams. Make one platform or operating model responsible for correlation, ownership, and remediation status so teams can see where issues remain open. That clarity is essential for release governance.
• Embed security checks into CI/CD workflows Move SAST, SCA, and secrets scanning into build and review stages so vulnerabilities are identified before deployment. Tie failed checks to policy enforcement rather than advisory tickets so release decisions reflect actual risk. This shortens the path from discovery to fix.
• Measure remediation speed as a security outcome Track mean-time-to-response, fix acceptance, and re-open rates, not just detection volume. If the same issues keep reappearing, your programme is producing activity rather than improvement. Use these metrics to show whether automation is reducing technical debt.

Key takeaways

• AppSec spend rises, but without governance it can still produce fragmented tooling, slow remediation, and weak ROI.
• Secure-by-design controls reduce cost because they move vulnerability discovery and enforcement earlier in the software lifecycle.
• ASPM and automation matter because they turn AppSec from issue discovery into measurable, policy-led risk reduction.

Key terms

• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Secure-by-Design: Secure-by-design means security requirements are built into the development process rather than added after release. The practical aim is to define minimum acceptable controls early, then enforce them consistently so products cannot ship without passing baseline security checks.
• 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.
• Mean Time To Respond: Mean Time To Respond, or MTTR, measures how long it takes to contain or remediate an incident after detection. In AI-assisted SOCs, MTTR improves only when automation is accurate, bounded, and able to support safe escalation paths.

What's in the full article

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

• How OXSecurity frames AppSec budget optimisation across compliance, tool consolidation, and secure-by-design investment choices.
• The platform-centric argument for ASPM, including how centralised correlation changes developer remediation workflows.
• Examples of no-code workflow automation that reduce manual AppSec handling and enforce policy during release.
• The article's specific claims about MTTR reduction, security debt reduction, and developer-centric enforcement.

👉 OXSecurity's full article covers budgeting, automation, and ASPM in more operational detail.

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 practitioners connect identity controls to the broader security programmes they already run.