Security Review When Nobody Wrote the Code

Security review practices assume an author: someone who made choices, can explain them, and whose mistakes follow recognizable human patterns. Generated code breaks all three assumptions, and the review process needs adjusting in specific ways rather than just being applied harder.

What changes about the defects

They're consistent rather than idiosyncratic. A human makes a mistake in one place. A generated pattern applies the same flaw everywhere it's used — which is worse in blast radius and, counterintuitively, better in detectability once you know to look for repetition rather than for anomaly.

The code looks careful. Human-written vulnerabilities often carry a tell: hurried code, an obvious shortcut, an inconsistent style. Generated code has uniform quality, so scanning for the suspicious-looking part doesn't work.

Nobody can be asked why. "Why did you handle it this way?" is a core review question with no one to answer it. The reasoning either arrives with the change or doesn't exist.

Volume rises. More code, same reviewers — the same bottleneck as functional review, with higher stakes on what gets missed.

Where to look instead

Rather than scanning for wrong-looking code, check the categories where generated code has structural weak points:

Input trust boundaries. Generated code frequently handles the specified input shape well and treats input as trusted more readily than a security-conscious author would. Check every boundary where external data enters.

Authorization, as opposed to authentication. Whether the requester is permitted to do this to this resource, as distinct from whether they're logged in. This is the check most commonly absent, because the specification usually says what the endpoint does rather than who may call it.

Error paths. The least specified, least tested, and least examined part of any change — and where information disclosure and failure-open behavior live.

Anything constructing a query, path, command, or URL from input.

Secrets handling. Whether credentials appear in logs, errors, or responses.

Defaults. Generated code often produces permissive defaults, because the specification described the working case rather than the locked-down one.

✅ Practices that adapt

Require the change to state its security-relevant assumptions. What it assumes about inputs, who it assumes has already been authorized, what it assumes about the caller. ⚠️ Those assumptions are where vulnerabilities live and they're invisible in code — making them explicit is the single most useful change.

Automate ruthlessly. Static analysis, dependency scanning, secret detection, taint tracking. Every mechanical check is attention returned for the judgment questions. This mattered before; it's load-bearing at volume.

Review the pattern, not just the instance. If a generated approach appears in twelve places, review the approach once, carefully, then verify mechanically that the other eleven match. Reading all twelve badly is worse.

Enforce structurally, not by review. Parameterized queries by construction, output encoding in the framework, authorization checks in middleware. Anything a reviewer has to remember to check will eventually be missed at volume.

Test the security properties. An eval case whose expected result is a permission error. Injection attempts asserted on actions rather than words. These run every time and don't get tired.

💡 The asymmetry worth exploiting

Generated code's consistency, which is a liability for blast radius, is an asset for detection: if a pattern is wrong, it's wrong the same way everywhere, so finding one instance finds all of them, and fixing the generation source fixes the class.

That's a better position than human-written vulnerabilities, which are scattered and individual. It rewards a specific practice — when you find a security issue in generated code, immediately search for the pattern rather than fixing the instance.

The takeaway

Generated code fails security review's assumptions: mistakes are systematic rather than idiosyncratic, the code looks careful, and nobody can explain the choices. Look at trust boundaries, authorization, error paths, and defaults rather than scanning for suspicious style. Require security assumptions to be stated, enforce structurally rather than by reviewer memory, and when you find one instance of a flawed pattern, search for the rest — because there will be a rest, and that's the one advantage this situation gives you.