Prioritizing reachable vulnerabilities (Beta)

📘

Reachability is in beta, and requires to be enabled for your organization. Please reach out to support or your FOSSA account manager, to enable reachability.

What is Reachability?

Reachability is FOSSA’s security feature, which infers if the vulnerability is reachable in your first-party code. It allows you to identify which vulnerabilities are reachable and helps you prioritize remediation work. When a vulnerability is reachable, FOSSA’s reachability analysis lists call paths from your first-party code to vulnerable functions associated with CVEs.

This way, you can proactively remediate the issue by modifying your usage of dependency. The following instructions will walk through an example of how reachability analysis works in FOSSA.

Limitations

• Reachability is only supported for JAVA projects built with either Gradle or Maven, and scanned by FOSSA CLI v3.9.2 or greater. FOSSA CLI must find built jar files for analysis. If either of those conditions is not met, FOSSA will not perform a reachability analysis.

• If you are an on-prem customer, you would need FOSSA v4.17.10 or greater, to support reachability.

• If a project analyzed by FOSSA contains multiple JVM-based projects (not multi-module builds, but distinct builds), and if those projects have the same vulnerability and same dependency - FOSSA will not be able to differ if both dependencies's vulnerabilities are reachable.

• FOSSA currently does not traverse call paths resulted from use of Java's Reflection - and as result may not find reachability, if the Reflection or class loader was used to invoke vulnerable function.

Walkthrough

In this section, we will walk through an analysis of example projects end-to-end. We will (1) analyze an example project and (2) explore web UI to highlight reachability.

1. Analyze Maven Project

# Get example project
; git clone https://github.com/fossas/reachability-with-maven-example.git
; cd reachability-with-maven-example

# (required) perform maven build
# if jar artifact is not present reachability will not be performed
; mvn package

# Get latest FOSSA CLI
# docs: https://github.com/fossas/fossa-cli
; curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install-latest.sh | bash


# Check CLI Version (must be greater or equal to v3.9.2)
; fossa --version 

# Analyze with fossa
; fossa analyze -p reachability-example -r example-revision --fossa-api-key <MY-FOSSA-KEY>

This project contains ten total dependencies, with two dependencies having known vulnerabilities,

• org.dom4j:dom4j$2.1.0 (with CVEs of: CVE-2020-10683 and CVE-2018-1000632)
• com.google.guava:guava$28.1-jre (with CVEs of: CVE-2023-2976 and CVE-2020-8908)

2. Explore User Interface

We expect our user interface to change as Reachability functionality is being actively worked on and expanded for more languages.

On our project's page, under "Security Issues," all vulnerabilities are enumerated for the dependencies mentioned above. A new tag, "Reachable," appears for vulnerability, which FOSSA has confirmed to be reachable from first-party code.

Further, FOSSA enumerates all code paths from which vulnerability is reachable when FOSSA confirms reachability. To view code paths from your first-party code, click on the vulnerability. Click the "Reachability" tab to view code paths on the detailed issue view.

In the above example,

1. Region indicated by (1) shows vulnerable function: org.dom4j.io.SAXReader:<init>()
2. Region indicated by (2) shows the first code path from first party code to vulnerable function
3. Region indicated by (3) shows the second code path from first party code to vulnerable function

Reachability Filter

The security Issues page now includes a Reachability filter on the right side. When "reachability" is toggled, only vulnerabilities confirmed to be reachable are displayed on the page.

Note, "Reachable" means that FOSSA has confirmed that the vulnerability is reachable. It does not mean vulnerability is not a security issue or concern.

Please refer to: If CVE is not reachable, does that mean CVE is not a security issue?

F.A.Q.

1. How do I enable reachability?

To enable Reachability, your organization must have a security offering, and a “Reachability” feature flag enabled. If unsure, please get in touch with support at https://support.fossa.com/hc/en-us or your account manager.

2. How does reachability work?

FOSSA performs reachability analysis in the following steps,

1. FOSSA CLI scans your project to infer all direct and transitive dependencies.
2. FOSSA CLI scans your project to construct a call graph of fully qualified symbols.
3. FOSSA CLI uploads a list of dependencies and constructs a call graph for detailed analysis.
4. FOSSA Endpoint constructs hydrated call graphs with dependencies.
5. FOSSA Endpoint: infer that vulnerable symbols associated with CVEs are present in your call graph.

FOSSA uses different techniques depending on the project being analyzed. For JAVA projects built with Gradle or Maven - FOSSA CLI will use the built jar to infer call graphs associated with the first-party code.

To learn more, refer to FOSSA CLI docs.

3. Why is FOSSA not finding reachability for specific CVE?

FOSSA can not find reachability for the CVE if FOSSA does not have a record of vulnerable functions associated with the CVE.

4. If CVE is not reachable, does that mean CVE is not a security issue?

🚧

No, CVE is still a security issue and should be remediated.

When FOSSA marks CVE as reachable, FOSSA has identified a path from a vulnerable function associated with CVE to code path(s) in your first-party code or artifact(s).

Conversely, if CVE is not marked as “reachable,” it could mean,

• FOSSA does not have a record of vulnerable functions associated with CVE, and as such, is unable to infer if CVE is reachable or not reachable
• FOSSA CLI may not have scanned projects in which CVE is present
• FOSSA CLI may not have scanned projects in which CVE is present with reachability analysis

Security issues and CVEs not marked as Reachable do not imply they are not security issues; it simply means FOSSA couldn’t confidently determine whether CVE is reachable.

5. Does fossa upload my source code for reachability?

FOSSA does not upload source code for reachability. FOSSA performs a scan on your project to construct a call graph and uploads this call graph for further analysis. The actual source code is not uploaded to the FOSSA endpoint.

FOSSA requires a (caller, call site) relationship from your source code to infer if the vulnerable function is used. As such, we upload call graph information for analysis. An example snippet of the call graph uploaded to the endpoint is below.

com.example.app.App:parse(java.net.URL) org.dom4j.io.SAXReader:<init>()
com.example.app.App:parse(java.net.URL) org.dom4j.io.SAXReader:read(java.net.URL)

You can see all reachability data uploaded by FOSSA CLI. To do so,

# run in output and debug mode, this way we run analysis locally
# and perform no upload to endpoint
; fossa analyze -o --debug

# extract debug bundle
; gunzip fossa.debug.json.gz

# look at the content
; cat fossa.debug.json | jq '.bundleReachabilityRaw'

6. How do I get help with reachability?

Please reach out to our support team at: https://support.fossa.com/hc/en-us

7. How do I report inaccuracy?

Send us a report using the “Report a data issue with this vulnerability” option at the bottom of the Vulnerability Issue.