## Executive summary This document outlines GitLab’s approach to improving triage and remediation decisions for users by introducing reachability data. Information contained within this document will outline market needs, problems to be solved, competitive analysis, functionality, and user experience goals. ### Static Reachability Static Reachability designates the usage of a dependency in a software application. It establishes whether or not the dependency is called, which can allow users to distill their scan results into more actionable remediation plans. This reduces noise and allows users to deprioritize vulnerabilities that are attributed to dependencies that are not actually used in their application. ### Problems to be solved Users are inundated with a high volume of vulnerabilities in their scan results and cannot make quick remediation decisions in the context of their project. We currently offer three data points that aid remediation decisions: CVSS Severity, EPSS score, and KEV. These are helpful, but lack contextual insight into the project where a vulnerability was identified. Providing usage information for dependencies allows for easier decision making when determining priority order for remediating vulnerabilities. [See user journey map](https://www.figma.com/board/qGzSUoc7meihiKXk3gqJFC/CA---Static-Reachability-User-Journey?node-id=0-1&p=f&t=x20UkFrTLKguo2Uv-0). ## Requirements ### Functionality Our Static Reachability functionality should be able to support Java, JavaScript and Python. In the future we can examine the need to expand language support to C#, go, Ruby, and others based on customer needs. Users should be able to receive reachability results as a part of their Dependency Scan. We should be mindful of the performance of the analysis so as to not slow down scans, which would have a negative impact on pipelines. Reachability can be disabled through a template, but it is on-by-default. We should adhere to on-by-default as data generated by reachability analysis does not negatively impact scan results, only enriches them. To designate whether or not a dependency is reachable we should return information that the dependency is reachable or we were unable to make a determination. In the case where a dependency is reachable we have confidence in our findings. There may be cases where we are unable to establish if the dependency is reachable with OUR analysis, but this does not mean the dependency is not reachable. We do not want to give false information to users and should err on the side of caution. Reachability data should be accessible for consumption by front-end facing teams. This will enable user-experience goals. ### User experience Users will receive reachability results post-Dependency scan. We will propagate this information to users in the following areas: #### Vulnerability report Users will see reachability information within the **Severity** column. We should be mindful of overcrowding this space and add this information in a hoverover for rows where Tool Type is Dependency Scanning. The user will see two options, depending on our findings: 1. Reachable: Yes - designating that we were able to perform the analysis and identify reachability 2. Reachable: Not Available - designating that we were either unable to perform the analysis or could not make a determination. The user should be able to filter on reachability so as to distill the Dependency Scanning results into a smaller data set to more easily triage and focus remediation efforts. #### Vulnerability details page The user should also see reachability information in the Vulnerability details page. This information will appear only for Dependency Scanning vulnerabilities. Beneath the existing information on this page (CVSS, EPSS, KEV, etc.) the user will see two options, depending on our findings: 1. Reachable: Yes - designating that we were able to perform the analysis and identify reachability 2. Reachable: Not Available - designating that we were either unable to perform the analysis or could not make a determination. ## Maturity levels ### Experiment * Users will receive reachability information for Java dependencies * We will leverage Oxeye analysis engine to power the analysis * Users should not need to be a SAST user to use Static Reachability * Users should be able to see a reachability indicator in the GraphQL API ### Beta * Users will receive reachability information for Python dependencies * Improve configuration for users by removing need to use a docker container to derive reachability information * Handle transitive dependencies by marking them as reachable if their parent dependency is reachable * Include a UI element on the Vulnerability report and Vulnerability details page ### General Availability * Full language support (Java, JavaScript, Python) * Support for offline environments * UI filtering on the vulnerability report * Replace analysis engine with semgrep-core to improve performance * Support for Pipeline Execution Policies ## Success measures 1. **Reachable dependencies remediated by CVSS Severity** 1. Helps us understand if certain severity levels associated with reachable dependencies are of higher urgency. 2. We should capture non-reachable dependencies as well to have a comparison. 2. **Time to remediation for reachable dependencies, grouping by CVSS Severity** 1. Highlights that users are prioritizing reachable dependencies for remediation, showing that we are solving the [problem](#bookmark=id.lbnlpbyrg53z) above. First Teams | Phase | First Team | |-------|------------| | Implement reachability with semgrep rules | VR + Composition Analysis | | Update Vulnerability report | Security Insights + Composition Analysis |