Notifications
Clear all
Topic starter
18/08/2026 2:44 pm
TL;DR: AppSec slows delivery when findings sit outside developer workflows, and Forrester says 53% of development teams feel that friction, according to Arnica’s analysis. The central issue is not scan coverage but remediation flow, because backlog growth, ownership gaps, and delayed context turn visibility into a governance problem, not a detection problem.
NHIMG editorial — based on content published by Arnica: How to Build a Developer-Native AppSec Program Without Slowing Down Engineering
By the numbers:
- 53% of development teams report security requirements slow delivery when AppSec lives outside developer workflows.
- The average ratio of AppSec engineers to developers sits around 1:100, and in high-growth engineering orgs it can reach 1:200 or beyond.
- A growing backlog with 100% scan coverage is still a failing program.
Questions worth separating out
Q: How should security teams implement application security without slowing developers down?
A: Put controls inside the normal delivery workflow.
Q: Why do AppSec programmes create friction when findings are routed through tickets?
A: Ticket-based routing adds extra translation steps between the finding and the fix.
Q: What breaks when AppSec tools do not know the current code owner?
A: Findings stall when they are assigned to the wrong person, especially after team changes or AI-generated code changes.
Practitioner guidance
- Embed findings in the developer workflow Surface security findings in the IDE, pull request, or commit context so developers can act without leaving the tool they already use.
- Rebuild ownership around the current code owner Route every finding to the present maintainer of the codebase, not the historical author.
- Automate routine remediation paths Auto-remediate known-safe patterns such as secret exposure, dependency updates, and other predictable fixes while escalating only findings that require human judgement.
What's in the full article
Arnica's full blog covers the operational detail this post intentionally leaves for the source:
- Specific workflow examples for routing findings through IDE, pull request, and commit channels
- Implementation patterns for current code-owner resolution when original authors or AI agents are no longer the right point of contact
- Automation approaches for low-risk fixes such as secret exposure and dependency updates
- Metric examples for tracking fix rate, merge delay, and remediation backlog health
👉 Read Arnica's analysis of building developer-native AppSec without slowing engineering →
Developer-native AppSec and the governance gap teams keep missing?
Explore further
18/08/2026 3:27 pm
Developer-native AppSec fails when remediation is treated as a downstream ticketing problem. The article shows that scan coverage alone does not create security outcomes if findings arrive outside the developer workflow. Security teams still lose time to triage, ownership lookup, and cross-team negotiation. The field should treat delivery context as part of the control itself, not as an optional interface layer.
A question worth separating out:
Q: How can organisations measure whether AppSec controls are working?
A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.
👉 Read our full editorial: Developer-native AppSec is closing the gap between scans and fixes
