TL;DR: 31.4% of AI-generated submissions in a coding tournament still contained vulnerabilities even when security-focused participants were trying to win, according to Symbiotic Security research, with path traversal making up 56.5% of flaws and zero-vulnerability code sometimes losing on functionality. The data shows why secure generation needs scanning in the loop, not just better prompting.
NHIMG editorial — based on content published by Symbiotic Security: Introducing Symbiotic Code and the secure coding tournament findings
By the numbers:
- 31.4% of all submissions contained at least one vulnerability in the secure coding tournament.
- The average submission contained 1.28 vulnerabilities across 102 evaluated submissions.
- Path traversal accounted for 56.5% of the 131 vulnerabilities found in the tournament.
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why do AI coding assistants still produce insecure code?
A: They learn patterns from large code corpora that contain both secure and insecure examples, and they do not reliably reason about all dataflow or trust-boundary issues.
Q: What do organisations get wrong about secure prompting for coding agents?
A: They often assume better prompts are enough.
Practitioner guidance
- Scan generated code before it reaches review Integrate static application security testing into the AI coding path so that insecure output is flagged at generation time, not only in CI or after merge.
- Set an absolute security acceptance threshold Reject AI-generated code that exceeds your defect tolerance, even if it functionally outperforms another submission or implementation.
- Constrain prompts around trust boundaries Require prompts to specify input validation, allowlists, dangerous operation restrictions, and secret-handling rules before code generation begins.
What's in the full report
Symbiotic Security's full research post covers the operational detail this post intentionally leaves for the source:
- Round-by-round submission patterns, including which challenge types produced the highest vulnerability counts.
- The judging rubric and session mechanics used to score secure output versus functional output.
- Examples of prompt strategies that led to zero-vulnerability submissions and where they still failed functionally.
- The workshop and gameplay details behind the secure coding tournament methodology.
👉 Read Symbiotic Security’s analysis of secure AI code generation and tournament findings →
AI code generation and security scanning: what changed in practice?
Explore further
Secure AI code generation is now a governance problem, not just a developer productivity issue. If AI tools can generate vulnerable code even in a security-conscious tournament, then enterprise teams cannot rely on prompt quality alone to protect application integrity. The risk extends into IAM, secrets handling, and service trust, because insecure code often becomes the control plane for identity decisions. Practitioners should govern generated code as part of the software supply chain, not as a novelty feature.
A question worth separating out:
Q: Should teams block AI-generated code that is secure but incomplete?
A: Yes, when incomplete output would silently fail a business requirement or create operational gaps. Security and correctness both matter. A secure endpoint that never executes its required function can be just as disruptive as an insecure one, because teams may discover the flaw only after deployment.
👉 Read our full editorial: Secure AI code generation still needs runtime scanning and guardrails