Imagine a feature request for a comics server: a user pastes an image URL and the server downloads it and saves it as cover art. Nothing about that sentence reads as dangerous. Kavita, an open-source comic server, implemented exactly that; the code passed review, merged, shipped. Later the same code acquired a second name — CVE-2022-2756, a server-side request forgery (SSRF): the server fetched a URL on the user's behalf without ever checking where it pointed. The destination could be an image, or the server itself, or an address on an internal network that no outsider should reach.
Alibaba Cloud built an experiment around five requests like this one, and the results are worth reading closely — not because they prove something about AI-written code, but because they isolate why ordinary review misses the same class of bug whether a machine or a person wrote it.
Qoder Security is a code-security capability Alibaba launched in July and wired directly into Qoder Agent sessions; the scan runs with the command /security-scan. For the experiment, published on the Alibaba Cloud Community blog on 14 October, the team took five feature requests drawn from five real open-source projects, each corresponding to a publicly disclosed and already-fixed CVE. They turned the requests into prompts that described only the feature — no mention of security — and asked Qoder Agent to implement them in the historical versions of those projects where the flaws were originally introduced. Then they scanned.
The five scenarios mapped onto five different trust boundaries: data parsing (OpenSearch Ruby, CVE-2022-31115), network access (Kavita, SSRF), the file system (Qdrant, CVE-2024-2221), databases (Flight PHP), and system commands (discordrb, shell injection). Data parsing, network access, the file system, databases, and system commands: five of the most common security boundaries. Two were written up in detail.
The Qdrant case is the most instructive because the flaw lives in the path, not in any single line. Qdrant is a vector database that AI applications increasingly use. The request: add a snapshot-upload endpoint that saves an uploaded backup and then restores it — and, "entirely naturally," if the upload includes a filename, use that filename when saving. The agent implemented it in the project's existing style.
The scan traced the data flow the way a human reviewer struggles to: the filename enters through the upload request, is used to build a destination path, and travels through several functions and modules before reaching a file-write. With a ../ sequence in the filename, the write lands outside the snapshot directory — wherever the person crafting the name wants it to go. Inspect any one function alone and nothing is wrong: one accepts input, another builds a path, each does its job. The risk only becomes visible when the whole chain is connected. The report proposed normalizing and validating the filename and confirming the resolved path stays inside the snapshot directory; the agent applied the fix in the same session, the tests still passed, and a re-scan no longer flagged that path.
The discordrb scenario was faster to grasp. The framework drives FFmpeg for voice processing; the request was to let callers pass an options string with extra FFmpeg arguments for trimming and filters. One optional parameter, a few lines of code. The scan found that the string was interpolated into a command handed to the system shell — ordinary arguments were fine, but a semicolon or a pair of backticks could inject an entirely unrelated command. The only thing separating "support extra arguments" from "let the caller rewrite the shell command" was the caller's goodwill. The fix — pass arguments as individual list elements instead of assembling one string for the shell — is textbook, but only if you know to look.
The remaining three reinforce the pattern. OpenSearch Ruby's YAML support passed server responses into a parsing API permissive enough to instantiate objects, not just read data. Flight PHP wrapped database writes using parameter binding for every value — the standard defense — yet concatenated table and column names directly into the SQL, and identifiers cannot be parameterized; the values were protected, the identifiers were not. That one is the sharpest finding, because the "best practice" of prepared statements can itself create the blind spot.
The unifying point is not that agents write insecure code. Every one of the five vulnerabilities was originally written by people, passed review, and shipped. Each began with a reasonable requirement — support another format, save a user a step, cut some repetitive code. The failure is structural: security review is good at judging a change in isolation and poor at assembling the full data flow across modules, which is precisely where this class of bug lives.
There is a version of this that is easy to miss. The engineers who wrote those five vulnerabilities at least had colleagues reviewing their work. When it is one person and an agent, there is frequently no second reader at all — and AI-assisted coding multiplies the volume of code flowing past whatever review does exist.
What the agentic scanner changes is less about detection than about timing. Its argument is that when a report arrives only after commit and before release, the developer has already moved on; they must reconstruct context from days earlier while triaging a flood of alerts. Feedback delivered inside the coding session collapses discovery, understanding, remediation, and verification into one continuous loop. That is a legitimate thesis, and it is the one real product claim in the post.
It remains a vendor demonstration. The company states plainly in the footer that the scenarios are built on already-fixed, publicly disclosed issues and do not imply that Qoder reproduced or rediscovered the corresponding CVEs, that runs vary by product version and session state, and that the experiments should be done in an isolated environment. There is no independent reproduction of the diffs, no false-positive rate, and "the tests still passed" is necessary but not sufficient — a fix that keeps a test suite green can still leave the boundary open.
The interesting question is not whether one coding agent beats another at spotting bugs; it is what happens as the volume of machine-written code rises. When a change is one plausible feature among thousands and no one holds the whole picture in their head, the second pair of eyes — already scarce inside large teams and often nonexistent for solo builders — is the binding constraint. Moving a security gate inside the generation loop addresses that constraint directly. Whether the gate is any good is a separate, testable claim; the experiment is a hypothesis, not a proof. But the instinct — make the scanner see the whole chain, and make it speak before the developer moves on — is the right one to build on.