Notifications
Clear all
Topic starter
19/08/2026 3:31 pm
TL;DR: AI coding assistants are driving 3 to 4 times more commits and more than 10 times as many OSS and SAST findings in Fortune 20 environments, according to Apiiro's analysis, while traditional review and scanning workflows struggle to absorb the volume. The governance problem is no longer code generation alone, but how to enforce runtime-aware, policy-based decisions before risky changes reach production.
NHIMG editorial — based on content published by Apiiro: analysis of AI-assisted development, AppSec governance, and runtime-aware remediation
By the numbers:
- Developers using AI assistants produced 3–4× more commits and security findings spiked over 10× in Fortune 20 enterprises.
Questions worth separating out
Q: How should security teams reduce rework when AI accelerates code changes?
A: They should move security checks closer to authoring time, because the cost of fixing issues rises sharply after merge.
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 AI-generated code risk?
A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows.
Practitioner guidance
- Map AI-assisted code growth to review capacity Measure how much additional change volume AI assistants are creating, then compare that against scanner throughput, reviewer capacity, and remediation queues.
- Push policy checks into the IDE Move approved patterns, dependency rules, and security exceptions into developer workflows so risky changes are intercepted before PR creation.
- Connect findings to runtime exposure Tie code issues back to the systems that actually run them, including gateways, IAM controls, and blast radius.
What's in the full article
Apiiro's full webinar discussion covers the operational detail this post intentionally leaves for the source:
- Developer workflow examples showing how AI-assisted changes are evaluated inside the IDE
- How runtime context is used to decide between autofix, guardrail enforcement, and risk acceptance
- The measurement model for acceptance rate, class-level elimination, and exploitability-based MTTR
- Examples of how the software graph informs prioritisation across code, runtime, and policy
👉 Read Apiiro's analysis of how AI coding assistants change AppSec risk →
AI-assisted code changes: what AppSec leaders need to change now?
Explore further
19/08/2026 4:13 pm
AI-assisted development creates a governance gap, not just a productivity gain. The article shows that code generation velocity now outpaces the capacity of manual review, scanner triage, and remediation queues. That is an AppSec governance problem because security processes still assume human-paced change. For identity programmes, the same pattern appears whenever fast-moving systems outrun access review and policy enforcement. Practitioners need controls that absorb machine-speed change without expanding exception debt.
A question worth separating out:
Q: How do you know if AI-assisted security automation is actually working?
A: Look for fewer new material risks landing in repositories, faster remediation for exploitable issues, and high acceptance of suggested fixes in the IDE and pull request flow. If output rises but backlog and exceptions also rise, automation is adding noise rather than reducing risk.
👉 Read our full editorial: AI-assisted development is outpacing AppSec controls
