AI 安全需要第二意见

中文版正在随流水线自动整理，稍后刷新即可；可先阅读下方英文原文。

本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Thought Leaders

AI Security Needs a Second Opinion

Add Unite.AI to your preferred sources on Google

AI is writing software faster than we can secure it. Are you keeping up?

By the time you finish reading this sentence, developers and their AI agents will have pushed a couple thousand code commits. Last year at this time, it would have been about 150.

The past year has seen AI-generated software accelerate to astonishing levels. GitHub recorded 7.38 billion commits in September 2026 alone, more than five times the total from a year earlier. The security implications of this explosion are profound. Every one of those commits is code someone is supposed to understand, maintain, and secure. Cloud Security Alliance found that AI-assisted developers at Fortune 50 companies commit code at three to four times the rate of their peers, while their monthly security findings rose roughly tenfold.

Now consider who inherits that increase. The CISO’s team is the same size it was a year ago, but the backlog is not. Vulnerability submissions are rising, monthly fixes are falling, and unresolved criticals are expanding. It’s no wonder that Gartner says CISO burnout is becoming a critical operational risk.

The Temptation of the Latest Model

When the number is that big, the instinct is to chase a bigger number: more findings, more coverage, more scans. But that’s like bailing a sinking boat and asking for a bigger bucket when what you need is to find the leak. A security program isn’t measured by how much it finds. It’s measured by how much of what it finds is real, and how many of the most critical findings actually get fixed.

Frontier AI models are remarkable at finding novel exploits and uncatalogued flaws with probabilistic reasoning. But results vary. Run the same scan on the same code five times and the findings match only about a third of the time, according to Checkmarx research.

That inconsistency is why rules-based analysis still matters. It’s less flexible than frontier AI, but it applies proven logic the same way every time, so teams can trust and verify the results. AI catches what rules miss, like familiar weaknesses in unfamiliar forms, or flaws that only become exploitable when separate parts of the code interact. Together, AI and rules-based analysis surface more of what matters, with fewer false alarms.

None of this is an argument against AI. It’s an argument that security needs a second opinion. Whatever engine you choose, hold it to three questions.

Question One: Fidelity

When the scanner says something is wrong, is it worth your time?

Fidelity is trust. A finding that isn’t real costs a developer an afternoon and costs security a little more credibility. At scale, false positives are what make teams stop listening. The alerts are just “crying wolf” and fade into background static.

This is where consistency matters. Deterministic analysis returns the same answer every time on the same code, which builds trust and makes results auditable.

Question Two: Accuracy

Are you finding the complete set of issues that matter most?

Fidelity tells you whether a finding is worth your time, but it doesn’t tell you what the scanner missed. We use a working measurement with origins in data science called an F1 score. F1 rates performance on a scale of 1-0, based on two factors:

- Precision: the share of reported findings that are real. High precision means fewer false alarms.

- Recall: the share of real vulnerabilities the scanner actually finds. High recall means little slips through.

A scanner can look precise by flagging almost nothing, or thorough by flagging everything, with low F1 scores for both. The industry average is about 0.20. We have been working hard on this challenge and have seen results that are three to four times the accuracy of a standard scanner.

Better accuracy makes everything downstream get easier for developers. Your team spends less time validating and more time fixing.

Question Three: ROI

How do we maximize investment and resources?

This question is the one most often skipped in the pilot and most painfully answered in production.

Frontier models bill by the token, and tokens are spent whether or not a scan finds anything. Scanning a one-million-line repository costs more than a thousand dollars at current published prices. And the gap between models’ token use is wide; price varies depending on the model you choose and how much it has to reason to finish your job.

Multiply that across every commit, pull request and repository in an enterprise. Uber, which spends $3.4 billion a year on R&D, reportedly exhausted its entire 2026 AI budget within months of rolling out AI coding tools.

We call this the token tax. It’s like taking a Ferrari to pick up groceries: you’re paying for power the trip doesn’t need. Hardcoded credentials and SQL injection are predictable patterns that deterministic analysis covers reliably.

AppSec Has to Evolve

This is the reasoning behind the architecture of Checkmarx Fusion. Rules-based engines establish ground truth, reproducibly and at less cost of token-based analysis. Frontier models are directed at what rules can’t anticipate: novel patterns, complex logic, exploitability in context. Then a findings analysis layer fuses the results into one trusted set.

Deterministic provides certainty. AI provides reach. Coverage and trust rise together. Against an LLM working alone, we see up to four times the fidelity, two to four times the accuracy, and roughly a third of the cost.

Finding problems is only the start. The same logic applies to prevention. Let’s take an example. By empowering developers at the point of creation, in the IDE where they write the code, we can stop problems before they start. Similarly, when it comes to the vulnerabilities that do get through, why not provide developers with merge-ready fixes for the ones that matter most? These are the challenges we are solving for, with the goal to chip away at the existing backlog, for the quickest impact with the least effort.

The Code Is Running. Can You Keep Up?

AI gave attackers the gift of speed. The way to close that gap isn’t one more tool. It’s a decision about how your whole organization builds and secures software. The code being written today will run your business for years. The question for security leaders is no longer how much faster AI helps you build. It’s whether your programs can keep pace with what it creates.

So don’t get lost in the numbers. Ask three questions of any program: Can I trust what it finds? Does it find enough of what matters? Is it realistic to implement across my organization? Pairing deterministic precision with frontier reasoning gives you the best chance of answering yes to all three.

Software isn’t slowing down. Our job now is closing the risk gap: the distance between how fast software is created and how fast risk gets found and fixed.

Auto-fetched and translated by AI Gem Box. All rights belong to the original author.