Full Report
Research from the NCSC designed to eradicate vulnerability classes and make the top-level mitigations easier to implement.
Analysis Summary
# Research: A method to assess 'forgivable' vs 'unforgivable' vulnerabilities
## Metadata
- **Authors**: NCSC Research Team
- **Institution**: National Cyber Security Centre (NCSC)
- **Publication**: NCSC.GOV.UK Reports
- **Date**: 28 January 2025
## Abstract
This research introduces a novel framework for categorizing software vulnerabilities based on the difficulty of their prevention and the maturity of existing mitigations. By distinguishing between "forgivable" vulnerabilities (complex, novel, or architectural) and "unforgivable" vulnerabilities (those that are trivial to prevent or belong to classes with well-established, automated mitigations), the NCSC aims to shift the industry focus toward eradicating entire classes of trivial defects at scale.
## Research Objective
The research addresses the persistent prevalence of "low-hanging fruit"—vulnerabilities that continue to appear in modern software despite decades of known defensive patterns. The objective is to provide a methodology that allows organizations and regulators to hold software vendors accountable for failing to implement basic "secure-by-design" principles.
## Methodology
### Approach
The researchers developed a qualitative assessment framework that evaluates a vulnerability based on:
1. **Preventability**: The availability of tools, language features (e.g., memory-safe languages), or libraries that prevent the bug.
2. **Maturity of Mitigation**: How well-understood the remediation is within the industry.
3. **Developer Experience**: The effort required by a developer to implement the secure alternative versus the insecure one.
### Dataset/Environment
The framework was tested against historical vulnerability data, including high-profile cases like the Atlassian Confluence OGNL injection and common memory corruption bugs, to validate whether they could be objectively classified under the new criteria.
### Tools & Technologies
- **Vulnerability Class Analysis**: Categorization based on CWE (Common Weakness Enumeration).
- **Secure-by-Design Principles**: Alignment with international guidance from CISA, FBI, and NCSC.
## Key Findings
### Primary Results
1. **Bifurcation of Risk**: Vulnerabilities are not created equal; a significant portion of modern CVEs are "unforgivable" because the technology to prevent them has existed for over a decade.
2. **Systemic Failure**: The continued presence of "unforgivable" bugs indicates a failure in the software development lifecycle (SDLC) rather than a lack of technical solutions.
3. **Incentive Alignment**: Categorizing bugs this way provides a metric for "quality" that can influence procurement and regulatory oversight.
### Supporting Evidence
- Empirical analysis of "trivial" bugs (like basic SQL injection or buffer overflows in non-legacy code) shows they persist even in products from mature vendors.
- References to OGNL injection bugs as examples where modern frameworks provide safe defaults that were bypassed or ignored.
### Novel Contributions
- **The "Forgovability" Scale**: A conceptual framework that moves beyond "Severity" (CVSS) to "Avoidability."
- **Institutional Memory**: A focus on ensuring that once a class of vulnerability is understood, it is structurally eliminated from future codebases.
## Technical Details
The methodology suggests that a vulnerability is "unforgivable" if it meets the **"Commodity Mitigation Test"**:
- Does a compiler flag, a safe library/API, or a memory-safe language exist that would have rendered this bug impossible?
- If yes, and it was not used in a new product, the vulnerability is classified as unforgivable.
- Technical examples include using `strcpy()` instead of safer alternatives or failing to use parameterized queries in SQL environments.
## Practical Implications
### For Security Practitioners
- Use this framework to prioritize vendor management. A vendor with fewer "unforgivable" bugs is demonstrably more mature in their security engineering.
### For Defenders
- Move away from "whack-a-mole" patching. Focus on whether your internal development teams are repeating "unforgivable" mistakes, which indicates a need for better linting, architectural changes, or language shifts.
### For Researchers
- Provides a new metric for analyzing the "security debt" of software ecosystems.
## Limitations
- **Legacy Code**: The research acknowledges that applying "unforgivable" standards to 30-year-old legacy codebases is difficult, as the cost of refactoring may be prohibitive.
- **Subjectivity**: While the framework aims for objectivity, "ease of implementation" can be subjective depending on the specific constraints of embedded or high-performance systems.
## Comparison to Prior Work
Unlike the **CVSS (Common Vulnerability Scoring System)**, which measures the *impact* and *exploitability* of a bug, this NCSC research measures the *competence* of the prevention strategy. It shifts the conversation from "how bad is this bug?" to "why did this bug exist in the first place?"
## Real-world Applications
- **Procurement**: Government and enterprise entities can require vendors to disclose the ratio of forgivable vs. unforgivable bugs found during audits.
- **Software Transparency**: Incorporating these metrics into Software Bill of Materials (SBOM) discussions.
## Future Work
- Refinement of the criteria for at-scale automated classification of vulnerabilities.
- Integration of the "forgivable" metric into international standards for secure software development.
## References
- CISA/NCSC: *Secure by Design, Secure by Default*.
- Atlassian Confluence OGNL Injection Analysis (2024).
- Zheng et al. (2019): *Empirical study of OpenStack software bugs*.