Topic starter
18/08/2026 2:22 pm
TL;DR: AppSec prioritisation is shifting toward identity context, with Arnica saying ownership, reachability and pipeline exposure explain risk better than severity scores alone. That leaves teams needing current identity resolution across source control, collaboration tools and delivery paths to route findings to the right owner.
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: 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.
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.
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.
Glossary terms: Identity-aware remediation, Agentic code change, Pipeline identity, Reachability analysis
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
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