Stop Trusting the Security Scorecard: Why AI Code Needs Teeth, Not Numbers

I merged a feature last month that Claude had written. It handled user authentication state. The code looked clean, followed patterns I recognized, passed all the tests. Three days later, a security consultant I'd hired for a compliance audit found a partial bypass in the session validation logic — the kind of thing that would've taken an attacker maybe two hours to exploit once they knew what they were looking for.

That's when I realized I'd been operating on a lie: the code was "secure" because the AI told me it was secure, which meant nothing.

Every LLM-powered code generation tool I've used lately slaps some variant of "security-aware" on their marketing page. GitHub Copilot mentions it. Claude does. Even smaller specialized tools claim it. But when you ask any of them to prove it — to give you an actual number you can audit, a score that's tamper-evident, a formula you can inspect — you get silence or marketing fluff. That gap between claimed security and verifiable security is where real risk lives.

The Problem With Marketing Metrics

Here's what bothers me most: the security metrics that do exist are often designed to flatter the tool, not inform the developer.

A "pass rate" tells you how many attacks a model blocked versus failed against, but it's lying to you through omission. If a model blocks 18 out of 20 attacks, that sounds great until you realize one of those two failures is an authentication bypass. The pass rate treats that the same as it treats a blocked SQL injection attempt. Meanwhile, a codebase that has three partially-bypassable defenses (the ones that work 90% of the time) gets scored identically to one with clean blocks and total failures mixed together — both might be 0.5, but they're not the same risk.

I've worked on systems where that distinction mattered. HIPAA environments. PCI compliance work. Once you're in regulated territory, "mostly secure" isn't a category that exists. You need to know where the partial defenses are, where the complete gaps are, and which attacks actually threaten your specific domain.

What ARS Actually Does Differently

The Adversarial Resilience Score takes a different approach: it averages continuous per-attack scores across three states (fully mitigated = 1.0, partial/bypassable = 0.5, completely missed = 0.0) rather than collapsing everything into pass/fail buckets.

That sounds like a small technical difference. It's not. A score that lands on a continuous scale from 0.0 to 1.0 forces you to acknowledge gradients. A codebase with mostly clean blocks but two serious gaps scores measurably different from one with mixed results, even if the counts look similar on paper. More importantly, you can't game it by throwing trivial attacks at the tool. One serious missed attack drags the average down hard, the way a real vulnerability should.

The mechanism itself is auditable: every score comes with a one-line explanation from an independent verdict model, and the entire report is hashed so you can verify it wasn't touched up after the fact. That's not proof the code is actually secure — it's proof that whatever score you're reading is the score that was genuinely computed.

What I'd Actually Want to See

I appreciate the approach here, but I have questions.

First: how much does the quality of the attack playbook matter? The tool uses domain-specific scenarios (OWASP Top 10, HIPAA, PCI DSS) rather than generic fuzzing, which I like. But who decides what counts as an attack in HIPAA mode? Is there community review? Can you propose new attacks? A framework is only as good as the rigor that went into building it.

Second: an ARS of 0.80 gating the build is bold. I respect the decision to make security advisory, not optional. But in practice, that threshold might be too prescriptive for some teams and too loose for others. What does 0.80 actually mean in terms of real-world attack probability? That needs more clarity.

Third — and this is the developer in me talking — I'd want to see how this integrates into actual CI/CD workflows without becoming another noisy failure that teams disable by default.

The Real Value Proposition

Stripping away the concept, what this actually does is replace "the AI says the code is secure" with "here are the specific attacks the code failed against, why it failed, and a comparable score you can track over time."

That's genuinely useful. Not because it's a perfect security measure — nothing is. But because it's verifiable, explainable, and domain-aware. Those three things together are rare enough that they're worth paying attention to.

Source: This post was inspired by "The Adversarial Resilience Score: A New Metric for AI-Generated Code" by Dev.to. Read the original article