Topic starter
18/08/2026 2:22 pm
TL;DR: AppSec teams now need context-aware prioritisation because 82% of findings in Arnica customer repositories belong to developers no longer at the company, while most tools still rely on CVSS and scan volume rather than ownership, reachability, or pipeline exposure, according to Arnica. That shift makes identity-aware routing and autonomous governance of AI-generated changes a practical control problem, not just a workflow preference.
Editorial analysis by NHI Mgmt Group, based on content published by Arnica: “Arnica vs Checkmarx One: AppSec Compared July 2026”.
By the numbers:
- 82% of findings belong to developers no longer at the company, making identity-aware routing a real workflow gap.
Key questions
Q: What breaks when AppSec teams rely on severity scores without identity context?
A: Severity scores break down when they are used without ownership, reachability, and delivery context.
Q: Why do stale code owners create remediation risk in AppSec programmes?
A: Stale code owners slow remediation because findings are routed to people who no longer own the service or no longer work there.
Q: How should teams govern AI-generated code when they cannot review every change?
A: Teams should shift from source-only assurance to runtime assurance.
Practitioner guidance
- Implement identity-aware finding routing Map SCM authors, chat identities, and agent identities to a current human owner so findings do not stall in stale inboxes or team aliases.
- Score findings by reachability and ownership Combine exploitability, repository exposure, and active code ownership so critical issues in reachable code outrank high-severity noise.
- Govern agentic code changes as identity events Require traceable identity, scoped authority, and policy enforcement for AI-generated commits, pull requests, and pipeline actions.
Bottom line: AppSec prioritisation is moving toward identity context because ownership, reachability, and pipeline exposure explain operational risk better than severity scores alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:13 pm
Identity context is now a first-class AppSec control plane: severity scores no longer describe operational risk on their own. AppSec programs now need to know who owns the finding, whether that identity is still active, and whether the code path can actually be reached. That pushes prioritisation into identity governance, not just vulnerability management. Practitioners should treat ownership and reachability as control inputs, not triage notes.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should pipeline permissions be treated as application security risk?
A: Pipeline permissions should be treated as application security risk whenever a trusted identity can move code, secrets, or artefacts toward production. A low-severity issue becomes much more serious if the same path can be used by a service account, bot, or overprivileged token. AppSec and IAM need a shared view of that delivery path.
👉 Read our full editorial: AppSec prioritisation is shifting from severity scores to identity context