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

At a glance

What this is: AppSec spending is growing, but the article says the real return comes from risk-based, automated secure-by-design controls rather than compliance-led tool buying.

Why it matters: IAM, NHI, and security teams should care because the same governance problem appears in software programmes: fragmented controls, late detection, and manual remediation waste budget and hide real risk.

By the numbers:

• Security as a percentage of IT spending increased from 8.6% in 2020 to 13.2% in 2024.
• An estimated 80% will have adopted specialized processes and tools across the enterprise by 2027.
• IDC research indicates that 50% of software developers spend 19% of their time each week on security tasks.

Context

AppSec budget pressure is not just a spending story, it is a governance story. When security grows faster than visibility into where risk actually sits, organisations end up funding controls that are difficult to justify, hard to operationalise, or too late to change outcomes. In software programmes, that usually shows up as tool sprawl, duplicated analysis, and expensive remediation work after code has already moved downstream.

The identity connection is indirect but real. Application security depends on controlled access, secrets handling, and trustworthy developer workflows, which means the same lifecycle discipline used for NHI and IAM programmes applies here: know what is deployed, who can change it, and where approval and enforcement actually happen. The article's core argument is that budget increases only matter when control design follows risk, not procurement habit.

Key questions

Q: How should teams invest in AppSec when budgets are rising but risk remains fragmented?

A: Prioritise spend on controls that reduce exposure earlier in the SDLC and remove duplicate work from the operating model. Budget growth only turns into security ROI when it lowers remediation effort, improves prioritisation, and reduces the gap between detection and enforcement.

Q: Why do fragmented AppSec tools create more risk than just operational noise?

A: Because fragmentation delays triage, obscures ownership, and makes it harder to prove whether a control is working. Security teams spend time translating between tools instead of fixing issues, while developers receive conflicting signals. The result is slower remediation and weaker accountability, especially when code, pipeline, and ticketing systems are all separate.

Q: What are the signs that AppSec spending is not improving security outcomes?

A: Long remediation queues, repeated findings across releases, heavy manual triage, and developers spending significant time on security tasks are all warning signs. They indicate the programme is generating activity without materially reducing attack exposure or release friction.

Q: Should organisations prioritise secure-by-design over late-stage compliance fixes?

A: Yes, when the goal is to reduce cost and risk at the same time. Earlier controls usually prevent more rework, are easier to enforce, and create better evidence for governance than compensating for defects after deployment.

Technical breakdown

Why tool sprawl undermines application security ROI

AppSec tool sprawl appears efficient because teams can buy best-of-breed scanners, SAST, SCA, secrets scanning, and posture platforms for separate problems. In practice, the result is fragmented telemetry, duplicated findings, and manual correlation across consoles, which increases cost and slows remediation. The hidden loss is not only licensing spend but analyst and developer time spent reconciling inconsistent outputs. When controls are not normalised into one decision path, security work becomes a coordination exercise instead of a risk-reduction exercise. That breaks the economics of AppSec before it breaks the code.

Practical implication: Consolidate overlapping AppSec workflows into a single triage and remediation path before adding more point tools.

How secure-by-design shifts the economics of SDLC control

Secure-by-design means the control is applied before code reaches production, not after a finding has been discovered in a live environment. The article cites NIST's long-standing point that post-deployment defect fixing can be dramatically more expensive than earlier remediation, which is why shift-left only works when security requirements are built into design, build, and release gates. This is not about slowing delivery. It is about moving enforcement to the cheapest point in the lifecycle, where fixes are smaller, release risk is lower, and repeat findings are reduced.

Practical implication: Embed security checks in design and CI/CD so the earliest viable control point is also the cheapest remediation point.

Why automation changes AppSec from triage to prioritisation

Automation matters because the volume problem is no longer manageable by manual review alone. Once teams face hundreds or thousands of issues across the software supply chain, the bottleneck becomes deciding what matters first, not merely finding weaknesses. Automated prioritisation, response routing, and policy enforcement reduce MTTR and prevent critical issues from reaching production code. This is especially relevant where application security intersects with identity and secrets governance, because exposed credentials or over-permissioned build paths turn a software issue into an access problem.

Practical implication: Automate detection and prioritisation so engineers spend time on the vulnerabilities most likely to drive breach impact.

Threat narrative

Attacker objective: Exploit application weaknesses or exposed secrets before teams can remediate them, gaining a path to compromise software, users, or downstream environments.

1. Entry occurs when weaknesses in application code, dependencies, or secrets handling survive until production, where they become reachable through the software supply chain.
2. Escalation happens when fragmented AppSec tooling delays triage and allows high-risk vulnerabilities or exposed secrets to remain active across releases.
3. Impact is broader compromise, higher remediation cost, and avoidable release delay because security debt accumulates faster than teams can clear it.

Breaches seen in the wild

• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

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

AppSec ROI fails when organisations buy more inspection than enforcement. The article's central point is that budget growth does not automatically produce risk reduction if teams keep layering scanners, dashboards, and specialist tools without changing where decisions are made. In practice, the expensive part of AppSec is often the human reconciliation layer, not the tooling itself. The practitioner conclusion is simple: budget should follow a control model, not a catalogue.

Secure-by-design is now a budgeting strategy, not just a software-engineering slogan. The economics change when security is embedded before deployment, because every avoided late-stage defect saves rework, release delay, and incident exposure. For identity teams, the parallel is clear: lifecycle discipline only works when enforcement happens at issuance, approval, and change time, not after the fact. The field should treat early control placement as a financial control as much as a technical one.

Application security is moving toward policy-driven orchestration rather than point-product accumulation. The article points to ASPM-style centralisation because the real problem is correlating findings and turning them into action. That is the same governance pattern that appears in identity programmes when teams try to unify entitlements, secrets, and workflow evidence across systems. The practitioner implication is to measure how quickly a finding becomes a decision, not how many findings a stack can generate.

Secrets and developer workflow governance are part of the AppSec budget question. Once automated pipelines carry credentials, tokens, and code changes together, weak workflow control becomes both a security and cost issue. That is where identity security meets software assurance most directly. Teams should therefore evaluate whether their current spend reduces exposure at the point of change or merely adds another review layer after the risk has already spread.

Named concept: security debt compression. This article describes the economic effect of letting application risk accumulate until production, where every fix is slower, more expensive, and more disruptive. Security debt compression is what happens when organisations postpone enforcement and then pay a multiplied cost during release pressure. The practitioner conclusion is to shorten the interval between detection, decision, and remediation before that debt compounds.

What this signals

Application security is shifting from control accumulation to control orchestration. The organisations that will get real value from rising budgets are the ones that can reduce the number of places a vulnerability has to be reviewed before it is fixed. That same governance logic is now visible across identity programmes, where scattered control points rarely produce better outcomes than a smaller number of enforced lifecycle gates.

Security debt now behaves like financial debt. The longer an application weakness remains unaddressed, the more expensive it becomes to fix and the more likely it is to affect release velocity. For practitioners, that means AppSec effectiveness should be measured in reduced rework, shorter decision cycles, and fewer late-stage exceptions, not in raw alert volume alone.

For practitioners

• Define AppSec spend by risk tier Map budget lines to the asset classes, threat scenarios, and compliance obligations they actually protect. If a control covers only a small slice of business risk, do not let it consume enterprise-wide funding by default.
• Consolidate overlapping AppSec tooling Reduce duplicate scanners, redundant dashboards, and separate triage queues that force analysts to reconcile the same vulnerability in multiple systems.
• Move security checks into CI/CD gates Make design, build, and release controls fail early for critical issues so remediation happens before production exposure and release delay multiply the cost.
• Automate vulnerability prioritisation Use risk-based scoring and workflow routing so teams spend less time on low-value findings and more time on issues most likely to drive breach impact.
• Track security debt alongside release metrics Measure unresolved findings, average time to decision, and rework caused by late fixes so leaders can see whether AppSec spend is actually reducing downstream cost.

Key takeaways

• AppSec budget growth does not create better security on its own if teams keep funding fragmented tools and late-stage remediation.
• The article frames secure-by-design controls as the main route to software security ROI because early enforcement reduces rework, delay, and exposure.
• For practitioners, the test is whether spend shortens the path from finding to fix and removes avoidable manual triage from the operating model.

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.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management for teams that need stronger control over modern identity estates. It is designed for practitioners building programmes that connect identity governance to broader security operations.