Spotting code slop before it becomes a security incident

Cover image for Spotting code slop before it becomes a security incident

AI coding assistants have never been faster at shipping code that compiles, passes tests, and looks clean in review. The problem is what hides underneath: hallucinated dependencies attackers can pre-register, missing input validation, silently mocked tests, and auth checks that simply aren't there. Peer review and shift-left scanners were built for human mistakes, not model output, and the gap between them is where slop turns into an incident.

That gap is already showing up on the balance sheet. Reviewers face more code per week with the same headcount, scanners miss the novel failure modes models produce, and merged slop compounds into duplicated vulnerabilities, leaked secrets, and access-control breaches that surface weeks later as full-blown supply-chain compromises. The teams feeling this most acutely aren't the ones with the least tooling; they're the ones whose findings have nowhere governed to go.

The fix is to stop treating this as a code-quality problem and start treating it as a workflow problem: pre-merge gates that catch what SAST and SCA can't, paired with governed routes from every finding to a named human owner. That is the shift this article walks through, with AppSec workflows as the lead example.

What code slop looks like and why it passes review

Code slop is AI-generated code that is syntactically plausible but functionally unreliable, insecure, or unmaintainable. Left unchecked, it turns a codebase into a tragedy of the commons: each diff looks reasonable on its own, but the accumulated shortcuts and near-duplicates make the whole harder to review, maintain, and trust.

One defining characteristic of code slop appears in dependency recommendations. A study of 576,000 AI-generated code samples across 16 models found 19.7% of recommended package dependencies were fictitious. Worse, 43% of those hallucinated names repeated consistently across re-runs of the same prompt, making them predictable enough for attackers to pre-register on npm or PyPI. AI-generated code also frequently omits input validation unless prompts explicitly require it.

That omission produces recurring input-validation failures (CWE-20), including SQL injection (CWE-89) and OS command injection (CWE-78). Test subversion is another known failure mode: an agent rewrites tests to pass broken code instead of fixing it, sometimes hallucinating an external service and mocking it out so its fabricated tests pass.

Hallucinated dependencies, missing validation, test subversion, and duplicated insecure logic survive review because the defects look correct. Independent assessments consistently report higher issue rates in AI-written code than human-written code, with cross-site scripting appearing disproportionately, yet the diffs still read cleanly. Even mature pipelines miss regressions that clear human review, automated review, unit tests, end-to-end tests, verification, and dogfooding.

Several structural forces let these defects outpace reviewers:

  • No architectural memory: AI assistants carry no memory of architectural decisions from last week, let alone last quarter, so they recreate existing components and bypass established abstractions. Teams that rely heavily on AI-generated changes often see more copy/paste code and less refactoring over time, which means duplicated logic spreads faster than reviewers can rationalize it.

  • Insecure training patterns: LLMs reproduce patterns from their training code, including insecure patterns. AI reviewing AI compounds the blind spot because the generator and reviewer share training distributions.

  • Volume that outstrips capacity: Heavy AI use increases pull request volume and review load, while large PRs reduce reviewers' ability to detect defects, and extra-large PRs often consume hours while producing few meaningful comments.

Every piece of code slop that slips through AI-driven volume and overloaded review adds to a compounding balance.

The security debt code slop leaves behind

Merged code slop doesn't sit still; it compounds into security debt with measurable interest. GitClear's large-scale maintainability analyses of AI-accelerated codebases show the same pattern: duplicated code rises, error-masking constructs become more common, refactoring declines, and new lines become less connected to existing code.

Duplicated vulnerabilities force teams to patch every sibling copy they can find, while swallowed exceptions hide exploitable failure modes from logs; when code is disconnected, teams may have no natural owner who understands it.

Secrets debt grows on the same curve. Public repositories continue to receive large volumes of hard-coded secrets, and credentials that leak often remain valid long after exposure. AI-assisted commits add another path for credentials to move from local development into shared repositories.

Security leadership is already paying the price. Leaders increasingly report confirmed or suspected vulnerabilities introduced by AI-generated code, and AI-accelerated development has made it harder for security to keep up. Workloads keep climbing while too much of the day still goes to manual, repetitive triage. Shift-left investment from the last decade has not absorbed this debt.

Shift-left rests on two assumptions that code slop breaks: the developer wrote the code, and the scanner knows the pattern. Neither holds. SAST misses risky logic that doesn't match a known signature, SCA can't flag a dependency that doesn't exist, and the human feedback loop dies once the developer has moved on, leaving findings to pile up faster than teams can triage.

Six pre-merge gates that stop code slop before it ships

Security teams can automate most of the pre-merge gates that catch code slop. Six carry the most weight for security teams:

  • Registry verification for every new dependency: CI checks every new import or require in the diff against PyPI, npm, or Maven to confirm the package exists and exports the function being called. Trivy, Snyk, or a registry lookup script closes the slopsquatting hole SCA leaves open.

  • Secret scanning with full history: Gitleaks (gitleaks/gitleaks-action@v2) or TruffleHog run with fetch-depth: 0. The pipeline fails on any detected key, token, or password.

  • SAST with OWASP-mapped rules: Semgrep with the p/owasp-top-ten config plus CodeQL run on every PR. Critical findings block merge.

  • A coverage gate that rejects tautologies: Require security coverage and meaningful test coverage before merge. Tests asserting tautologies are a named AI failure mode, so error paths count alongside the happy path.

  • AI authorship provenance: Use Git trailers or PR-template disclosure fields to preserve accountability and auditing. Pair that disclosure with automatic routing of high-risk work to senior and security reviewers.

  • IaC misconfiguration scanning: Checkov or KICS run on every PR that touches infrastructure files. Critical misconfigurations fail the merge. Incidents involving missing Row Level Security policies are what this gate prevents.

Every gate above generates findings, and findings without owners age into incidents. Most programs break at the handoff from scanner finding to accountable owner.

From curating code to governing it: closing the ownership gap

The gates only work if a named human acts when they fire, and most organizations haven't decided who should own that action. The NIST AI RMF says organizations should document clear roles, responsibilities, and lines of communication for managing AI risks throughout the organization. Ownership only works when the named owner has visibility, authority, budget, and consequence.

An owner missing any one of them is a fall guy. Findings route into abandoned groups after reorganizations, and tickets sit there aging. Fragmented ownership is a recurring barrier to scaling AI safely, because no one is clearly on the hook when a scanner alert lands.

Teams closing this gap move findings out of static queues and into governed workflows, where every alert has a defined trigger, a named actor, and an audit trail. A workable pattern for a secret-finding path looks like this:

  1. A webhook from the secret scanner fires on a new finding.

  2. An enrichment step extracts the committer, repository, and secret type.

  3. A validity check confirms whether the credential is still active against the issuing provider.

  4. A message routes to the repo owner with a one-click revoke-and-rotate approval.

  5. On approval, the workflow revokes the key via the provider's API and logs the full trail in a ticketing or case-management system.

Severity classification can sit inside the same workflow, ideally within guardrails and behind a human-in-the-loop approval so a person stays on the revoke-and-rotate decision. 

The point is that deterministic steps (webhook, enrichment, API revocation) and judgment steps (severity, approval) share one audit trail, and the same named-owner model scales past secrets to any finding queue.

Making code slop detection an operational discipline

Security pass rates argue against waiting for the models to fix this on their own. Generation quality keeps improving on axes security teams do not fully control, which means the controllable variables sit between generation and merge, and between finding and fix. The teams closing the gap aren't the ones with the most scanners; they're the ones whose findings have somewhere to go.

That's the environment Tines 3B gives teams. Whether the code was written in Claude Code, Codex, or the Tines 3B builder, findings from registry checks, secret scans, and SAST route through the same governed workflow: enrichment, validity checks, and human approval share one audit trail, so a revoke-and-rotate decision and the record of who approved it are never two separate things to reconcile later. 

Deterministic steps and judgment calls run on the same surface, with a named owner attached to every finding instead of a queue no one's accountable for.

AI-generated code volume will keep rising; review and response capacity has to rise with it. Start running and governing that work with Tines 3B.

Frequently asked questions

How much less secure is AI-generated code than human-written code?

By most measures, meaningfully less. NYU Tandon found roughly 40% of 1,692 Copilot-generated programs contained exploitable flaws, and CodeRabbit's report has also found higher issue rates in AI-authored code. One caveat: a systematic literature review at PMC notes it remains unclear whether AI introduces categorically new vulnerability types compared to humans, and the gap varies by language and study.

What is slopsquatting, and how serious is it?

Slopsquatting is a supply-chain attack in which adversaries register fictitious package names LLMs hallucinate on registries like npm and PyPI, then load those packages with malicious payloads. Python Software Foundation Developer-in-Residence Seth Larson coined the term in April 2025. Because hallucinated names repeat predictably across prompts, attackers can profile a model's consistent hallucinations and pre-register them cheaply.

How do the EU AI Act and NIS2 shape controls for AI-generated code?

Both regulations push toward documented human oversight and auditable controls over AI-assisted software work. The EU AI Act treats certain code-generation use cases as high-risk when they feed regulated systems, and NIS2 raises the bar on software supply-chain security for essential and important entities. For teams shipping AI-generated code into either scope, that translates into concrete requirements around provenance labeling, secret and dependency scanning in CI, and named human approval before high-risk changes merge, which the pre-merge gates and governed workflows described above are designed to satisfy.

What extra review controls do AI-generated pull requests need?

Stricter ones than human PRs. Teams should treat AI-generated code the way they'd treat code copied from an external repository or pasted from a forum: useful, but untrusted until reviewed. In practice that means provenance labeling via Git trailers or PR-template disclosure, automatic routing of high-risk changes (auth flows, cryptographic primitives, credential handling, and authorization logic) to senior and security reviewers, plus explicit checks for authorization logic, which AI-generated code often lacks.

Sign up today to get started or schedule time with our team to learn more.