Topic starter
10/06/2026 12:21 am
TL;DR: More than 48,000 new CVEs were published in 2025, according to Orca Security, but the AppSec bottleneck is now prioritization and validation because code reachability and AI triage are needed to separate executable risk from noise. Severity scoring alone cannot tell teams which findings actually run in production.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “From Findings to Fixes with Code Reachability, AppSec Triage Agent, and the AppSec Dashboard”.
Key questions
Q: What breaks when AppSec teams rely on scan severity alone?
A: Severity-only triage breaks because it ignores runtime reachability, business context, and ownership.
Q: Why do reachable vulnerabilities deserve higher priority than generic scan results?
A: Reachable vulnerabilities matter more because the application actually invokes the vulnerable function, which means the issue can move from abstract weakness to practical exposure.
Q: How can teams tell if AppSec triage is breaking down?
A: Look for long queues, repeated scanner disagreement, rising exception volume, and engineers spending most of their time classifying findings rather than resolving them.
Practitioner guidance
- Prioritise reachable vulnerabilities first Rank findings by whether the vulnerable function is actually invoked in production code paths, not just whether it exists in a dependency tree.
- Map findings to code owners and runtime context Link SAST, SCA, and secrets findings to the repository, code path, and team responsible for remediation so validation does not stall in manual handoffs.
- Use AI triage only as a validation accelerator Require explainable reasoning, reviewer override, and rollback for automated true-positive or false-positive verdicts before using the output to change priority.
Bottom line: AppSec has moved from a discovery problem to a prioritisation problem, because not every vulnerable component creates the same level of real-world exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
11/06/2026 2:07 am
Application security has crossed from discovery to decisioning. The limiting factor is no longer whether tools can find vulnerabilities, but whether teams can prove which findings matter in production. When code reachability and contextual triage become necessary to move work forward, that is a sign the operating model has outgrown severity-first prioritisation. Practitioners should treat remediation capacity as the scarce resource, not scan volume.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why runtime context and ownership mapping remain persistent governance gaps.
A question worth separating out:
Q: What should teams do when security findings keep outpacing remediation capacity?
A: Teams should narrow the queue to executable, validated issues and stop treating every finding as equally actionable. That means proving reachability, validating the code context, assigning clear ownership, and using trend data to fix the workflow that keeps producing the same exposure. Without that discipline, remediation will always lag discovery.
👉 Read our full editorial: Application security is shifting from finding flaws to proving risk
12/06/2026 3:41 am
Executable risk has replaced raw vulnerability volume as the governing unit of AppSec. Once organisations can see tens of thousands of findings, the decisive question becomes which code paths are actually invoked in production. A programme that cannot prove reachability is still operating on theoretical exposure, not measurable risk. The practitioner conclusion is that remediation policy must be anchored to execution evidence, not just scanner output.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should organisations measure AppSec success by fewer findings or less exploitable risk?
A: They should measure less exploitable risk. A lower finding count can hide unresolved exposure if the remaining issues are the ones that actually run in production. A better test is whether the programme can show fewer reachable issues, faster remediation of validated findings, and less repeat introduction of the same control failures.
👉 Read our full editorial: Application security is shifting from finding flaws to proving risk
This post was modified 1 day ago by NHI Mgmt Group