Each guideline in the CERT C Secure Coding Standard contains a Risk Assessment section which attempts to provide software developers with an indication of the potential consequences of not addressing a particular vulnerability in their code (along with some indication of expected remediation costs). This information may be used to prioritize the repair of vulnerability classes by a development team. It is generally assumed that new code will be developed to be compliant with all applicable guidelines.
Priority and Levels
Each rule and recommendation has an assigned *Priority*. Priorities are assigned using a metric based on Failure Mode, Effects, and Criticality Analysis (FMECA) \[ [IEC 60812|AA. Bibliography#IEC 60812 2006]\]. Three values are assigned for each rule on a scale of 1 to 3 for Wiki Markup
- Severity – how serious are the consequences of the rule being ignored
Value
Meaning
Examples of Vulnerability
1
low
denial-of-service attack, abnormal termination
2
medium
data integrity violation, unintentional information disclosure
3
high
run arbitrary code
...
The three values are then multiplied together for each rule. This product provides a measure that can be used in prioritizing the application of the rules. These products range from 1 to 27, although only the following 10 distinct values are possible: 1, 2, 3, 4, 6, 8, 9, 12, 18, and 27. Rules and recommendations with a priority in the range of 1-4 are Level 3 rules, 6-9 are Level 2, and 12-27 are Level 1.
- Priorities and Levels
Level
Priorities
Possible Interpretation
L1
12, 18, 27
High severity, likely, inexpensive to repair
L2
6, 8, 9
Medium severity, probable, medium cost to repair
L3
1, 2, 3, 4
Low severity, unlikely, expensive to repair
As a result, it is possible to claim Level 1, Level 2, or complete compliance (Level 3) with a standard by implementing all rules in a level, as shown in the following illustration:
Recommendations are not compulsory and are provided for information purposes only.
...