Software security maturity data is shifting toward AI-era risk

At a glance

What this is: This is a preview of Veracode’s upcoming State of Software Security report, highlighting how application-risk maturity is being measured and how AI-era threats and software supply chain pressure are shaping the next edition.

Why it matters: It matters because application security leaders, IAM teams, and security architects need to translate finding volume into remediation priorities, especially where software supply chain exposure and identity-controlled build paths can expand blast radius.

By the numbers:

• The 2025 report analysed 1.3 million unique applications and 126.4 million raw findings.
• The report’s press release reached a potential audience of 208.3 million and was viewed more than 10,500 times.
• The editorial media coverage reached around 380 million readers worldwide, with a UVM of 59 million in the first month.

👉 Read Veracode's preview of the upcoming State of Software Security report

Context

Software security maturity is increasingly measured by whether organisations can convert large volumes of vulnerability data into prioritised action. The article points to a familiar governance problem: most teams can collect findings, but fewer can consistently reduce security debt across application portfolios, supply chains, and AI-influenced development pipelines.

The primary identity intersection is indirect but real. Application risk management depends on the identity of build systems, service accounts, API keys, and developer access paths, so weakness in software security often becomes an identity governance problem downstream. That is typical for modern application security programmes, not an edge case.

Key questions

Q: How should security teams prioritise application security findings in cloud environments?

A: Security teams should prioritise application findings by combining severity with exposure, reachability, ownership, and business impact. A medium issue on an internet-facing production service can be more urgent than a critical issue in dead code. ASPM helps by correlating scanner output with runtime context so remediation reflects actual risk.

Q: Why does software supply chain security matter more in AI-assisted development?

A: AI-assisted development increases the speed and volume of code, dependencies, and pipeline changes entering production. That expands the number of identities, tokens, and trusted components involved in delivery. If those identities are over-privileged or poorly governed, the supply chain becomes a faster path to production compromise.

Q: What do security teams get wrong about measuring application risk maturity?

A: They often confuse output with progress. High finding counts, more dashboards, or more scans do not prove risk is falling. Mature programmes track whether fix speed is improving, whether critical debt is shrinking, and whether teams are reducing exposure in the systems that matter most.

Q: What is the difference between collecting findings and reducing security debt?

A: Collecting findings creates visibility. Reducing security debt requires prioritisation, engineering capacity, and sustained closure of the issues that create the most risk. Organisations can have excellent reporting and still carry dangerous debt if they do not convert evidence into remediation decisions.

Technical breakdown

How software security maturity is measured across application portfolios

Maturity in application security is not a single score. Veracode’s framing compares organisations across flaw prevalence, fix capacity, fix speed, security debt prevalence, and open-source critical debt. Together these metrics show whether teams are finding issues, remediating them, and preventing backlog from compounding. That matters because raw finding counts alone do not reveal whether risk is shrinking or simply being documented more efficiently. Practical maturity depends on trend direction, not dashboard volume.

Practical implication: measure remediation throughput and debt reduction together, not just scan volume.

Why AI-driven development changes software supply chain risk

AI-assisted development increases the number of code paths, dependencies, and machine-generated changes that enter the software lifecycle. That raises the importance of software supply chain controls because vulnerability introduction can now happen at speed and at scale, especially where open-source components, generated code, and automated pipelines interact. The governance problem is not just code quality. It is provenance, reviewability, and the ability to prove which identities and tools touched the pipeline.

Practical implication: tie pipeline access, secret handling, and dependency review into a single control view.

What context-driven remediation means for security debt

Context-driven remediation means organisations should prioritise vulnerabilities by exploitability, exposure, and business criticality rather than treating every finding as equally urgent. Security debt becomes persistent when teams fix easy issues first and leave high-risk exposures in place. The article’s framing reflects a broader shift in application security: the goal is not only to collect evidence of weakness, but to direct limited engineering time toward the issues that materially change risk.

Practical implication: rank findings by exposure path and business impact before assigning remediation work.

Threat narrative

Attacker objective: The attacker seeks to turn one weak point in the software lifecycle into broader downstream compromise or durable access to applications and deployment paths.

1. Entry occurs through AI-assisted development workflows, third-party dependencies, or exposed software delivery paths that increase the number of things an attacker can target.
2. Escalation follows when vulnerable code, mismanaged secrets, or over-privileged pipeline identities allow the attacker to move from a single flaw to broader software supply chain control.
3. Impact lands as persistent application risk, wider exposure across production systems, and remediation backlogs that security teams struggle to reduce.

NHI Mgmt Group analysis

Application security maturity is becoming a governance problem, not just a scanning problem. The article’s focus on flaw prevalence, fix speed, and security debt shows that maturity depends on operational follow-through, not tool output. Teams that can measure, prioritise, and close risk consistently will outperform those that merely collect findings. The practical conclusion is that security debt should be managed as a programme metric, not an after-the-fact audit result.

AI-era software pipelines create a stronger identity intersection than many teams recognise. When code generation, dependency ingestion, and automated release paths accelerate, the identity of service accounts, CI/CD tokens, and developer access becomes part of the attack surface. That makes identity governance relevant to software security even when the headline topic is application risk. Practitioners should treat pipeline identity as a core control plane.

Context-driven remediation is the real differentiator in security debt reduction. Organisations do not reduce risk by fixing the largest number of findings. They reduce risk by fixing the findings that are most exposed, most exploitable, and most likely to affect critical services. This shifts the discipline from volume-based reporting to decision-based security management, which is where mature programmes separate themselves.

Software supply chain security is now inseparable from resilience planning. The article’s emphasis on emerging AI-driven threats and supply chain pressure reflects a market moving toward more interconnected risk. That means application security, identity governance, and resilience planning need shared metrics and shared ownership. Practitioners should expect tighter convergence between development controls and security governance.

What this signals

Identity-controlled build paths are now part of software security governance. As AI-assisted development expands, the same lifecycle controls used for NHIs become relevant to CI/CD tokens, deployment secrets, and automation identities. Teams that already manage rotation, scope, and offboarding well will be better placed to absorb the next wave of application risk.

Security debt will increasingly be judged by remediation velocity, not just backlog size. Leaders will want proof that the worst exposures are being closed faster, particularly where application risk intersects with identity exposure in pipelines and cloud delivery. That puts pressure on security teams to align vulnerability management with identity and access governance.

The next maturity jump will come from linking application findings to identity context. If a vulnerable dependency is reachable only through a tightly scoped pipeline identity, the risk picture changes. If the same dependency is behind a broadly privileged token, the blast radius is much larger. That is where software security and identity governance converge in practice.

For practitioners

• Prioritise remediation by exposure and business criticality Build a triage model that scores findings using exploitability, internet reachability, asset value, and dependency depth so engineering time goes to the issues that can actually change risk. Use this model to separate backlog noise from true security debt.
• Map pipeline identities to software delivery risk Inventory CI/CD service accounts, deployment tokens, and build-system permissions, then restrict each to the minimum scopes required for release activity. Review where secrets are stored, who can read them, and whether any token can reach production environments without explicit approval.
• Track security debt as a leadership metric Report fix speed, fix capacity, and open critical debt together so leaders can see whether the programme is reducing exposure over time. Avoid reporting raw finding counts in isolation because they can rise even when actual risk is falling.
• Separate AI-generated change from human-reviewed change Require provenance checks and review gates for code generated or transformed by AI tools, especially where dependencies, configuration files, or pipeline scripts are altered. This reduces the chance that automated output quietly expands the attack surface.

Key takeaways

• The article frames software security maturity as a measurement and prioritisation problem, not a reporting exercise.
• Veracode’s 2025 analysis covered 1.3 million applications and 126.4 million findings, underscoring the scale of the remediation challenge.
• For practitioners, the main implication is to connect vulnerability triage, pipeline identity control, and supply chain governance into one operating model.

Key terms

• 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.
• Fix capacity: Fix capacity is the amount of remediation work a team can complete within a given period. It measures whether security and engineering resources are sufficient to turn findings into closed issues, which is a better indicator of maturity than scan counts alone.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full article

Veracode's full post covers the launch framing and report context this post intentionally leaves for the source:

• The upcoming State of Software Security report preview and why the 16th edition matters to practitioners
• The launch timeline for the 2026 report and webinar, including the publication sequence
• The broader AI-era themes Veracode says will shape the full findings, especially security debt and supply chain risk
• The communications and reach metrics from last year's release that are not needed for operational decision-making here

👉 Veracode's full post covers the report preview, the 2026 launch timing, and the AI-era themes behind the findings

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programmes that rely on them.