How do I audit findings in the Software Composition Analysis Report?

Question

Answer

The OIS Software Assurance Software Composition Analysis Report provides a list of the known vulnerabilities in libraries and frameworks used by the application being scanned. Each finding will be categorized according to severity and will contain a link to a known vulnerability, e.g. a particular CVE which contains details about the vulnerability and mitigation advice.

To respond to these findings, the developer should view the VA SwA Composition Analysis Appendix Word document supplied by OIS Software Assurance. This document lists all of the identified vulnerabilities with a “Developer Response” section for each.

The developer should analyze each finding to determine if it is a true or false positive. If it is a false positive, the developer should provide an explanation in the Appendix document’s “Developer Response” column, including references to fixes in the code (e.g. filenames, line numbers) or other relevant information that explains why the finding does not apply to the application.

After the VA SwA Composition Analysis Appendix Word document has been updated with the appropriate developer responses for each finding, the updated document should be included in future code review submissions.

Note: This is different from the Fortify audit process where such comments are entered into the FPR scan file.

Guidance for analyzing and auditing findings

Below are three notional examples of how to resolve different types of Software Composition Analysis findings. For findings in the report, the linked CVE or other reporting source will contain details about the vulnerability, impacted versions, and potential fixes. The link will also include a description of the issue and a list of references that can be read for further details.

Example that requires an upgrade: CVE-2020-5902 lists the affected versions, so the developer can confirm whether or not they are using an impacted version. Links provided through the CVE list versions where the vulnerability has been fixed, so the developer can upgrade to a patched version that does not contain the vulnerability.
Example that requires code changes: mitigations can be implemented in the application’s source code to change how the library/framework is used to ensure the vulnerability is mitigated. In this case, the developer should provide details about where these mitigations reside in the code (filenames and line numbers) and how they resolve the issue. For example, CVE-2020-8908 recommends against using Guava API com.google.common.io.Files.createTempDir() since it does not appropriately set permissions. It is recommend to instead use java.nio.file.Files.createTempDirectory() which explicitly sets permissions upon creation. If this code change is made or another mitigation is put in place, the developer should describe it in the provided comments.
Example where only analysis is required to determine applicability: if the identified vulnerability is in a component of a library/framework that the application and its dependencies are not using, the developer should state that the component is not used in the developer’s response. For example, CVE-2021-29425 describes an issue with Apache Commons FileNameUtils.normalize(). If this function is not being used by the application, or by any other dependency used by the application, that can be stated as a mitigation in the developer’s comments. Note that if the component is used indirectly - i.e., the component with the vulnerability is used by a component that is used by the application (or any number of levels of indirection), it is considered to be used by the application, and the vulnerability must be mitigated.

Note that inclusion in the TRM is generally not a sufficient mitigation for reported findings.

If the dependency flagged by the tool is a transitive dependency, e.g. a dependency of a dependency, please see this technical note for information on auditing those findings.

Additional Information

Note that the source for which vulnerability data is being retrieved is mainly CVE although it is also retrieved from industry sources: