Application security is shifting from finding flaws to proving risk

At a glance

What this is: This is an independent analysis of Orca Security’s AppSec updates, which focus on code reachability, AI triage, and dashboarding to help teams prioritise executable risk instead of raw vulnerability volume.

Why it matters: It matters to IAM and security teams because remediation workflows, ownership mapping, and risk validation are increasingly the control points that determine whether vulnerabilities, secrets exposure, and SDLC issues are actually contained.

👉 Read Orca Security’s analysis of code reachability, triage, and AppSec dashboards

Context

Application security teams are being overwhelmed by the volume of findings, but the deeper issue is that most programmes still treat every issue as if it deserves the same response. In practice, the security problem is not simply exposure. It is determining which code paths are actually exercised, which findings are likely to be true positives, and which issues reflect repeatable development behaviour rather than isolated defects.

That shift matters across IAM and NHI governance because the same operational pattern shows up in secrets, tokens, service accounts, and agent-adjacent development workflows: teams need context before they can decide whether a risk is real. In that sense, AppSec triage is becoming a governance problem as much as a detection problem, especially when the remediation backlog is larger than the team’s ability to validate it.

Orca’s starting position is typical for modern enterprise AppSec programmes. Most organisations have more visibility than they have decision capacity, which is why prioritisation frameworks are now the control plane for action.

Key questions

Q: How should security teams prioritise AppSec findings when CVE volume keeps rising?

A: Security teams should prioritise findings that are both validated and reachable in the application’s actual execution path. Severity alone is too coarse when thousands of issues are open. The best operating model is to combine exploitability evidence, ownership mapping, and workflow context so remediation effort is spent on issues that can affect production first.

Q: Why do code reachability and false-positive triage matter in AppSec programmes?

A: They matter because AppSec teams do not fail mainly on detection. They fail when the backlog becomes too noisy to act on. Code reachability proves whether a vulnerable function is actually used, while false-positive triage prevents teams from wasting time on findings that do not represent real exploitability. Together they turn scanning into decision support.

Q: How can organisations tell if an AppSec dashboard is actually useful?

A: A useful AppSec dashboard shows whether risk is being reduced over time, which repositories repeatedly introduce exposure, and whether remediation targets are being met. If it only reports counts, it is a reporting tool. If it surfaces control failures, ageing issues, and repeat offenders, it becomes a governance tool that supports action.

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.

Technical breakdown

Code reachability and executable exposure

Code reachability asks a narrow but decisive question: does the application actually invoke the vulnerable function, or is the issue only present in a dependency that never runs? By tracing call paths from first-party code into packages, the approach turns SBOM-style inventory into exploitability context. That is different from severity scoring, which estimates impact without proving whether the risky path is reachable in the deployed application. Reachability can also surface exact source lines, giving developers a concrete place to validate the finding. In practical terms, the output is not “there is a vulnerability” but “this vulnerability is in the execution path.”

Practical implication: use reachability to separate production-relevant issues from theoretical exposure before you create remediation tickets.

SAST triage with code context and data flow

An AppSec triage agent sits between raw static analysis and developer action. It evaluates code context, data flow, and sanitization patterns to decide whether a finding is likely a true positive or a false positive. That matters because many SAST programmes fail not on detection quality, but on the cost of review. If analysts must manually inspect every high-priority result, triage becomes the bottleneck and developer trust erodes. Orca’s model also adjusts risk scoring after validation, which changes the operational queue rather than just adding another opinion layer. The key mechanism is verdict refinement, not more alerting.

Practical implication: apply automated triage to high-volume SAST streams where review effort is blocking remediation throughput.

Application risk dashboards and SDLC control signals

A centralized AppSec dashboard is most useful when it shows how risk changes over time, not just how many findings exist today. By aggregating remediation SLAs, vulnerability trends, top violated controls, and risky repositories, the dashboard shifts the conversation from point-in-time backlog to recurring control failure. That is especially important when exposed valid secrets or ageing dependency issues repeatedly appear across teams. The architecture here is program-level visibility: leadership needs to see whether the same development pattern keeps reintroducing exposure. The dashboard therefore becomes a governance instrument, not just a reporting view.

Practical implication: track recurring control violations and repeat-offender repositories so you can fix the source pattern, not only individual findings.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Executable risk is the right named concept for this shift. A vulnerability is only operationally relevant when the application actually executes the vulnerable path and the organisation can act on it with confidence. That is why combining call-path evidence with false-positive suppression changes the unit of work from “finding” to “reachable, validated issue”. The implication is that AppSec governance should be measured by reduction in executable exposure, not by raw issue counts.

Context collapse is now a recurring control failure across AppSec and NHI-adjacent workflows. Findings generated without ownership, runtime context, or code flow are difficult to validate, assign, and close. This is the same governance pattern that appears when secrets, tokens, or service-account exposure is discovered without lifecycle context. The implication is that security teams need decisions grounded in execution evidence, not inventory alone.

Top Violated Controls is more useful than another backlog metric. If the same development behaviours keep producing exposure, the problem is systemic rather than incidental. A programme that only reports volume learns nothing about why risk keeps returning. Practitioners should use control-pattern data to identify where developer workflow, code review, or release discipline is repeatedly failing.

From our research:

• 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.
• For a broader lifecycle view, the Ultimate Guide to NHIs shows why visibility, rotation, and offboarding remain intertwined controls.

What this signals

Executable risk will become the more useful unit of measurement for AppSec teams as CVE volume continues to rise and backlog pressure increases. Programmes that cannot distinguish reachable issues from theoretical ones will keep spending on noise instead of risk reduction.

Secrets exposure is still a structural problem across identity programmes, and that matters here because application risk is often driven by the same weak control surfaces that govern non-human identities. When code, config, and CI/CD are treated as acceptable credential storage, remediation speed becomes less important than preventing recurrence.

Teams should expect stronger convergence between AppSec reporting and identity governance reporting, especially around ownership, lifecycle context, and remediation accountability. The next step is not more findings, but clearer evidence of what was actually eliminated from production.

For practitioners

• Prioritize reachable vulnerabilities first Triage issues by proving whether the vulnerable function is actually invoked in the deployed application, then defer non-executable findings until higher-risk work is complete.
• Use code context to validate SAST findings Require data flow, sanitization, and control-path evidence before escalating a high-priority static analysis result into the remediation queue.
• Tie findings to named code owners Map each validated issue to the repository, service, or team that actually invokes the vulnerable path so tickets do not stall in security-owned queues.
• Track recurring control failures by repository Review dashboards for repeated violations, duplicate exposures, and ageing findings so you can address the development pattern causing the risk instead of only the individual issue.

Key takeaways

• Orca’s message is that AppSec has become a decision problem: teams now need proof of reachability and validation before they can act with confidence.
• The scale of the issue is already material, with more than 48,000 new CVEs published in 2025 and too many programmes still trapped in backlog triage.
• Practitioners should measure success by reduced executable exposure, better ownership mapping, and faster validation of high-priority findings.

Key terms

• Code Reachability: Code reachability is the practice of determining whether a vulnerable function is actually executed by the application in a real runtime path. It separates theoretical exposure from exploitable exposure by tracing call paths from first-party code into dependencies and identifying what the application truly uses.
• False Positive: A false positive is a security finding that appears risky but does not represent exploitable behaviour in the target system. In AppSec, false positives consume analyst time and slow remediation, so validation mechanisms that distinguish them from true positives are essential to keeping response queues useful.
• Application Security Triage: Application security triage is the process of deciding which findings deserve immediate remediation, which require more validation, and which can be deferred. It combines severity, context, ownership, and execution evidence so security teams can focus effort on issues that are both real and actionable.
• Exploitable Exposure: Exploitable exposure is risk that can be exercised in practice, not just described in theory. It exists when a vulnerable code path, reachable dependency, or misused secret can be invoked in the running environment, making the issue relevant to production security and remediation prioritisation.

Deepen your knowledge

Code reachability and contextual triage are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with noisy findings and identity sprawl across development pipelines, it is worth exploring.

This post draws on content published by Orca Security: code reachability, AppSec triage, and application risk dashboards. Read the original.