Notifications
Clear all
Topic starter
02/08/2026 12:00 pm
TL;DR: Application risk management is becoming a data-to-action discipline, not a reporting exercise, according to Veracode. Its 2025 State of Software Security analysed 1.3 million applications and 126.4 million findings, using five maturity metrics to compare top and bottom performers and show where security debt still accumulates.
NHIMG editorial — based on content published by Veracode: From Data to Action, Key Insights About Advancing Security Practices
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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about measuring application risk maturity?
A: They often confuse output with progress.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Veracode's preview of the upcoming State of Software Security report →
Software security maturity in the AI era: what changes for teams?
Explore further
02/08/2026 1:06 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Software security maturity data is shifting toward AI-era risk
