Each guideline in the CERT Perl Secure Coding Standard contains a Risk Assessment section which section that 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.
...
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]. Three values are assigned for each rule on a scale of 1 to 3 for
Severity
– how—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
Likelihood
– how—How likely is it that a flaw
introducedintroduced by ignoring the rule can lead to an exploitable vulnerability?
Value
Meaning
1
unlikely
2
probable
3
likely
Remediation Cost
– how—How expensive is it to comply with the rule?
Value
Meaning
Detection
Correction
1
high
manual
manual
2
medium
automatic
manual
3
low
automatic
automatic
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 1–4 are Level 3 rules, 6-9 6–9 are Level 2, and 12-27 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
...
Where applicable, guidelines provide information on analyzer tools that can automatically diagnose violations of secure coding guidelines. Most automated analysis analyses for the Perl programming language are neither sound nor complete, so the inclusion of a tool in this section typically means that this tool can diagnose some violations of this particular rule. Currently, there is no conformance test suite available that can be used to access the false-positive and false-negative rates of analyzers when checking conformance for a particular guideline against source code . (Although although CERT has announced it will coordinate the development of a freely available, open source licensed conformance test).)
Because of the lack of an existing conformance test, the information in these sections may be
...
Additionally, because tools and The the CERT Perl Secure Coding Standard wiki both evolve continuously, this information can become dated and obsolete. Where possible, we try to reference the exact version of the tool for which the results were obtained.
...
The risk analysis section also contains a link to search for related vulnerabilities on the CERT website. Whenever possible, CERT Vulnerability Notes are tagged with a keyword corresponding to the unique ID of the coding guideline. This search provides you with an up-to-date list of real-world vulnerabilities which that have been determined to be at least partially caused by a violation of this specific guideline. These vulnerabilities are only labeled as such only when the vulnerability analysis team at the CERT/CC is able to evaluate the source code and precisely determine the cause of the vulnerability. Because many vulnerability notes refer to vulnerabilities in closed-source software systems, it is not always possible to provide this additional analysis. Consequently, the related vulnerabilities field tends to be somewhat sparsely populated.
...