User Guide
Appendix B: Static Analysis Results Prioritization
has reviewed the results.) The likelihood of a finding is computed by combining the accuracy of the
rule and the confidence in the analysis with the probability that the vulnerability will be discovered
and acted upon, as follows:
likelihood = accuracy x confidence x probability
For the purpose of weighing static analysis results, an accuracy measure is associated with each rule
applied by the analysis engine. This number represents the possibility that the rule will correctly
identify a vulnerability.
For example, the rule that Fortify Static Code Analyzer uses to identify the member field race
condition has a high accuracy because it precisely identifies assignments to a member field of a
singleton object. Conversely, the rule used to identify cross-site request forgery has a low accuracy
because it identifies potentially vulnerable form submissions and relies on a human auditor to
determine whether the form submissions are susceptible to cross-site request forgery.
During static analysis, Fortify Static Code Analyzer might have to make assumptions about the way
the code behaves at runtime. The more assumptions Fortify Static Code Analyzer makes, the more
likely it is that a result is incorrect.
The term confidence is used to estimate the possibility that Fortify Static Code Analyzer correctly
applies the rule. For example, Fortify Static Code Analyzer reports reflected cross-site scripting
vulnerabilities in a JSP where data from a request parameter is echoed directly to the page with high
confidence. Conversely, Fortify Static Code Analyzer reports a persistent cross-site scripting issue
where data read from a database into a class selected at runtime using dependency injection is
rendered in the presentation tier with low confidence.
To represent the probability that the vulnerability is discovered and acted upon (with action
potentially coming the form of an exploit), Fortify Static Code Analyzer associates a probability
measure with each category of vulnerability identified by the rules. For example, cross-site scripting
vulnerabilities carry a higher probability than member field race conditions because they are more
likely to be discovered and exploited.
From a programmer’s perspective, some bugs are harder to fix than others. Modifying a single line of
code in a self-contained method is easier than modifying the result of a sequence of calls that span
the program. The term remediation effort describes the relative amount of effort required to fix and
verify a finding.
Fortify Static Code Analyzer provides a remediation effort with each finding it reports. For example,
member field race conditions have a small remediation effort, while cross-site request forgery, which
often involves major changes to a website, has a high remediation effort.
To avoid implying too much precision where little exists, Fortify Static Code Analyzer limits values of
impact, accuracy, confidence, and probability to a decimal range of from 0.1 to 5.0 and scales the
calculated likelihood value to the same range. It then defines high values for impact and likelihood as
those at 2.5 and above [2.5,5.0] and low values as those below 2.5 (0,2.5).
Fortify Static Code Analyzer does not provide units for remediation effort because the absolute cost
of remediating different vulnerabilities differs from one organization to another. Instead, remediation
effort estimates the relative cost to remediate one kind of finding versus another, thereby enabling a
comparison of the effort required to remediate different vulnerabilities or vulnerabilities across more
than one project.
Micro Focus Fortify Audit Workbench (22.1.0)
Page 147 of 156