AppSec prioritisation is shifting from severity scores to identity context

At a glance

What this is: This is a comparison of Arnica and Checkmarx One that finds AppSec is moving from raw scanning breadth toward contextual prioritisation, identity-aware routing, and agentic AI governance.

Why it matters: It matters because IAM, PAM, and security teams now have to account for developer identity, bot identity, and ownership drift inside AppSec workflows, not just vulnerability severity.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Arnica's comparison of Checkmarx One and AppSec prioritisation

Context

Application security platforms increasingly sit at the intersection of code quality, supply chain security, and identity governance. The real issue is no longer how many findings a scanner can produce, but whether a team can route those findings to the right human or system owner before risk drifts into production.

Arnica's comparison with Checkmarx One is useful because it exposes a deeper governance gap in AppSec programmes: identity context is often missing from triage, remediation, and policy enforcement. That gap becomes more visible as AI-generated code, bot-authored commits, and stale repository ownership make traditional assignment models less reliable.

For teams already wrestling with machine identity sprawl, this is not an abstract tooling debate. The same lifecycle and ownership problems seen in NHI governance reappear in developer workflows, especially when findings are assigned to people who have left the company or to automated actors with no durable accountability.

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. That produces noisy backlogs, wasted engineering effort, and delayed remediation for the issues that actually matter. A low-scoring issue in an exposed customer path can be more dangerous than a high-scoring issue that never reaches production.

Q: Why do departed developers create AppSec governance problems?

A: Because remediation depends on ownership that still exists. If a finding is assigned to someone who has left, the ticket often falls into a stale queue or a shared alias that nobody actively monitors. That turns AppSec into a tracking problem instead of a risk-reduction process and weakens accountability across the engineering identity lifecycle.

Q: How should security teams govern autonomous coding agents in software delivery pipelines?

A: Treat the agent, its sandbox, and its tool access as a single governed execution path. Require per-run identity, scoped credentials, signed triggers, and human approval before merge. The key is not to stop automation, but to ensure every autonomous action has a bounded lifecycle, a clear owner, and an auditable trail from trigger to release.

Q: Who is accountable when a supply chain finding is linked to a bot or workflow identity?

A: Accountability should rest with the human owner of the workflow or the team that authorised the bot's permissions, not with the bot itself. Non-human identities need a named operational owner, lifecycle review, and revocation path, otherwise remediation and incident response become impossible to enforce consistently.

Technical breakdown

Why severity-based AppSec scoring breaks down

Traditional AppSec tools rely on static scoring models such as CVSS, then layer queues, filters, and dashboards on top. That works poorly when exploitability depends on whether code is reachable, whether the dependency is loaded in production, and whether the responsible developer is still present. Context-aware prioritisation is different because it connects a finding to runtime exposure, repo ownership, and delivery path. In identity terms, it treats the code change as part of an accountability chain, not a detached vulnerability record.

Practical implication: teams should treat ownership, reachability, and pipeline exposure as triage inputs, not optional metadata.

Identity-aware routing across developer and bot identities

Finding routing fails when the assignee model assumes a stable human author. In modern repositories, authorship may belong to a departed engineer, a shared team alias, or an AI coding agent that generated the change but does not own the risk. Identity-aware routing resolves those entities to a current human decision-maker and preserves an audit trail of who dispatched the action and who can close it. That is a governance control as much as a workflow feature, because remediation without accountable ownership becomes backlog noise.

Practical implication: map repository identities to living ownership records and keep them synchronized with joiner-mover-leaver processes.

Agentic AI governance in the software delivery chain

Agentic AI changes AppSec because the system making the change is not always the same system that reviews or deploys it. If an AI agent can open pull requests, trigger pipelines, or alter configuration, then security policy has to apply at the moment of action, not after the fact. Governance needs to distinguish between generated code, delegated execution, and autonomous pipeline behaviour. That is where AppSec becomes adjacent to NHI governance: the agent, bot, or workflow token becomes a non-human actor whose permissions must be bounded and reviewed.

Practical implication: define policy for AI-generated changes separately from human-authored code and require explicit controls for delegated execution.

Threat narrative

Attacker objective: The attacker wants to move risky code or pipeline actions into production while avoiding timely ownership, review, and containment.

1. Entry occurs through code changes, pipeline actions, or third-party dependencies that enter the delivery chain with more trust than they deserve.
2. Escalation happens when stale ownership, overprivileged workflow identities, or unreviewed AI-generated actions expand the blast radius of a bad change.
3. Impact follows when vulnerable, malicious, or misrouted changes reach production faster than the organisation can attribute and contain them.

NHI Mgmt Group analysis

Severity-only AppSec is now a governance blind spot. CVSS is useful for standardisation, but it does not tell teams whether a finding is reachable, who owns it, or whether the responsible identity still exists. That creates queue inflation and false urgency, especially in large engineering organisations. The more code moves through ephemeral workflows, the less useful severity alone becomes as a decision mechanism. Practitioners should treat prioritisation as an identity and exposure problem, not only a vulnerability scoring problem.

Identity-aware routing is becoming a core AppSec control, not a convenience layer. When 82% of findings in one customer analysis belong to developers no longer at the company, routing failure is a governance failure. The control gap is not just stale tickets, but broken accountability across joiner-mover-leaver processes for engineering identities. That is why AppSec programmes increasingly need ownership resolution tied to current repository activity. Practitioners should align remediation routing with active identity lifecycle data.

Agentic AI creates a new class of non-human change authority. Once AI systems can write code, open pull requests, and trigger pipelines, they behave like governed non-human actors inside the delivery process. That means identity policy has to extend beyond human authorship into delegated execution and autonomous actions. This is where OWASP-NHI and software delivery governance intersect. Practitioners should define when a coding agent may act, what it may touch, and who is accountable for its output.

Supply chain security is converging with identity governance. AppSec is no longer just about code defects and dependencies. It now includes the identities that can move code, the tokens that can alter pipelines, and the permissions that can publish artifacts. That convergence explains why modern AppSec tooling is increasingly evaluated on identity context as much as on scan breadth. Practitioners should benchmark their controls on ownership, privilege, and traceability, not just on detection volume.

What this signals

AppSec leaders should expect ownership routing to become a measurable control objective, not an informal workflow preference. As AI-generated changes and departed authors become more common, the control surface shifts toward identity resolution, revocation, and traceability across engineering systems.

Identity-routing debt: when findings cannot reach a current owner, the organisation is carrying a hidden governance liability. That debt compounds across SCM, CI/CD, and ticketing, which is why teams should benchmark remediation against live repository activity and not legacy aliases.

The next evaluation step is whether AppSec platforms can describe who can act, who is accountable, and which non-human identities are authorised to move code. That is where software delivery governance and NHI controls begin to overlap in a way security teams can actually operationalise.

For practitioners

• Replace severity-only triage with contextual scoring Weight findings by reachability, repository exposure, code ownership, and whether the affected component is actually invoked in production. This reduces false urgency and makes remediation queue decisions defensible.
• Tie AppSec ownership to live identity records Synchronize repository owners, developer identity data, and team aliases with joiner-mover-leaver processes so findings do not land with departed staff or dead group inboxes.
• Treat AI coding agents as governed non-human actors Define policy for autonomous pull requests, pipeline triggers, and config changes created by AI agents, then restrict their permissions to task-scoped access and explicit approval paths.
• Audit secrets and pipeline permissions together Review leaked secrets, overprivileged service accounts, and workflow tokens as one control surface, because delivery-chain compromise usually crosses all three boundaries.

Key takeaways

• AppSec is moving beyond scan volume and severity scores toward ownership-aware prioritisation.
• Identity drift in engineering workflows creates the same accountability problems seen in NHI governance.
• AI agents and workflow identities must be governed as non-human actors if code delivery is to remain auditable.

Key terms

• Identity-aware prompt routing: A control pattern that ties each LLM request to verified identity and policy before the prompt reaches a model or tool. It prevents access decisions from being made too late in the workflow and keeps retrieval, execution, and logging tied to the original caller context.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.

What's in the full article

Arnica's full comparison covers the operational detail this post intentionally leaves for the source:

• Side-by-side feature coverage for SAST, SCA, IaC, secrets detection, SBOM, and ASPM across both tools
• Workflow examples for routing findings to active developers instead of departed authors or stale aliases
• The product's agentic AI policy model, including how governed rules reach coding agents and pipeline actions
• Deployment and pricing details that matter once teams move from evaluation to implementation

👉 The full Arnica comparison includes workflow detail, agentic governance, and deployment trade-offs.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and delivery workflows.