Every piece of software has bugs. Many have vulnerabilities. But not all software vulnerabilities are created equal.
Some are complicated, buried deep in obscure logic, or made possible by bleeding-edge exploit techniques. Others—well, others are glaringly obvious. These are the ones that make security professionals shake their heads and ask: How did this ever make it to production?
In a recent post, the UK’s National Cyber Security Centre (NCSC) offered a new way to think about security flaws: classify them as forgivable or unforgivable. This simple distinction challenges developers and product owners to reflect not just on what the vulnerability is, but why it happened—and what that says about their software development practices.
This isn’t a new concept. In 2007, Steve Christey of MITRE coined the term “unforgivable vulnerabilities” in a paper that remains remarkably relevant today. He also proposed a model—Vulnerability Assessment Assurance Levels (VAAL)—to measure the depth, complexity, and preventability of a vulnerability.
In this blog post, we explore what makes a vulnerability unforgivable, why it matters for your software security posture, and how this mindset can change the way your team handles vulnerability management.
What Are Unforgivable Software Vulnerabilities?
Christey’s concept of unforgivable software vulnerabilities is not about severity alone—it’s about obviousness, laziness, and negligence.
A software vulnerability is unforgivable when it:
- Has been widely known and well-documented for years
- Can be easily discovered with simple manual testing
- Uses canonical, low-effort attack techniques
- Is present in the most frequently used parts of an application
- Could be spotted in minutes by a security-aware developer or tester
Examples of Unforgivable Vulnerabilities:
- SQL Injection via login forms or user ID parameters
- XSS (Cross-site Scripting) using basic <script> tags in web input fields
- Remote File Inclusion using unsanitized GET/POST variables
- Directory Traversal with ../.. in file names
- Hard-coded admin passwords in production builds
- World-writable system executables or configuration files
- Authentication bypass using obvious tricks like authenticated=true
These aren’t rare edge cases. They’re foundational flaws that have been addressed in secure coding guides, university lectures, and OWASP Top 10 lists for over a decade. Their presence in modern software reveals a serious gap in secure development awareness.
VAAL: A Framework for Maturity in Software Vulnerability Management
To formalize this thinking, Christey proposed the Vulnerability Assessment Assurance Levels (VAAL)—a framework that looks beyond CVSS scores to assess a vulnerability’s broader context.
VAAL includes dimensions such as:
- Access constraints: Can an unauthenticated user exploit it?
- Feature frequency: Is the vulnerable code path commonly used?
- Novelty: Is the vulnerability a known class, or something new?
- Manipulation complexity: How easy is the exploit to craft?
- Effort to discover: Could it be found in five minutes with basic tools?
- Severity & ubiquity: Does it affect all installations, or just edge cases?
Unforgivable software vulnerabilities score low across these metrics—meaning they’re easy to find, easy to exploit, and hard to justify.
NCSC’s Take: Context and Culture Matter
The NCSC’s approach adds an ethical and cultural dimension to the technical framework. They encourage analysts and developers to ask:
“Given the maturity of the product, team, and context—should this vulnerability still be happening?”
It’s a subtle but powerful shift in thinking. A critical vulnerability might be forgivable if it’s highly complex or the result of a novel exploit. Conversely, a low-severity bug might be unforgivable if it’s the result of blind trust in user input, lack of validation, or copy-pasted insecure code.
This perspective invites software development teams to reflect not just on their software vulnerabilities, but on their processes, culture, and learning.
Why This Matters in 2025
Despite decades of secure coding education, unforgivable vulnerabilities are still rampant. At BSG, we regularly uncover issues during penetration testing that indicate not just individual mistakes—but fundamental development failures:
- Login forms vulnerable to SQL injection
- Client-side security checks with no server validation
- Open directories or world-writable configuration files
- Hardcoded backdoors “left in for testing”
These flaws aren’t just risky—they’re reputational liabilities.
In a world where software supply chain attacks and zero-day exploits dominate headlines, no organization can afford to ship code that breaks on page one of the security playbook.
How to Apply This Thinking
You don’t need to overhaul your entire SDLC to start identifying and preventing unforgivable software vulnerabilities. Start with these steps:
- Make a checklist: Use Christey’s “Lucky 13” as a baseline during code reviews.
- Shift-left with purpose: Train developers to spot “Found in Five” issues early.
- Use smarter metrics: Don’t just track CVSS—track VAAL-like maturity signals.
- Measure progress: Are you seeing fewer obvious bugs over time?
- Assess third-party software: Demand secure-by-design practices from your vendors.
TL;DR: Forgive the Novel, Condemn the Negligent
The takeaway is simple: not all software vulnerabilities are forgivable. Some are signs of innovation. Others are signs of negligence.
If your product—or a product you’re relying on—still has unauthenticated RCE due to a hardcoded password, the issue isn’t just technical. It’s cultural.
By adopting a mindset that distinguishes between forgivable and unforgivable flaws, you improve not just your security posture, but your entire engineering discipline.
Want help reviewing your software for unforgivable vulnerabilities?
We specialize in secure development assessments, penetration testing, and risk-based remediation strategies. Let’s make sure your code reflects your commitment to security.