Claude Code, Cursor, and Copilot have made shipping code faster than reviewing it. When you ask for a fast solution, the model tends to give you exactly that: fast. Which often means the input validation, the CORS policy, the edge case for an empty array, gets quietly skipped in favor of something that just works for the happy path.
Your security team didn't get faster at the same rate your commit velocity did. That gap is where the actual risk lives.
Where the Risk Actually Enters
Prompt for fast code ──> AI generates functional boilerplate
│
▼
[Pre-commit: Gitleaks / Trufflehog] ──> catches leaked secrets locally
│
▼
[CI: Semgrep / Bandit / Snyk] ──> catches OWASP-class flaws
│
▼
Signed release
Three Layers, Each Catching Something the Others Miss
Local, before it even leaves your machine. A fast regex scanner like Gitleaks or Trufflehog wired into your git hooks stops a commit dead if it contains an OpenAI key, an AWS secret, or a database connection string with credentials baked in. AI assistants love generating "working examples" with a real-looking placeholder key. Catch it here, not three commits later.
In the pipeline, on every PR. Run automated rules against SQL injection patterns in raw ORM queries, XSS in frontend templating, and weak cryptographic primitives like MD5 or SHA1 showing up anywhere near a password. These are exactly the patterns a model reaches for when it's optimizing for "code that runs" over "code that's safe."
Package integrity, the one most teams haven't thought about yet. Verify that any newly introduced dependency in package.json or requirements.txt has actually existed in the public registry for a reasonable amount of time and has a verified publisher. This defends against slopsquatting: a model invents a plausible package name, an attacker registers it with embedded malware, and waits.
| Risk | What triggers it | The guardrail |
|---|---|---|
| Leaked API keys | "Here's a working example with a dummy key" | Pre-commit regex scan |
| SQL injection | Dynamic string interpolation in a query | AST-based pattern rule in CI |
| Dependency hallucination | A plausible but nonexistent package name | Registry age and publisher check |
This Doesn't Have to Slow You Down
The usual objection is that security scanning adds friction to a fast workflow. In practice, an AST-based scanner like Semgrep running incremental diff checks on changed files only takes a few seconds inside GitHub Actions, it's not the bottleneck people expect it to be. The actual cost of skipping this step shows up later, in an incident review, not in your CI minutes.
Frequently Asked Questions
What exactly is dependency slopsquatting?
When a model recommends a package name that doesn't actually exist, an attacker can register that exact name on npm or PyPI with malicious code inside it, then wait for developers who trust the model's suggestion to install it without checking.
Does adding this security layer meaningfully slow down PR review?
Not much. AST-based scanners run incremental checks on just the changed files, which typically finishes in well under a minute inside a CI pipeline, not the multi-minute delay people assume.
Should this replace a human security review entirely?
No. It catches the mechanical, pattern-matchable stuff fast and consistently, freeing up a human reviewer to focus on logic flaws and business-context issues that a static scanner can't reason about.
Comments
Comments are reviewed before appearing publicly.
No comments yet — be the first.