Notifications
Clear all
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.
NHIMG editorial — based on content published by Arnica: Arnica vs Checkmarx One: AppSec Compared
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.
Questions worth separating out
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.
Q: Why do departed developers create AppSec governance problems?
A: Because remediation depends on ownership that still exists.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read Arnica's comparison of Checkmarx One and AppSec prioritisation →
Identity context in AppSec: are severity scores enough anymore?
Explore further
18/08/2026 3:13 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AppSec prioritisation is shifting from severity scores to identity context
