Notifications
Clear all
Topic starter
18/08/2026 2:42 pm
TL;DR: AI coding assistants are now used or planned by 84% of developers, while research cited by Kusari shows the output often carries more security flaws, hallucinated dependencies, and missing defensive controls than human-written code. The governance problem is no longer adoption itself, but the lack of workflow controls that treat AI-generated code as untrusted input.
NHIMG editorial — based on content published by Kusari: AI coding assistants have become standard-issue tools in modern software development
By the numbers:
- 84% of developers now use or plan to use AI coding assistants, and 51% rely on them daily.
- GitGuardian found that 6.4% of repositories using GitHub Copilot leak at least one secret.
- 9% of respondents consider AI-driven security analysis a, er AI-driven security analysis a must-have capability.
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 teams get wrong about AI-generated documentation and code review?
A: They often assume documentation or review output is proof of oversight.
Practitioner guidance
- Treat AI-generated code as untrusted input Require the same level of security scrutiny for AI-assisted changes as for code from any external contributor, especially where authentication, validation, or secrets handling are involved.
- Embed SAST and SCA in the pull request workflow Run static application security testing and software composition analysis automatically on every PR so insecure patterns and transitive dependency issues are visible before merge.
- Block unverified package names from AI suggestions Add registry checks and allowlists so hallucinated dependencies, typosquats, and newly registered lookalikes cannot move from suggestion into the build.
What's in the full article
Kusari's full article covers the operational detail this post intentionally leaves for the source:
- Feature-by-feature breakdown of AI code review and dependency management capabilities in the developer workflow
- Survey table showing how developers rank SAST, SCA, IDE integration, and AI security analysis priorities
- Practical examples of inline PR security analysis for direct and transitive dependencies
- Discussion of how maintainers used the tool to catch issues that AI code generation missed
👉 Read Kusari's analysis of AI coding assistant risk and AppSec controls →
AI coding assistants and AppSec gaps: what teams need to know?
Explore further
18/08/2026 3:26 pm
AI-assisted development has become an application security governance problem, not just a developer productivity choice. Once AI tools are part of the code path, organisations inherit a second code author whose output must be controlled like any other untrusted supply chain input. That changes how security, engineering, and platform teams should think about code review, dependency trust, and release gating. The practical conclusion is that AppSec controls must sit inside the workflow, not outside it.
A question worth separating out:
Q: Should organisations treat AI coding assistants as part of the security boundary?
A: Yes. If an AI assistant can generate code, open pull requests, or influence deployment, it is operating inside the security boundary and must be governed accordingly. That means controlling its connectors, monitoring its outputs, and limiting the credentials it can access.
👉 Read our full editorial: AI coding assistants widen appsec gaps across code and supply chain
