Summary: Wiki pages for raw/Secure-coding-patterns/ — securing code that AI writes. The one collection where the AI system is the author rather than the target.
Sources: raw/Secure-coding-patterns/ (4 files, ~13,800 words)
Last updated: 2026-07-29
Pages
| Page | Covers |
|---|---|
| ai-generated-code-risk | Why AI code fails differently — CSA’s four risks, and which statistics to trust |
| slopsquatting | Hallucinated dependencies as a supply-chain attack |
| securing-the-ai-sdlc | IDE-to-CI controls, reachability, governance, secure prompting |
| secure-coding-fundamentals | The baseline practices and the OWASP/CERT/NIST standards behind them |
Why this collection is different
Every other collection treats the AI system as the target. Here it is the author, and the target is ordinary software. That makes it the vault’s only bridge to conventional application security.
OWASP LLM05 Improper Output Handling is the hinge between the two views: model output flowing untrusted into a downstream system — whether that system is a web page or your git repository.
Four findings
- The failures are omissions, not novel vulnerability classes. Missing validation, absent authorization checks, skipped output encoding. CSA: “many vulnerabilities aren’t the result of writing ‘bad code.’ They come from missing protections.” That is why the pre-AI fundamentals still carry most of the load.
- Slopsquatting turns a model quality problem into a supply-chain attack. Hallucinated packages appeared in 5.2% of commercial-model and 21.7% of open-source-model outputs across 576,000 samples, producing >205,000 unique fake package names (USENIX Security 2025). It works because hallucinations are repeatable — attackers register the name the model keeps suggesting.
- Syntactically correct code defeats linters. Every flaw class here compiles cleanly. CSA’s sharpest example is
if user.role == "admin"replacingif "admin" in user.roles— an authorization bypass that looks like a tidy refactor. - Architectural drift is the unscannable one. “Security controls applied in one path but not another,” accumulated commit by commit with no one holding the whole design. Every individual commit passes review.
Statistics — read the provenance
| Claim | Trust |
|---|---|
| 62% of AI-generated solutions contain design flaws or known vulnerabilities (arXiv 2502.11844) | Academic, cited second-hand |
| 5.2% / 21.7% hallucinated-package rates (USENIX Sec ‘25) | Academic, best-evidenced here — but OpenSSF cites the same study as 19.7%; name the population |
| 2.7× vulnerability density vs human code | Vendor claim, uncited |
| 97% of orgs using AI coding assistants | Vendor survey |
Three of the four sources are vendor marketing with embedded product CTAs; one includes a “best solutions” ranking featuring itself first. CSA is the only vendor-independent source. Capability taxonomies are consistent across all four and are reliable; the vendor-generated numbers are not.
The coding assistant, bracketed
Two attacks in the vault target the same tool from opposite ends:
- slopsquatting poisons what the assistant recommends — a package that doesn’t exist until an attacker registers it.
- PITAX T46 Rules-File Backdoor poisons what the assistant is told — hidden instructions in
CLAUDE.md,.cursor/rules,copilot-instructionsor a dependency, “steering AI coding agents to emit backdoored or vulnerable code.”
Both end with attacker-controlled code in your repository. Neither requires touching your infrastructure.
Cross-collection links
- OWASP Top 10 for LLMs — LLM03 supply chain, LLM04 poisoning, LLM05 output handling
- Agentic and tool attacks — T42 and T46 target coding agents directly
- Model Theft — source code sent to external assistants is a confidentiality exposure
- AI Act Art 15 — none of this is among its five named attack classes
- Root index
Gaps
- NIST SSDF (SP 800-218) is referenced but absent from
raw/. It is the framework an auditor is most likely to cite, and it would sit naturally beside the NIST AI RMF. - The general OWASP Top 10 Secure Coding Practices and CERT Coding Standards are likewise referenced but not present.
- Secure patterns for building LLM applications — prompt construction, output sanitisation, tool-call validation — are now covered in Securing LLM applications. What remains uncovered is secure design: threat modelling a RAG pipeline, or structuring a multi-agent trust boundary.
- Vendor-independent evidence now exists: the Stanford CCS ‘23 study in Do users write more insecure code? found developers with AI assistants wrote less secure code while being more confident it was secure.
Log
See log.