Most writing about application security describes a problem that keeps getting bigger. That picture is accurate, and it is incomplete. Several things have changed in the last few years that let a security programme promise the business something it could not promise before: a short, defensible list of what matters, fixes that arrive with the finding, and a way to adopt AI safely instead of slowly. The opportunity belongs to teams that move from finding problems to closing them.
In short
- Exploitation data is now free and current. CISA KEV and FIRST EPSS let any team rank by real-world exploitation, not theoretical severity.
- Detection has commoditised. Strong open-source engines exist for most scanning categories, so budget can move to prioritisation and remediation.
- AI can draft the fix. Explaining a finding and proposing a change used to cost an engineer’s hour; it is becoming a review task.
- Security can become an enabler. A team that can govern AI agents and prove compliance continuously says yes faster.
Four shifts that create the opening
KEV, EPSS"] --> O["Short, defensible
priority list"] B["Open-source engines
mature detection"] --> O O --> F["Fix at the speed
of development"] C["AI-assisted
remediation"] --> F F --> E["Security as
an enabler"] D["Regulation and
board attention"] --> E style O fill:#ccfbf1,stroke:#0d9488 style E fill:#99f6e4,stroke:#0f766e
1. Exploitation data changed what “critical” can mean
When CISA launched the Known Exploited Vulnerabilities catalog in late 2021 it gave every organisation a free, authoritative list of vulnerabilities attackers are actually using; it has since grown past a thousand entries. FIRST’s EPSS adds a daily probability of exploitation for every published CVE. Combined with your own exposure and data context, they make it realistic to promise: everything known to be exploited and reachable is fixed within days.
2. Detection became a commodity
Ten years ago, good scanning meant expensive licences. Today Trivy, Opengrep, Gitleaks, Syft, Checkov, OWASP ZAP, Prowler and Falco are widely used, actively maintained open-source engines. Commercial engines remain strong, but the gap has narrowed enough that the decisive difference between programmes is no longer what they detect. It is what they do next.
3. AI can draft the remediation
The expensive part of a finding has always been the developer’s time to understand it and work out the change. Language models are good at exactly that: explaining a finding in context and proposing a fix for a human to review. The opportunity is real but needs care. What is sent to the model, and whether code leaves your environment, should be explicit decisions.
4. Boards and regulators are paying attention
Disclosure rules, product liability in the EU and sector regulation have put software security on board agendas. That brings scrutiny, and it also brings sponsorship. A CISO who can show a credible, improving risk number has a stronger hand in budget conversations than at any time before.
From finding to fixing
Success measured in coverage and findings raised. Developers receive long lists, without context, from several tools. Security reports volume; the board hears “it’s complicated”.
Success measured in exploitable exposure removed and time to fix. Developers receive a short list, each item with its reason and a proposed change. The board hears one number, and its trend.
The loop that matters: the developer gets the reason and the fix in the same place as the failure.
A worked illustration: what changes in a quarter
Consider an illustrative organisation of 300 developers carrying 9,000 open scanner findings, of which 1,400 are labelled Critical by CVSS. The security team’s stated SLA is “criticals in 15 days”. In practice, about 120 criticals are closed per month, so the SLA is missed for almost all of them and the board report shows a number that never falls.
| Step | Effect on the list | Why |
|---|---|---|
| Correlate across tools and rescans | 9,000 → roughly 6,500 unique | Same issue reported by several tools and branches |
| Mark dev-only, test-code and unreachable findings | Critical-by-CVSS 1,400 → several hundred | Scope and exposure context |
| Rank by KEV, EPSS, exposure and data | P1 ≈ 60, P2 ≈ 400 | Known exploitation and business impact |
| Set SLA: P1 in 7 days, P2 in 30 | P1 list is finishable within a sprint | Capacity now matches policy |
Nothing about the organisation’s actual exposure changed on day one. What changed is that the team can now make and keep a promise. Within a quarter the board report can show known-exploited, reachable findings falling towards zero, and a time-to-fix figure that is improving. Those numbers are defensible because every step that produced them is recorded on each finding.
The figures here are invented to show the mechanics. The reductions at each step on your own estate are the first thing worth measuring, and they are usually persuasive on their own.
Where the value lands
| Opportunity | Who benefits | How you would measure it |
|---|---|---|
| Less noise | Developers, AppSec | Raw-to-actionable ratio; findings per developer per sprint |
| Faster fixes for what matters | Business, CISO | Median time to remediate P1 and P2; SLA adherence |
| Tool consolidation | CFO, security operations | Licences retired; consoles analysts must use |
| Continuous compliance evidence | Audit, risk, legal | Audit preparation hours; repeat findings |
| Safe AI adoption | Product, engineering | AI features and agents shipped with inventory and policy in place |
| Credible board reporting | Board, CEO | One risk number, defined the same way each quarter |
data
IBM’s 2024 Cost of a Data Breach study found that organisations making extensive use of security AI and automation had average breach costs substantially lower, by about USD 2.2 million, than those that did not, and identified and contained breaches faster.
Source: IBM Security, Cost of a Data Breach Report 2024. Correlation, not proof of cause; organisations that automate also tend to be more mature in other ways.
The changing role of the AppSec team
When detection is automatic and prioritisation is policy-driven, the AppSec team’s time moves. Less of it goes on triaging scanner output by hand and chasing duplicates; more goes on the work only people can do.
Reads scanner output, removes duplicates and false positives, decides by hand what to send to which team, and answers developers who ask which findings they can ignore.
Owns the priority policy and the context model, reviews the few findings the policy cannot decide, works with teams on systemic fixes, and governs new surfaces such as AI agents.
That shift is also the answer to the staffing problem. A team of five cannot read forty thousand findings. It can maintain a policy that ranks them, and spend its expertise on the hundred that the policy flags as genuinely dangerous.
Objections worth taking seriously
| Objection | What is true about it | How to address it |
|---|---|---|
| “Deprioritising findings means accepting risk.” | It does. Every programme already accepts risk, implicitly, by not finishing the list. | Make the acceptance explicit and recorded, with reasons and review dates. |
| “EPSS and KEV miss new threats.” | Both lag novel exploitation, and EPSS is a probability. | Use them to order work, not to ignore anything; exposure and data context still raise unexploited findings. |
| “AI fixes could introduce bugs.” | They can. | Treat them as drafts for review, run them through the same CI gate, and control what code the model sees. |
| “Open-source scanners are not enterprise grade.” | Support and rule quality vary. | Use them where they are strong, accept commercial output where they are not; the decision layer should take both. |
Security as an enabler of AI
The largest opportunity may be the one least discussed in security terms. Every organisation is under pressure to adopt AI, and most security teams are being asked to approve AI features and agents faster than they can review them. A team that can show an inventory of every model and agent, map AI findings to the OWASP LLM Top 10, and enforce what each agent may do before it acts, can say yes, with these conditions instead of not yet.
How to take it
Get to one list
- Correlate existing scanner output in one place
- Add KEV, EPSS and exposure context
- Agree P1–P4 and the SLA with engineering
- Baseline the raw-to-actionable funnel
Close the loop
- CI gate on new P1s only
- Fix guidance and AI-drafted changes in front of developers
- Retire overlapping tools where the queue covers them
- Board reporting on exploitable exposure and MTTR
Enable the business
- AI inventory and agent policies as a standard for new launches
- Continuous compliance evidence for PCI, SOC 2, DORA or CRA
- Attack-path view joining code, cloud and identity
- Security metrics in product and engineering reviews
For the CISO
Reposition the programme around one promise: exploitable exposure fixed within an agreed time.
Use the moment of AI adoption to become the function that makes it safe, not the one that delays it.
For the AppSec lead
Keep the engines you trust. Spend new effort on correlation, context and remediation.
Make AI-drafted fixes a review task with clear rules about what data the model sees.
For the board
The question to ask is not “how many vulnerabilities do we have” but “how quickly do we close the ones that matter”.
Security that can approve AI safely is a competitive advantage, not a cost centre.
The opportunity is not to find more. It is to fix what matters, fast, and prove it.
The data, the engines and the AI to do that now exist. What remains is the operating model.