Enable Static Reachability in latest DS template

What does this MR do and why?

Currently we can enable static reachability (SR) by setting GITLAB_STATIC_REACHABILITY_ENABLED to true and including Jobs/SAST.latest.gitlab-ci.yml . This will introduce two jobs required for the static reachability:

• gitlab-static-reachability: Providing reachability data
• gitlab-enrich-cdx-results: Combining the reports from gitlab-static-reachability and DS SBOM to provide an SBOM report with reachability data.

Notice that the static-reachability feature depends on DS so including the template for DS is a requirement. This approach is overcomplicating things since static reachability is a SCA feature and hence it should be located in Jobs/Dependency-Scanning.latest.gitlab-ci.yml.

In this MR we delete everything related to static reachability from the SAST latest template and we move it to the DS latest template. Moreover we:

• Get rid of the .post job for enriching the sbom with static reachability data. This was needed since it could cause a SBOM ingestion race. That means that we are not sure which SBOM report would be ingested first. The one from DS job (no SR data) or the one from the .post job (containing SR data).
• Moved the enrichment .post job (SCA-to-sarif-matcher analyzer) into the DS analyzer.
• The gitlab-static-reachability job is responsible for running a reachability analysis on the code. This job will execute if GITLAB_STATIC_REACHABILITY_ENABLED is true. In reality though we only support python. If no python file is detected this job will just exit with 1. The job is allowed to fail. For beta we want to enable SR on for Python projects so we want the user to enable it if and only if he has python files. However, if for some reason SR is enabled on a different project we still want to continue with dependency-scanning without breaking the pipeline in any way.
• The DS latest template contains 2 DS jobs:
  • dependency-scanning: this is the previous version of DS. It will run as usual if GITLAB_STATIC_REACHABILITY_ENABLED is false.
  • dependency-scanning-with-reachability: this is the DS job that also contains the SBOM enricher with reachability data. It optionally depends on gitlab-static-reachability . This job will only execute if GITLAB_STATIC_REACHABILITY_ENABLED is true. In case gitlab-static-reachability fail there will be no report. However the job will complete the dependency scanning part of the job and just skip the SBOM enriching part.
• We also updated the SCA-to-sarif-matcher to the latest version v2.0.2 which does not require a docker image of the code built by the user. This was one of the main issues that we tried to fix in SR beta.

Below you can see how the SR is implemented in the template:

Caution

We attempted to introduce this feature in !182860 (merged) and it was reverted with !186444 (merged) due to breaking users pipelines that were overwriting the stage of dependency_scanning job. See [internal discussion]. Be aware that if a user overwrites dependency-scanning instead of the base job dependency_scanning or .ds-analyzer this will still break the pipeline. In this MR we attempted to fix this problem by making sure that all jobs inherit their stage from .ds-analyzer which extends dependency_scanning.

Important

To ensure that this change can work with Scan Execution Policies (SEP) we made dependency-scanning-with-reachability to depend optionally on both gitlab-static-reachability and gitlab-static-reachability-0. The latter is the name of the job introduced by SEP. This way we ensure that if a user enables SR on a project through SEP this will still work without ending up with dependency-scanning-with-reachability having needs:[] which would cause the job to run without respecting stage order.

Important

Another improvement point in this MR is that we tried to make sure that the dependency-scanning-with-reachability job will not end up having needs:[] in any case. For that reason we make sure that gitlab-static-reachability job can run for any kind of project (Python or not) but exits with 1 in case it is not a project with a supported language.

References

• Discuss design approaches for the future of Dep... (#521587 - closed)
• Enable Static Reachability in the latest DS tem... (#523358 - closed) • Nick Ilieskou • 17.11 • At risk
• #523358 (comment 2433019275)
• Documentation MR

Screenshots or screen recordings

Before

Before this change SR was being enabled by including the latest SAST template in combination with the DS template (latest or stable). As you can see in the image below by enabling SR the jobs that were required were:

• gemnasium-dependency_scanning for DS
• gitlab-static-reachability for running GLAS for SR
• a build job for building the docker image with the code which would be used in the .post job
• gitlab-enrich-cdx-results job which was a .post job for enriching the SBOM reports. This job was running the SCA-to-sarif-matcher in the docker image built by the build job.

Tip

Please ignore the gitlab-advanced-sast job from the picture above.

After

With this MR we only need the latest DS template to enable SR. When we do that we will get 2 jobs in the test stage:

• gitlab-static-reachability : which is GLAS for SR
• dependency-scanning-with-reachability: which runs the new DS analyzer and then the SCA-to-sarif-matcher . Notice that this job waits until gitlab-static-reachability is finished.

Tip

In the following example we also overwrite the test stage with a new value

How to set up and validate locally

1. Checkout this branch in your local GDK
2. Start your GDK
3. Create a new project with a main.py and some minimum code.
4. Create a ci file and include the Jobs/Dependency-Scanning.latest.gitlab-ci.yml
5. Set DS_ENFORCE_NEW_ANALYZER and GITLAB_STATIC_REACHABILITY_ENABLED to true
6. Run a pipeline

Sample project.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.