Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
Description
Establish and maintain a severity rating system and process for application vulnerabilities that facilitates prioritizing the order in which discovered vulnerabilities are fixed. This process includes setting a minimum level of security acceptability for releasing code or applications. Severity ratings bring a systematic way of triaging vulnerabilities that improves risk management and helps ensure the most severe bugs are fixed first. Review and update the system and process annually.
Implementation Checklist
Tool Recommendations
Application security platform with SAST, DAST, SCA, and developer training for secure software development
Veracode · Per-application subscription
Cloud-native application security platform with SAST, SCA, DAST, API security, and supply chain security testing
Checkmarx · Per-developer subscription
Application security testing suite with SAST (Coverity), SCA (Black Duck), and DAST for comprehensive AppSec
Synopsys · Per-developer subscription
Threats & Vulnerabilities (CIS RAM)
Threat Scenarios
Critical Vulnerability Deprioritized Without Severity Framework
IntegrityA critical remote code execution vulnerability in a customer-facing application is treated with the same urgency as a minor cosmetic bug because no severity rating system exists to prioritize remediation.
Low-Severity Vulnerabilities Consume Resources While Critical Flaws Persist
ConfidentialityDevelopment teams spend time fixing low-impact vulnerabilities while critical security flaws in production applications remain unpatched because no prioritization framework guides remediation ordering.
Vulnerabilities (When Safeguard Absent)
No Vulnerability Severity Rating System
Without a severity rating system, all vulnerabilities are treated equally, preventing the organization from directing remediation resources toward the most critical and exploitable flaws first.
No Minimum Security Acceptability Threshold for Releases
Absence of a minimum security bar means applications can be released to production with unresolved critical vulnerabilities because there is no defined standard preventing it.
Evidence Requirements
| Type | Evidence Item | Collection Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |