Is 45% of AI-generated code really insecure?
Roughly, yes. Public reporting in 2025 - including Veracode's GenAI Code Security Report - found that around 45% of AI-generated code samples introduced at least one OWASP Top 10 weakness on security-sensitive tasks. Treat that as a base rate, not a verdict on any single snippet; the real rate depends on prompt, language, and whether anyone reviews the output.
- ▸The failure rate varies by task and language. In the same public reporting, Java and legacy PHP patterns tended to fail more often than the equivalent task in TypeScript.
- ▸Models rarely invent exotic bugs. They reproduce the most common insecure patterns from their training data: string-concatenated SQL, missing authorization checks, weak crypto defaults, and permissive configuration.
- ▸Vibe-coded repositories amplify the problem because nobody reads the diff. The generation is trusted, merged, and shipped, so the vulnerability rate of the code becomes the vulnerability rate of the product.
- ▸The arithmetic is unforgiving. If half of generated snippets carry a weakness and a team merges a few hundred AI-authored changes a month, defects compound fast. We traced the downstream cost in The Technical Debt Time Bomb of AI-Written Code.
Which OWASP Top 10 flaws show up most in AI code?
The recurring offenders are A01 Broken Access Control, A03 Injection, A02 Cryptographic Failures, and A05 Security Misconfiguration. AI models optimize for the happy path, so they omit authorization checks, concatenate untrusted input into queries, choose outdated hashing, and leave debug and CORS settings wide open.
- ▸A01 Broken Access Control (CWE-284, CWE-639): generated endpoints often trust a user-supplied record ID with no ownership check - the classic insecure direct object reference (IDOR).
- ▸A03 Injection (CWE-89, CWE-79): string-built SQL and unescaped template output are the model's reflex when you ask for a query without specifying parameterization.
- ▸A02 Cryptographic Failures (CWE-327, CWE-916, CWE-798): MD5 or SHA-1 for passwords, ECB mode, disabled TLS verification, and hardcoded keys.
- ▸A05 Security Misconfiguration: wildcard CORS, verbose stack traces in production, and default credentials left in place.
- ▸A06 Vulnerable and Outdated Components: the model pins a version it remembers, which is frequently one with a published CVE. More on the mechanism in Why AI Coding Assistants Introduce Security Vulnerabilities.
How do I audit a vibe-coded repo I inherited?
Run a layered scan before you read a single line. Combine SAST, secret scanning, and software composition analysis (SCA) into one baseline pass, then triage by exploitability and reachability rather than by raw finding count. The goal is a ranked, CWE-mapped backlog, not a 4,000-line report nobody opens.
- ▸Inventory first. Generate a software bill of materials with Syft, then scan it with Grype, Trivy, or OSV-Scanner against the OSV database and the GitHub Advisory Database.
- ▸Static analysis. Run Semgrep with the OWASP and language rulesets; add CodeQL if you use GitHub Advanced Security. Use Bandit for Python and gosec for Go.
- ▸Secrets. Run gitleaks or TruffleHog over the full git history, not just HEAD - vibe-coded repos routinely commit live keys and rotate nothing.
- ▸Rank by reachability. A critical CVE in an unused transitive dependency matters less than a reachable A01 flaw on an authenticated route. Prefer tools that offer reachability analysis to cut false-positive noise.
- ▸Add container and IaC scanning. Vibe-coded stacks usually ship a generated Dockerfile and Terraform too; scan images with Trivy and infrastructure-as-code with Checkov or tfsec, because a misconfigured bucket or a root container undoes clean application code.
- ▸Set a triage SLA, not a wish. Fix reachable criticals within days, highs within a sprint, and everything else on a scheduled backlog. An unranked report ages into shelfware.
- ▸Map every finding to a CWE and an OWASP category so the remediation backlog is auditable and defensible in a client security review.
What is the fastest way to remediate the findings?
Fix by class, not by line. Group findings into a handful of vulnerability classes - injection, access control, crypto, secrets, dependencies - and apply one systemic fix per class instead of patching individual snippets. Systemic fixes are faster to implement, easier to test, and far harder to regress.
- ▸Injection: replace concatenation with parameterized queries and prepared statements; standardize on one ORM or query builder across the codebase.
- ▸Access control: centralize authorization in middleware or a policy layer, deny by default, and never trust a client-supplied object ID.
- ▸Cryptography: move password hashing to Argon2id or bcrypt, symmetric encryption to AES-GCM, and key storage to a managed KMS.
- ▸Secrets: rotate every exposed credential - deletion from HEAD is not remediation - then move secrets into a vault.
- ▸Dependencies: upgrade to patched releases; where an upgrade is blocked, document the accepted risk with an expiry date.
Write a failing test that reproduces the flaw first, then apply the class fix, then watch the test go green. That order turns each remediation into a permanent guardrail rather than a change you hope nobody undoes.
How do I add security guardrails in CI?
Put the same scanners on the merge path and fail the build on net-new, high-severity, reachable findings only. The enforceable rule is no new criticals: the pipeline blocks introductions rather than the entire legacy backlog, so the gate ships on day one instead of after a six-week cleanup.
- ▸Pre-commit: gitleaks plus a fast Semgrep ruleset catch obvious issues before they reach a pull request.
- ▸PR pipeline: SAST (Semgrep or CodeQL), SCA (Snyk, Trivy, or OSV-Scanner), and secret scanning as required status checks.
- ▸Diff-aware gating: fail only on newly introduced criticals to avoid blocking the whole team on inherited debt.
- ▸Provenance: sign artifacts with Sigstore cosign and target SLSA build levels so what you scanned is what you ship - the approach in Provenance You Can Prove: SLSA, Sigstore, and Policy-as-Code CI/CD.
How do I stop hallucinated and poisoned dependencies?
Pin, verify, and allowlist. AI assistants routinely invent package names that attackers then register - a pattern nicknamed slopsquatting - and typosquats slip in when no one checks the import. Lockfiles with integrity hashes, an internal registry proxy, and install-time scanning close most of the gap.
- ▸Enforce lockfiles with hashes: package-lock.json, poetry.lock, go.sum.
- ▸Verify every AI-suggested import against the real registry before adding it; if the package did not exist last week, treat it as hostile.
- ▸Proxy installs through an internal registry or Artifactory with an allowlist and quarantine for newly published packages.
- ▸Scan on install and block low-reputation or freshly created packages. We go deeper in Supply-Chain Attacks 2.0: Hallucinated Packages and Poisoned Models.
How do I prove the repo is actually fixed?
Evidence, not vibes. Re-run the full baseline scan, show the delta, and keep the reports as build artifacts. Tie each remediated class to a passing regression test and a CI gate so the fix cannot silently disappear on the next AI-generated pull request.
- ▸Store scan output in SARIF format as build artifacts and track the trend release over release.
- ▸Add a regression test for each fixed vulnerability class so a reintroduced flaw fails the build.
- ▸Confirm secrets were rotated, and verify the old credentials no longer authenticate.
- ▸Fold the guardrails into your paved road so secure defaults are the easy path - see Golden Paths as a Security Control: Internal Developer Platforms Done Right.
How TuniCyberLabs helps
We audit and remediate AI-generated codebases end to end: layered baseline scanning, class-based remediation, diff-aware CI guardrails, dependency allowlisting, and build provenance - all mapped to OWASP and CWE so the result survives a client audit. Talk to our engineers about a security review of your vibe-coded repository.