30.5 Supply chain risks (dependencies + generated code)

Goal: avoid shipping unreviewed risk

Vibe coding makes it easy to add dependencies and generate large amounts of code quickly.

That speed can hide supply chain risk:

• dependencies with vulnerabilities,
• dependencies with risky transitive dependencies,
• generated code that looks correct but contains subtle security flaws,
• copy-pasted snippets that bypass your security posture.

This page focuses on pragmatic defenses: reduce dependency footprint, review generated code, and keep the build pipeline safe.

Dependency risks (the classic supply chain problem)

Common dependency risk categories:

• Known vulnerabilities: published CVEs in direct or transitive dependencies.
• Typosquatting: installing a package with a similar name to a popular one.
• Abandoned packages: no maintenance, old vulnerabilities, broken security posture.
• Risky install scripts: postinstall scripts that run arbitrary commands.
• Over-broad permissions: dependencies that access the network/filesystem unnecessarily.

Practical mitigations:

• Prefer fewer deps: choose standard library and well-known packages.
• Pin versions: lockfiles and deterministic builds.
• Scan dependencies: vulnerability scanning in CI.
• Review transitive deps: especially for security-sensitive features.
• Audit install scripts: know what runs on developer machines and CI.

Generated code risks (unique to vibe coding)

Generated code is risky because:

• it can include insecure defaults (no auth, no rate limits, no validation),
• it may include outdated patterns,
• it may omit edge-case handling,
• it may “work” but violate your security requirements.

Common insecure defaults to watch for:

• Auth omitted: endpoints and admin actions without authentication/authorization.
• Input validation missing: injection risks (SQL, command injection, SSRF).
• Secrets in code: hardcoded API keys in config files.
• Unsafe file handling: path traversal, unrestricted uploads.
• Overly permissive CORS: exposing APIs to unintended origins.
• Debug logging: logging full requests/responses in production.

Process controls that reduce risk

Process controls that fit vibe coding (fast, repeatable):

• Diff-only changes: avoid huge unreviewable rewrites.
• Dependency gate: require explicit approval for adding new dependencies.
• Security checklist in PRs: auth, validation, logging, secrets.
• Static analysis and linters: baseline checks for common mistakes.
• Secret scanning: prevent committing secrets.
• Threat model review: for features that add tools or handle sensitive data.

Practical checklist

• Dependencies: minimize, pin versions, scan for vulnerabilities.
• Generated code: review for auth, validation, rate limits, logging.
• Build pipeline: avoid executing untrusted scripts; keep CI secrets safe.
• Secrets: never hardcode; scan commits; rotate when exposed.
• Testing: add security-relevant tests (permissions, input validation, refusal flows).

Where to go next

• Section 31: practical defenses
• Reference: fuzzing and adversarial inputs (27.4)