COMMENTARY: Code review, static application security testing (SAST), and software composition analysis (SCA) all answer the same question: Is the code we intend to ship any good?
For code that runs in a browser, that question covers only part of the risk. What executes can change after review, because a vendor gets breached, a third-party script changes at its source, or a package gets hijacked.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
Two recent cases show the pattern. On June 25, Polymarket said a third-party vendor had been compromised and a malicious script injected into its front end for some users. Blockchain analysts put the losses at roughly $3 million, and Polymarket said it would reimburse customers. Its servers were not affected.
A month later, on July 29, the FTC, the State of Utah, and Los Angeles County sued Hims & Hers Health. Among other claims, the complaint alleges that third-party tracking code on the company's website sent visitors' health information to advertising platforms. Hims & Hers disputes the allegations. Nothing has been proven.
In the first case, the code in the visitor's browser was not what the site owner had approved. In the second, the allegation concerns what third-party code did once it was running. Review of the code a team writes does not get designed to see either one.
AI widens the gap, but it’s an old gap
AI coding agents are increasing the volume and velocity of code moving toward production, while security review remains largely human-controlled. A National Bureau of Economic Research working paper found that autonomous coding agents lifted developer commits by 180%, while actual software releases rose by only 30%. The paper measures activity, not security. I read it as a reminder that more code written is not the same as more code shipped.
Quality remains a separate question. Veracode, a vendor in this market, tested more than 100 language models on 80 coding tasks in 2025. In 45% of test cases, the models produced code with a vulnerability from the OWASP Top 10. That’s vendor research on a curated set of coding problems rather than on real production systems, so I weigh it accordingly.
AI also changes the economics of attacks
AI isn't only changing how code gets produced. It's also altering the economics of attacks. The same technology that makes code cheaper to create also makes software cheaper to analyze. Today's attackers can accelerate code comprehension, reverse engineering, and deobfuscation.
One peer-reviewed benchmark gives a sense of where analysis tools stand. JsDeObsBench, from researchers at Ohio State, tested six language models against two open-source deobfuscation tools. The strongest model, GPT-4o, passed execution tests on about 93% of programs, ahead of the tools at about 84%, although the average model did worse than the tools. The programs were coding-challenge solutions run through one open-source obfuscator, so the results say nothing about commercial products. They do show that language models can already compete with conventional tools on that kind of code, and defenders should plan for any remaining gap to keep narrowing.
No client-side control makes code impossible to reverse engineer. The realistic goal: introduce enough friction, uncertainty, and cost that attacking an application becomes less attractive than finding an easier target. In an AI-assisted attack, that friction can mean more analysis, more experimentation, more model iterations, and more uncertainty about whether a discovered technique will actually work. It does not mean more than that.
Four practical steps
Here are four practical steps that can help security teams. Nothing at runtime completely fixes a vulnerability that review missed, so each step comes with its limits:
- Start upstream and automate the checks: Constrain what coding agents can do, and scan for secrets before code merges. Above all, keep secrets and authority on the server. If AI agents push code from generation to production faster than a security team can review it, don’t make protection a manual gate people add once review clears. It has to run automatically, at the same cadence as the pipeline itself.
- Apply control flow flattening to sensitive logic: Authentication flows, licensing checks, pricing logic, and fraud detection deserve structural protection regardless of whether a human or an agent wrote them, or whether they passed review cleanly or got pushed through under deadline pressure. Flattening these execution paths makes them harder to read and harder to alter. It does not remove a flaw inside them, and a determined attacker can still work through it.
- Embed runtime defenses: Code delivered to a browser operates in an environment the organization does not control. Complement build-time obfuscation via runtime protections. These include anti-debugging hooks that detect and respond to inspection attempts, anti-tampering checks that verify code integrity during execution, and self-healing mechanisms that restore or terminate protected functions when modification gets detected.
- Use controls that keep pace with the pipeline: Code Locks restrict execution by domain, approved browser environment, user, or time window. If protected code gets extracted, they raise the cost of running it somewhere else. If AI-generated code accidentally strips out environment constraints, such as enforcing execution within an approved domain or browser, applying the locks at build time restores those constraints in the shipped artifact. They remain client-side checks, so an attacker who controls the client can try to bypass them. This matters more as release velocity increases, because the faster code ships, the less time to catch a problem before it’s live.
Calls for a slowdown in AI innovation are mounting, but we don’t want to stop using AI. We must recognize that AI has changed the economics on both sides of the security equation. As AI makes code generation and attack analysis cheaper, defenders need to make exploitation harder and more expensive in return.
It’s impossible to achieve perfect protection. The real goal today: stop assuming a clean review means the code stays safe once it’s running in the browser. Teams need both.
Gareth Bowker, head of security research, Jscrambler
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
