Dev-first AppSec is becoming the default for AI-assisted code

At a glance

What this is: This is an analysis of why developer-first application security programmes reduce friction, improve adoption, and better handle AI-assisted code.

Why it matters: It matters because IAM, AppSec, and security architecture teams increasingly need controls that work inside developer workflows, not alongside them, especially as AI-generated code expands the attack surface.

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.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arnica's analysis of dev-first AppSec for AI-assisted development

Context

Developer-first application security is a response to a workflow problem as much as a technical one. When findings arrive as noisy alerts, separate tickets, or compliance language that engineers cannot act on quickly, they are ignored or deferred. In practice, that means security controls fail not because they are absent, but because they sit outside the place where code is created, reviewed, and merged.

The article also intersects with identity governance because modern software delivery increasingly depends on human developer identities, CI/CD service accounts, and machine-generated code paths that must be trusted, authorised, and auditable. As AI-assisted coding grows, the control question shifts from how to scan code to how to govern the identities, privileges, and decision points that move code into production.

Key questions

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. Findings should be actionable, ownership should be clear, and remediation should not require manual re-entry into separate security tools. If the process creates friction, teams will route around it and governance will weaken.

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. In practice, that means developers can accept more code with less scrutiny, which raises the chance of vulnerable functions, exposed secrets, and compliance failures entering the repository and CI/CD pipeline.

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. High noise means analysts spend time validating artefacts rather than fixing real authorization defects. The better question is whether the tool consistently produces findings with evidence strong enough for developers and risk owners to act on without re-investigation.

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.

Technical breakdown

Why friction breaks application security adoption

Developer-native AppSec succeeds or fails on operational friction. If a tool interrupts builds, requires a separate login, or returns hundreds of findings with no prioritisation, developers will route around it. That is not a training problem. It is a control-design problem. Security feedback must be actionable, contextual, and delivered where code already lives, otherwise the programme creates audit evidence without changing behaviour. The real mechanism is workflow integration: IDEs, pull requests, and CI pipelines become the enforcement surface, not an external portal.

Practical implication: reduce context switching and tune findings so developers can fix issues without leaving their workflow.

How AI-assisted code changes AppSec governance

AI-assisted code introduces a governance gap because code can be produced at scale by tools that do not understand local policy, threat model, or business context. That increases the volume of code requiring trust decisions while reducing the time available for human review. The issue is not that AI-written code is automatically unsafe, but that traditional review patterns assume a human authored and understood each change. Once generation is delegated, policy enforcement has to move upstream into the review and commit workflow, with clear approval boundaries and traceability.

Practical implication: treat AI-generated code as a governed input stream and enforce policy at commit and review points.

Why actionable findings matter more than raw vulnerability counts

Raw vulnerability counts rarely tell teams what to fix first. In developer-first programmes, prioritisation has to reflect exploitability, reachability, and business context so that engineers spend time on real risk instead of triaging noise. Low false-positive rates are essential because repeated incorrect alerts train developers to ignore all alerts. This is the same behavioural pattern seen in other security domains where poor signal quality erodes trust. Effective AppSec reporting therefore needs to rank findings by likely impact and remediation practicality, not simply volume.

Practical implication: measure false positives, reachability, and pre-merge catch rates, not just backlog size.

Threat narrative

Attacker objective: The objective is not necessarily direct intrusion, but the creation of unmanaged software risk that survives review and enters production.

1. Entry occurs through developer workflow interruption, where noisy or poorly prioritised findings are introduced into the build, pull request, or IDE context.
2. Escalation happens when teams bypass or suppress security tooling because the alerts are too costly to interpret or act on.
3. Impact is accumulated code risk, including vulnerabilities that reach production because the security process lost developer participation.

NHI Mgmt Group analysis

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.

AI-assisted code creates a new trust boundary for software delivery. Once code is generated or accelerated by AI, teams cannot assume the author understood the security consequences in the same way a human reviewer would. That makes policy enforcement, traceability, and approval boundaries more important than scanner volume. For practitioners, the governance question is who is accountable for code that was not consciously written end to end by a person.

False-positive fatigue is a governance failure, not a nuisance metric. When teams accept noisy findings as normal, they are signalling that the security control is designed for reporting rather than remediation. That undermines AppSec, but it also weakens identity and privilege governance around the delivery pipeline because service identities and approvals become easier to bypass. The named concept here is developer trust erosion: repeated low-value findings train engineers to disengage, which turns security into theatre instead of control.

Dev-first AppSec aligns with least-friction governance, which is where modern identity programmes are heading. Whether the subject is human developers, CI accounts, or AI-assisted workflows, the common requirement is that policy must be enforced where action occurs. The programme that wins is the one that makes secure behaviour the easiest behaviour, not the one that produces the longest report.

What this signals

Developer trust erosion: security teams should treat low-quality findings as a governance risk because every ignored alert weakens the control plane around code delivery. The practical response is to simplify policy surfaces, improve prioritisation, and measure whether engineers act on findings before merge rather than after incident response.

AI-assisted development will force AppSec and IAM teams to converge around workflow identity, because the real control points are no longer just human users but CI service accounts, repository permissions, and review authorities. That makes least-privilege access, short-lived credentials, and auditable approvals central to secure software delivery.

Teams that continue to measure success by vulnerability volume alone will miss the operational signal. The stronger indicator is whether security feedback is changing developer behaviour inside the delivery pipeline, which is where controls either earn trust or get bypassed.

For practitioners

• 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. Avoid forcing engineers into separate portals or ticket queues that create avoidable context switching.
• 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. Track pre-merge versus post-merge catches to see whether the programme is changing behaviour.
• 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.
• Measure trust, not just volume Use developer adoption rate, false positive rate, and mean time to remediate by severity to judge whether the programme is actually being used. If engineers are routing around the tool, the metrics will show it.

Key takeaways

• Dev-first AppSec works because it reduces friction at the point where developers make security decisions, not because it adds more scanning.
• AI-assisted code expands the governance burden by increasing the amount of code that must be trusted, reviewed, and approved under tighter time constraints.
• The most useful AppSec metrics are the ones that reveal adoption, trust, and remediation behaviour, not just backlog size.

Key terms

• Developer-First Security: Developer-first security is an operating approach that places security feedback inside the tools and workflows developers already use. Its purpose is to reduce friction while improving remediation speed, ownership, and consistency across the delivery lifecycle.
• AI-assisted Code Generation: AI-assisted code generation is the practice of using a model to draft or modify source code for a developer. It can speed delivery, but it does not verify correctness, security, or compliance, so the output still needs the same review, testing, and change control as human-written code.
• Developer Trust Erosion: Developer trust erosion is the gradual loss of confidence in security tooling when findings are noisy, repetitive, or hard to act on. Once engineers expect alerts to be low value, they stop engaging with the control, which turns security feedback into a compliance artefact instead of a remediation driver.
• Pre-Merge Security Control: A pre-merge security control is any check that evaluates code before it enters the main branch or release path. In practice, it is most effective when it is contextual, low-noise, and embedded in the same review flow that developers already use for acceptance decisions.

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.

👉 Arnica's full blog post covers the developer workflow details, prioritisation model, and AI code governance examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that supports broader secure development and access control work. It is suited to practitioners who need identity governance thinking that extends into modern delivery pipelines.