Notifications
Clear all
Topic starter
19/08/2026 3:30 pm
TL;DR: Over 70% of developers say security slows them down, and over 40% of new code in some repositories is AI-assisted, according to Arnica. The governance gap is no longer just scanner noise but whether AppSec can keep pace with developer workflows and AI-generated code before risk reaches production.
NHIMG editorial — based on content published by Arnica: Dev-First AppSec Programs That Developers Use (June 2026)
By the numbers:
- Over 70% of developers report that security slows them down, driving avoidance behaviour in day-to-day coding workflows.
- Over 40% of new code is now AI-assisted in some repositories, creating a governance gap for AppSec teams.
Questions worth separating out
Q: How should security teams embed AppSec controls into developer workflows?
A: They should place controls where developers already work, such as code review, build, test, and deployment systems.
Q: Why do AI coding assistants increase AppSec governance risk?
A: They increase risk because they optimise for speed and plausible output, not for context-aware security validation.
Q: What do security teams get wrong about false positives in code scanning?
A: They treat false positives as a nuisance metric instead of a control-quality signal.
Practitioner guidance
- Embed security feedback in the developer workflow Surface findings in IDEs, pull requests, and CI jobs so remediation happens where code is written, reviewed, and merged.
- Recalibrate triage to exploitability and reachability Prioritise findings by likely exploitability, reachability, and business context, then suppress repetitive low-value alerts that drive alert fatigue.
- Govern AI-assisted code at commit time Add policy checks, review gates, and traceability for AI-generated code before it is merged, because downstream scanning is too late to prevent workflow-driven risk accumulation.
What's in the full article
Arnica's full blog post covers the operational detail this post intentionally leaves for the source:
- Workflow examples for surfacing findings directly in pull requests, IDEs, and CI/CD pipelines.
- Specific prioritisation logic based on reachability, business context, and false-positive reduction.
- Implementation detail for AI-assisted code review and inline auto-remediation suggestions.
- Metrics examples for developer adoption, remediation time by severity, and pre-merge versus post-merge findings.
👉 Read Arnica's analysis of dev-first AppSec for AI-assisted development →
AI-assisted code and AppSec friction: what teams need to change?
Explore further
19/08/2026 4:13 pm
Dev-first AppSec is really a control-plane problem, not a tooling preference. Security programmes that ignore developer workflow create the same failure pattern seen in other identity-heavy environments: controls exist, but they are not used because they are too far from the point of action. The practical lesson is that enforcement must sit inside pull requests, CI, and review paths if it is expected to influence behaviour.
A question worth separating out:
Q: How can organisations tell whether developers are actually using AppSec tools?
A: Look at developer adoption rate, pre-merge versus post-merge catch rates, and mean time to remediate by severity. Those signals show whether the control is embedded in the workflow or being bypassed. If usage is low and alerts are ignored, the programme is creating visibility without changing outcomes.
👉 Read our full editorial: Dev-first AppSec is becoming the default for AI-assisted code
