AppSec prioritisation is shifting from severity scores to identity context

At a glance

What this is: Arnica’s analysis says AppSec prioritisation is shifting from severity scores to identity context because ownership, reachability, and pipeline exposure now determine which findings matter first.

Why it matters: This matters to IAM, PAM, and AppSec teams because code ownership, service identity, and pipeline permissions are now part of security triage, not just developer workflow metadata.

By the numbers:

• 82% of findings belong to developers no longer at the company, making identity-aware routing a real workflow gap.

Context

AppSec prioritisation breaks down when teams treat every finding as a scanner output instead of a governance decision. Severity alone does not tell you whether the vulnerable code is reachable, whether the owning developer is still active, or whether a pipeline identity can move a weakness into production.

This article sits at the intersection of application security and identity governance because code ownership, bot identities, service accounts, and pipeline permissions now determine remediation order. That makes the question less about scan volume and more about who can act, which changes the operating model for both AppSec and identity teams.

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. A critical flaw in unreachable code is not the same as a moderate flaw in a live service with active deployment paths. Without identity context, teams spend time on findings that no current owner can fix quickly, while easier-to-exploit issues stay in the queue.

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. In modern SCM environments, that failure gets worse when bot commits and AI agents are involved. A current identity mapping is necessary so findings land with someone who can actually fix and approve the change.

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. That means correlating deployments, traces, logs, and outcome metrics so behaviour can be validated after code is generated and released. The practical goal is not perfect review coverage, but a dependable record of what the system actually did in production.

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.

Technical breakdown

Why severity scoring misses identity context in AppSec

CVSS tells you how severe a flaw could be in isolation, but AppSec teams rarely operate in isolation. A finding only becomes actionable when it is tied to a reachable code path, an active repository owner, and a deployment path that can actually expose the issue. That is why context-aware prioritisation uses ownership, branch exposure, and pipeline state alongside vulnerability data. In modern software delivery, the control problem is not just detection. It is deciding which finding belongs at the front of the queue because it can be exploited, merged, or shipped soonest.

Practical implication: prioritise findings by exploitability and ownership context, not by severity score alone.

How identity-aware routing changes remediation in CI/CD

Identity-aware routing treats the developer, bot, or service account behind a change as part of the security signal. When authors leave the company, when agents create commits, or when stale aliases absorb alerts, findings fall into dead-end queues that delay remediation. Mapping SCM identity, chat identity, and agent identity to a current human owner closes that gap. This is especially relevant where pipeline automation creates changes faster than a traditional ticketing workflow can keep up. The governance issue is not that alerts exist, but that they reach nobody who can safely merge or fix them.

Practical implication: maintain current identity mappings between source control, collaboration tools, and remediation owners.

Why agentic AI expands AppSec beyond code scanning

Agentic AI changes the security model because autonomous tools can write code, open pull requests, and trigger pipeline actions without a human sitting in the loop for each step. Traditional AppSec scanning can still inspect the output, but it cannot by itself govern the action chain that produced the change. That creates a new boundary between code analysis and identity governance. In practice, the relevant control is no longer only whether the code is vulnerable. It is whether the actor that produced the code had bounded authority, traceable identity, and a policy envelope that constrained autonomous behaviour.

Practical implication: govern AI-generated changes as identity-bearing actions, not only as code artefacts.

Threat narrative

Attacker objective: The attacker wants to use trusted development and pipeline identities to turn code access into persistent software supply chain compromise.

1. Entry occurs when exposed secrets, stale tokens, or overprivileged pipeline identities provide access to repositories or CI/CD systems.
2. Escalation follows when the attacker uses that access to alter code, trigger autonomous pipeline actions, or persist through trusted automation paths.
3. Impact is the ability to inject malicious changes, steal developer secrets, or move compromised code toward production through legitimate delivery channels.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Dead ownership is a governance failure, not a routing inconvenience: findings attached to departed developers, stale aliases, or bot identities create a control gap that severity scoring cannot fix. When 82% of findings sit with people who are no longer there, the programme has already lost the remediation handoff. The underlying problem is identity lifecycle, not alert quality. Teams should rebuild ownership models around current human resolution, not legacy repository metadata.

Agentic AI creates a new AppSec category that classic scanners only partially cover: autonomous code generation and pipeline triggering introduce a policy problem before they introduce a code problem. The relevant control question is whether the agent’s authority, identity, and action scope are governed at execution time. This is where NHI, agentic AI, and AppSec converge. Practitioners should treat autonomous changes as governed actions with identity-bound accountability.

Software supply chain risk now includes identity scope inside the delivery path: tokens, service accounts, and pipeline permissions are not side issues, they are the access layer for code propagation. A vulnerability without a path to execution is lower risk than a modest flaw attached to a trusted deployment identity. That means identity governance has become part of application risk scoring. Security teams should re-evaluate whether their AppSec model can see trusted automation, not just vulnerable code.

AppSec prioritisation needs a named concept for this shift: identity-aware remediation routing: the finding is not fully prioritised until it is tied to a current owner, a reachable code path, and a valid delivery context. This is the practical bridge between software risk and identity governance. Without it, teams keep scoring issues that no one can action quickly. Practitioners should design triage around identity resolution, not just scanner output.

From our research library:

• 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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity-aware remediation routing will increasingly define AppSec maturity: teams that still route findings by scanner output alone will keep losing time to stale owners, inactive developers, and bot-authored changes. The governance shift is toward current accountability, not historical commit metadata.

Secrets sprawl and ownership drift now interact: internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), which means private codebases cannot be treated as lower-risk by default, according to the State of Secrets Sprawl 2026. Practitioners should expect secrets detection to remain noisy unless identity context and repo governance improve together.

For practitioners

• 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.
• Review pipeline credentials as AppSec inputs Inventory service accounts, tokens, and CI/CD permissions that can move code from repository to production, then reduce standing access where possible.
• Treat stale ownership as a lifecycle defect Reconcile repository ownership whenever developers leave, teams reorganise, or bots begin acting on behalf of humans, because remediation depends on current accountability.

Key takeaways

• AppSec prioritisation is moving toward identity context because ownership, reachability, and pipeline exposure explain operational risk better than severity scores alone.
• Findings tied to departed developers, stale aliases, or autonomous pipeline actions create a governance gap that scanner output by itself cannot close.
• Teams that want faster remediation need current identity resolution across source control, collaboration tools, and delivery paths.

Key terms

• Identity-aware remediation: Identity-aware remediation is response that connects a suspicious message or session to account-level action such as revocation, reset, or isolation. It matters because email threats often become access threats, and containment has to reach beyond the inbox to be effective.
• Agentic code change: An agentic code change is a software modification produced or triggered by an autonomous AI system that can select actions and timing without direct human approval for each step. These changes still require accountability, because the risk is not only the code itself but also the authority used to create and move it.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and engineering teams connect identity controls to the workflows that create and move risk.