The Conventional Wisdom
Security teams often view AI-powered vulnerability detection as an add-on to existing processes. You conduct static analysis, dynamic scans, and dependency checks, then perhaps experiment with an AI tool. The belief is that AI is promising but unproven, so it should be used cautiously until it matures. Let others take the initial risks.
This cautious approach seems responsible. After all, PCI DSS Requirement 6.3.2 in v4.0.1 mandates identifying security vulnerabilities through established methods. ISO 27001 expects systematic vulnerability management. You can't risk your compliance on untested technology.
Why This View Is Incomplete
The DARPA-led AI Cyber Challenge (AIxCC), announced at Black Hat in August 2023, challenges this assumption. Teams built autonomous systems that found over 80% of vulnerabilities and successfully patched nearly 70% of them. More strikingly, the compute cost was tens to hundreds of dollars per vulnerability—cheaper than a security engineer's manual triage.
The conventional wisdom overlooks a critical point: treating AI as supplemental means you never truly test your existing process. You assume your current toolchain is the standard, and AI must prove its worth. But what if your baseline is flawed?
Consider your current vulnerability management. Your SAST tool flags 3,000 issues. Your SCA tool adds 800 dependency alerts. Your DAST scanner contributes another 500. You're overwhelmed with 4,300 findings, mostly false positives or low-severity noise. You've built an entire workflow around managing this flood—tagging, prioritizing, assigning, tracking exceptions.
The AIxCC results suggest a different approach: start with the AI system and supplement with traditional tools where AI falls short.
The Evidence
The competition revealed unexpected efficiency. Teams didn't just find vulnerabilities—they operated within practical resource constraints. The compute cost is significant because it directly impacts operational reality. If finding and patching a vulnerability costs tens of dollars in compute versus hundreds in engineer time, you've changed the economics of vulnerability management.
The 80% detection rate needs context. Your current SAST tool's detection rate is likely unmeasured. You assume it's comprehensive because it generates thousands of alerts. But comprehensiveness isn't effectiveness. An AI system that finds 80% of actual vulnerabilities with minimal false positives outperforms a traditional tool that finds 95% of potential issues but overwhelms you with noise.
The 70% automated patching rate is practical. NIST 800-53 control SI-2 requires installing security-relevant software updates within defined time periods. Most teams struggle with this because patching requires context—will this fix break something else? The AIxCC systems didn't just identify issues; they generated patches that worked.
Skepticism from the security community drove these results. Teams knew experts doubted AI's capability, so they had to prove it was efficient enough for real-world deployment.
What to Do Instead
Invert your evaluation criteria. Instead of asking, "Can AI match our existing tools?" ask, "Can our existing tools match AI's signal-to-noise ratio?"
Run this experiment: Take a representative codebase with known vulnerabilities from a previous pentest or bug bounty. Run your current toolchain against it. Count the alerts and hours your team spends reaching actual vulnerabilities. Measure the false positive rate honestly.
Then evaluate AI-powered tools against the same codebase. Don't judge them by whether they find everything your SAST tool finds. Judge them by whether they find the vulnerabilities that matter with less noise.
For integration with existing security operations, treat AI systems as first-pass filters. Your SOC 2 Type II audit will still require evidence of human review for critical findings. But there's no requirement that humans must be first in the pipeline. Let AI handle initial detection and triage. Route high-confidence findings directly to remediation. Escalate edge cases to human review.
Document your decision criteria. When AI suggests a patch, what conditions trigger automatic deployment versus manual review? Criticality of the system? Type of vulnerability? Confidence score? This becomes your audit evidence that you're using AI responsibly within your risk management framework.
For teams under PCI DSS v4.0.1, Requirement 6.3.3 requires reviewing custom code before release. AI-generated patches count as custom code. Build a review process proportional to risk—automated testing for low-risk patches, human review for anything touching cardholder data.
When the Conventional Wisdom Is Right
The cautious approach makes sense in three scenarios.
First, when you're in a highly regulated environment with explicit tool certification requirements. Some frameworks specify approved vulnerability scanning tools by name. You can't swap in an AI system until it appears on the approved list, regardless of its effectiveness.
Second, when you lack the infrastructure to validate AI outputs. If you don't have comprehensive test coverage, you can't safely deploy AI-generated patches. The AIxCC teams succeeded because they built systems that could verify their work. Without that verification layer, you're introducing new risk.
Third, when your team doesn't understand the underlying vulnerabilities well enough to spot when AI gets it wrong. AI systems fail predictably—they struggle with business logic flaws, miss vulnerabilities requiring user intent understanding, and can suggest patches that fix symptoms but not root causes. If your team can't recognize these failure modes, you need more human expertise in the loop, not less.
The AIxCC proved AI can efficiently find and fix vulnerabilities. But efficiency without understanding is dangerous. Use AI to handle volume. Keep humans focused on complexity. That's not conventional wisdom—it's evidence-based practice.
