Topic starter
20/08/2026 5:53 pm
TL;DR: AI coding tools are accelerating insecure code, secret leakage, and dependency risk faster than many AppSec programmes can absorb, with Xygeni citing 35 new CVEs in March 2026 from AI tools, 62% of AI-generated code containing flaws per CSA, and AI-assisted commits leaking secrets at more than twice the human rate. The security model has to shift from review-heavy workflows to continuous controls that match development velocity.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “How to Secure AI-Generated Code in CI/CD”.
By the numbers:
- The Georgia Tech Vibe Security Radar project recorded 35 new CVEs in March 2026 directly attributable to AI coding tools.
- CSA research found that 62% of AI-generated code contains design flaws or known vulnerabilities.
Key questions
Q: What breaks when AI code review tools are allowed to analyse untrusted pull requests?
A: The review workflow itself becomes an attack surface.
Q: Why do AI-assisted commits increase secret exposure risk?
A: AI-assisted workflows increase secret exposure because developers often paste credentials into prompts or generated snippets, and those values can then appear in code, scripts, logs or historical commits.
Q: What do organisations get wrong about scanning AI-generated code?
A: The common mistake is treating more scanning as a complete answer.
Practitioner guidance
- Enforce SAST on every AI-assisted commit Scan every commit, not just pull requests, and tune findings for the failure classes AI tools repeatedly introduce: missing authentication, CSRF, SSRF, insecure deserialisation and hardcoded credentials.
- Add continuous secrets scanning and automatic revocation Cover repositories, pipeline logs, historical commits and container images, then revoke exposed API keys, tokens and service credentials immediately after detection.
- Block untrusted dependencies before install Require malware detection, typosquatting analysis and exact version or digest pinning for dependencies suggested by AI tools, especially where package names are unfamiliar or newly introduced.
Bottom line: AI-generated code is not simply faster code. It is a higher-volume source of repeatable security defects, secret leakage and risky dependency choices that legacy review models struggle to absorb.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:32 pm
AI-generated code is now a control-design problem, not just a code-quality problem. The article shows that the risk is systematic, with flaws repeating across output patterns rather than appearing as one-off defects. That means organisations cannot rely on review queues built for human pace. The decisive issue is whether security controls operate at AI speed, not whether developers write faster.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern AI-suggested dependencies and package trust?
A: Teams should treat AI-suggested dependencies as untrusted until validated. That means checking for typosquatting, malware behaviour, suspicious install scripts and package provenance before installation, then enforcing exact pinning and build-time policy. The goal is to stop hallucinated or malicious packages from becoming an easy supply chain entry point.
👉 Read our full editorial: AI-generated code is exposing secrets faster than AppSec can catch