## Overview This epic aims to enhance our Static Reachability feature by experimenting with function-level granularity for Python applications. Static Reachability is designed to flag Software Composition Analysis (SCA) findings as `REACHABLE` when vulnerable code is determined to be accessible from the customer's codebase. ## Goal The primary objective is to conduct an experiment and develop a Proof of Concept (PoC) that supports function-level granularity, which represents the most precise and accurate level of reachability analysis. ## Levels of Reachability Reachability can be defined at different levels: 1. Verifying that the vulnerable library is imported by the code 2. Confirming that the vulnerable library is utilized by the code (calls to functions defined in the library) 3. Ensuring that the code specifically uses vulnerable functions from the library This epic focuses on achieving the third and most granular level. ## High-level Architecture  ## Experiment Steps ### Offline Analysis of CVEs 1. Identify the corresponding diff that fixes the vulnerability 2. Utilize a Large Language Model (LLM) to extract vulnerable symbols 3. Apply static analysis to identify all dangerous public functions (those that reach a vulnerable symbol) ### Analysis of Customer Code 1. Employ static analysis to determine if the customer's code invokes any of the identified dangerous functions ## Expected Outcome The experiment should result in a PoC demonstrating the feasibility and effectiveness of function-level granularity for Static Reachability in Python applications. This will provide valuable insights for potential implementation in our security features. ## Implementation strategy ### Unknown feasibility The above design relies on multiples points that needs to be further refined: - Identify the code diff that fixes the vulnerability - Extraction of vulnerable symbols Those items don't have a clear technical solution.\ An early prototype will help grab a better understanding of the what can be technically achieved.\ We need to identify the different potential directions and their corresponding level of efforts and quality. Those prototypes must be done as early as possible, since their outcome can dramatically impact the expected efforts. Can we rely on a fully/mostly automated process for identifying the fixing commit?\ Or should we invest manual efforts to enrich the database with that information? ### Related links * https://gitlab.com/groups/gitlab-org/-/epics/17884#note_2687091912 ## Unknown efforts - Setting up a scalable infrastructure for a constant enrichment of GLAD - Do we have an existing infrastructure that we can leverage? OSS-PR? The ongoing research on that topic will be documented in [:google_docs: Function-Level Reachability Analysis - Research Document](https://docs.google.com/document/d/1xoLgXiGnB7gSK0JhLKXiy-uXZGXbAwbhFnt8gyNDftU/edit?usp=sharing) /cc @tkopel @johncrowley \\ /cc @twoodham