### **Background** To advance the Static Reachability feature to Beta, we need to enhance stability, observability, and user guidance. This phase focuses on addressing any outstanding issues, integrating key metrics, transitioning to the new Dependency Scanning analyzer, and providing external documentation. These improvements will bring the feature closer to a production-ready state, delivering a more robust and reliable experience. **Engineering DRI** : @nilieskou ### Experimental (current status) In order to enable Static reachability (experimental) the user needs to: * To include the Dependency Scanning and the latest SAST templates and setting `DS_ENFORCE_NEW_ANALYZER=true` * Only the old DS analyzer is supported, i.e. Gemnasium * The user needs to provide a docker image with the code to be scanned. This is a requirement for `sca-to-sarif-matcher`. There are a couple of bugs or not nice to have that are associated with this approach: * static reachability results are not guaranteed to reach the Gitlab rails DB since we have a possible race with SBOM ingestion. * the docker image needs to have specific packages installed * if container scanning is added in the pipeline static reachability fails * The DS job needs to add an unknown static reachability property for all components in SBOM.   ### **Beta** Here you can see a list of things that needs to be implemented in order to reach Beta: * In order to improve UX we must not require a docker image for `sca-to-sarif-matcher` to run. Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/520509 and https://gitlab.com/gitlab-org/gitlab/-/issues/521306. * We need to ensure that reachability data are always stored consistently in the Gitlab database. Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/500746. * Static reachability should work with Container Scanning. Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/520432. * We should enable static reachability for the new DS analyzer. Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/501054. Moreover, the plan is to have static reachability to work only with the new DS analyzer to promote its use. See https://gitlab.com/gitlab-org/gitlab/-/issues/521587#note_2371511520 * We should provide a UI element that can be used by the user. Relates to https://gitlab.com/groups/gitlab-org/-/epics/16510 blocked by https://gitlab.com/gitlab-org/gitlab/-/issues/513990, https://gitlab.com/gitlab-org/gitlab/-/issues/513991. * We should support Python projects. * Enrichment job should not require a docker image. * We should always mark transitive dependencies as `in_use` if the parent dependency is also `in_use`. * For beta we won't support offline instances. * Stretch: Support javascript For beta the enrichment job will be part of the dependency scanning job. That means that enabling static reachability will introduce only 1 job (SR job) which will run before the DS job starts.  ### More information about Beta * Experimental phase supports Python and Java. However, `Java` might be more difficult to properly support with a dockerless `sca-to-sarif-matcher`. For that reason we would prefer to focus on doing only PyPi for Beta and possibly extend to Javascript. * The biggest problem with supporting a dockerless `sca-to-sarif-matcher` for Python is to have information regarding library to module names mapping. This is required in order to identify correctly when a library is actually used. Instead of getting this information by looking on the actual installed packages in the docker image we can offline collect information for all PyPi packages. For Beta we can do that once and just for the latest version of every package and store the dataset somewhere, possibly in a git repo that can be downloaded by `sca-to-sarif-matcher`. For GA we need to perform PyPi metadata extraction in a continuous fashion for every package version. This could be part of PMDB.