Notifications
Clear all
Topic starter
18/08/2026 2:40 pm
TL;DR: AI coding assistants are accelerating code production faster than security controls are adapting, with Kusari reporting 85% adoption but only 9% treating AI-driven AppSec analysis as a must-have. That gap is allowing hallucinated dependencies, insecure patterns, and outdated libraries to reach production, turning AI-generated code into a measurable AppSec governance problem.
NHIMG editorial — based on content published by Kusari: Vibe coding security vulnerabilities are becoming one of the fastest-growing blind spots in application security
By the numbers:
- Research from the Cloud Security Alliance and Endor Labs found that 62% of AI-generated code contains design flaws or vulnerabilities.
- Veracode reported that 45% of AI-produced code fails against the OWASP Top 10.
Questions worth separating out
Q: How should security teams implement controls for AI-generated code in pull requests?
A: Security teams should make pull request scanning the default control point for AI-generated code.
Q: Why do AI coding agents increase supply-chain risk?
A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment.
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
- Implement pull request gates for AI-generated code Require SAST and SCA scans on every pull request that contains AI-assisted changes, with policy blocking merges until severe findings are resolved.
- Block unvetted dependencies by default Use an allowlist or approval workflow for any new package reference, and validate package names against trusted registries before build execution.
- Tag AI-assisted changes in the delivery pipeline Use commit metadata, IDE plugins, or repository labels so security teams can measure where AI-generated code enters the codebase and whether it passes review.
What's in the full article
Kusari's full report covers the operational detail this post intentionally leaves for the source:
- Survey methodology behind the 85% adoption and 9% must-have figures, useful for benchmarking your own programme.
- Per-language failure patterns, including where Java and other stacks showed the highest secure-generation failure rates.
- Practical examples of pull request scanning rules that target transitive dependencies, typosquatting packages, and insecure patterns.
- Developer workflow examples for secure prompt design and dependency policy enforcement.
👉 Read Kusari's analysis of vibe coding security vulnerabilities and AI-generated code risk →
Vibe coding security vulnerabilities: are your code review controls keeping up?
Explore further
18/08/2026 3:24 pm
AI-generated code is now a governance problem, not just a productivity trend. Once developers accept model output into production, the security model must treat generated code as untrusted input until verified. That means AppSec, IAM, and platform teams need shared ownership of review gates, dependency policy, and sensitive-path controls. The practical conclusion is simple: code provenance now belongs in security governance.
A question worth separating out:
Q: How can organisations reduce risk without stopping AI-assisted development?
A: Organisations should keep AI assistance but make the secure path the easiest path. That means secure prompt guidance, mandatory scanning, dependency allowlists, and extra review for security-critical code paths. The aim is not to ban speed, but to make sure productivity gains do not bypass the controls that protect production systems.
👉 Read our full editorial: Vibe coding security vulnerabilities are creating a new AppSec blind spot
