Uncategorized

The AI code vulnerabilities that grow with your app

Theori built 28 apps with AI coding agents and scanned each one through its pentesting platform. Five models did the building, split between Anthropic and OpenAI, across apps written from a spec, thrown together from a casual prompt, and rewritten from an aging PHP codebase.

AI code vulnerabilities

The team went in expecting injection everywhere. SQL injection, cross-site scripting, the bugs that fill security tutorials. Those barely showed up. The models reached for prepared statements and ORMs on their own and sanitized their inputs.

Andrew Wesie, CTO at Theori, traces this to what the easy bugs have in common. “Frontier models understand well-documented vulnerability classes better, but those vulnerability classes also are simpler and require less context to identify and fix,” he told Help Net Security. A single line of code shows the flaw, and a single line of code fixes it.

The bug in almost every app

Resource exhaustion and denial-of-service problems were the most common flaw at 21% of findings. Unbounded pagination. No rate limits. Synchronous work that blocks the whole process. These showed up in nearly every project.

The impact lands in operation. A server runs up a large bill, or an attacker knocks it over.

Wesie puts these in the category models still miss. “The vulnerability classes that models still struggle with are those that require system-level understanding,” he said. “Resource exhaustion types of vulnerabilities require understanding the limits of the system: how many requests per second is it expected to handle.” The model has to know how many requests the service should take and how big an uploaded file can get, and often that number lives nowhere in the code.

The bugs that grow with the app

Secrets exposure produced close to half of the critical findings. Hardcoded keys, default SECRET_KEY values, JWT secrets that let an attacker forge a session. These sit in quick-start templates that fill the training data and survive any “does it work” check.

Access-control bugs told a story about size. IDOR, where a user reaches data beyond their permissions, made up 11% of findings in the small builds.

The rewritten CMS hit 28%. The same-user ownership check is local and easy. The rule that spans hundreds of endpoints in a large app leaves a few gaps every time.

From 8,827 down to 434

The raw scans returned 8,827 detections. Theori collapsed the duplicates, then built proof-of-concept exploits to confirm the survivors.

What remained were 434 the team could stand behind.

Who reviews the code now

Human review was a bottleneck before AI coding caught on. The volume of generated code widened the gap. Wesie sees one path through it. “There is no option except to use automated review tools, at least for the line-by-line review and checking for security vulnerabilities,” he said.

He keeps people in the seats that call for judgment. “Humans should still drive the review that matters: threat models, high level architecture, and product decisions, and during security reviews automation supplements human experts, it does not replace them,” he said.

The automation has to clear a bar of its own. Low false positives. Patches that fix the root cause and hold up without breaking something else. Wesie put the test plainly. “Teams need to be tracking if these tools are solving real problems, or just burning tokens without value,” he said.

Report: How to implement a continuous offensive security testing program

Source link

Visited 1 times, 1 visit(s) today

Leave a Reply

Your email address will not be published. Required fields are marked *