AI writes the Dockerfile, and the pipeline is still checking the app code

Multiply the study out and the sample count explains itself. Seven hundred and thirty prompts against 27 models is 19,710 runs, near enough the roughly 20,000 samples IOActive reports ^[1][16]. That is about one shot per prompt per model, with no reroll until something passes review, which is a reasonable model of what actually lands in a commit. Nearly a third of that pool was fully exploitable, so the exploitable set alone runs to something like six thousand samples ^[3][17].

The best configuration tested still produced 90 distinct vulnerabilities across the sample set ^[4]. Against 730 prompts, that is roughly one distinct vulnerability for every eight things you ask for ^[20].

The mechanism behind the infrastructure split is duller than the numbers suggest. A Dockerfile that runs as root or pins nothing is not syntactically wrong, so nothing in a build fails, and there is no red mark for a reviewer to follow. IOActive puts the cause in the training data, which it says skews toward application-code examples and leaves IaC as a genuine blind spot ^[7]. The gates devops.com recommends for AI-authored infrastructure, misconfiguration scans, container checks, policy-as-code and secret scanning ^[13], are a separate toolchain from the application SAST most pipelines already run, and they have to be wired in deliberately.

Meanwhile the forty-point spread between how often generated code runs and how often it is safe ^[18] describes the loss of a free signal. Broken code announces itself. Working code that ships a hardcoded credential does not, and Veracode's number has not budged in two years ^[9].

The usual language hedge does not travel either. Rust and Go did somewhat better than Python or JavaScript on general code, and IOActive found that advantage mostly evaporated once cryptography and infrastructure logic were in scope ^[8].

Which leaves provenance, and this is where the Georgia Tech work is more instructive as a warning than as a tracker. Vibe Security Radar pulls fix commits from CVE.org, NVD, the GitHub Advisory Database and OSV, traces each back through Git history to the commit that introduced the bug, then looks at that commit for an AI tool's fingerprint: a co-author tag, a bot email address, a known tool signature ^[12]. The trace only completes where the fingerprint survived. Any organisation doing its own post-incident review is working under the same constraint, on its own repositories, with the same dependence on metadata nobody was thinking about at merge time.

Tagging AI-drafted changes and routing them for closer review ^[14] is usually pitched as governance. The stronger case is narrower: it is the difference between answering "which of these came out of an assistant" in an afternoon and treating it as a research problem. The two labs used different methods and different scoring, and landed within about four points of each other ^[19]. That agreement is the part worth acting on, because it means the number is a property of the tooling, not of one lab's harness.