⭐ Star on GitHub

Append-only. Newest entries at the bottom.


2026-07-29 — Initial ingest

Sources ingested: raw/Secure-coding-patterns/ — 4 files, ~13,800 words, added by the user. All read in full.

SourceWordsPublisher
Best AI Code Security Solutions 20264,546Orca Security (vendor)
AI Code Security: Complete Guide4,391Cycode (vendor)
Secure Coding Practices: 7 Best Practices, OWASP Guidance, and AI-Era Tips4,032Checkmarx (vendor)
Understanding Security Risks in AI-Generated Code851Cloud Security Alliance

Scope note: the folder name suggested generic secure-coding guidance. The actual sources are about securing code that AI writes — a narrower and more useful topic, and the only material in the vault where the AI system is the author rather than the target. Pages are scoped accordingly.

Pages created (6): index.md, log.md, ai-generated-code-risk.md, slopsquatting.md, securing-the-ai-sdlc.md, secure-coding-fundamentals.md

Findings recorded:

  • Slopsquatting — the strongest material in the collection. USENIX Security 2025 (Spracklen et al.), 576,000 samples: hallucinated packages in 5.2% of commercial-model and 21.7% of open-source-model outputs, >205,000 unique fake names. Works because hallucinations are repeatable, which is what makes a fictional name registerable.
  • Failure modes are omissions (missing validation, absent authz, skipped encoding) rather than novel vulnerability classes — which is why the pre-AI fundamentals still carry the load.
  • All flaw classes are syntactically correct, so linters miss them. CSA’s if user.role == "admin" vs if "admin" in user.roles example is an authorization bypass disguised as a refactor.
  • Architectural drift — controls applied in one path but not another — is unscannable because every individual commit passes. Structurally the same problem as multi-turn attacks: wrong unit of analysis.
  • Orca’s “two meanings” framing (securing AI-generated code vs using AI to secure code) is the same terminological collision already recorded for AI incident response. Cross-linked both ways.
  • CSA’s proposal to feed security context to assistants via an MCP server is the most forward-leaning control here — and is itself the surface PITAX T42 tool-definition injection targets. Noted as a two-edged recommendation.
  • Slopsquatting and PITAX T46 bracket the coding assistant — one poisons what it recommends, the other what it is told.

Provenance handling: three of four sources are vendor marketing with embedded product CTAs; Orca’s includes a “best solutions” ranking featuring itself first. Statistics are tabulated on ai-generated-code-risk.md and index.md with provenance marked — the two academic figures (62%, and the slopsquatting rates) are treated as load-bearing; Cycode’s uncited “2.7× vulnerability density” and its own-survey “97% adoption” are marked as vendor claims.

Root index updated: yes — Secure-coding-patterns removed from the empty-folders list.

Open items:

  • NIST SSDF (SP 800-218) referenced but absent; highest-value follow-up, and a natural companion to the NIST AI RMF already ingested.
  • General OWASP Top 10 Secure Coding Practices and CERT Coding Standards likewise referenced, not present.
  • No source covers secure patterns for building LLM applications — prompt construction, output sanitisation, tool-call validation. This collection is about code AI writes, not code that calls models. Uncovered vault-wide.
  • raw/Supply-chain-attacks/ still empty; slopsquatting and OWASP LLM03 are the current stand-ins.