Trigger depSASTer downstream when Gemfile.checksum changes

What does this MR do and why?

AppSec are asked to review new & updated dependencies: https://docs.gitlab.com/ee/development/gemfile.html#request-an-appsec-review

New gems add an extra security risk for GitLab, and it is important to evaluate this risk before we ship this to production

Currently we look at the diff, manually review the changes on best-efforts basis, look at how popular the gem is, etc. But we have SAST tools so why not use them!

I have been working on automation around this, and created depSASTer: https://gitlab.com/gitlab-com/gl-security/appsec/tooling/depsaster. Read the README to understand how it works.

This will increase efficiency:

• Contributors (who are team members) can self-review the SAST results
• AppSec can review the SAST results if needed

Screenshots or screen recordings

From gitlab-org/gitlab's perspective, it uses the Downstream Pipeline Multi-project CI/CD pattern. Here's a test project emulating that:

The depSASTer will be triggered, and it runs async. Once it's done the MR is updated with something like the following:

Src: https://gitlab.com/gitlab-com/gl-security/appsec/tooling/depsaster-test-project/-/merge_requests/3#note_1433354557

More examples

Here are two more examples, but they were manually triggered. When this MR is merged, these are the types of comments that will be posted automatically.

• !123144 (comment 1426378540)
• !115754 (comment 1406666629)

Rollout

• Merge this MR
• Have a maintainer add the CI variable ENABLE_DEPSASTER with the value true

Risks

• Breaking master pipelines
  • Prevent:
    • have someone with great CI/CD knowledge review this MR
    • the pipeline is allowed to fail
  • Response if it happens anyway:
    • remove ENABLE_DEPSASTER or set it to not true
    • revert this MR
• It runs on forks, wasting CI/CD time
  • Prevent: Not sure??
  • Response if it happens anyway: The pipeline will trigger, but depSASTer will ignore it when it checks the project ID. https://gitlab.com/gitlab-com/gl-security/appsec/tooling/depsaster/-/blob/main/lib/mr_handler.rb#L6-9. Additionally, the bot needs to have permission to read & comment.

How to set up and validate locally

I created a test project which uses very similar CI yml, but obviously gitlab-org/gitlab is wayyyy more complex.

https://gitlab.com/gitlab-com/gl-security/appsec/tooling/depsaster-test-project/-/blob/main/.gitlab-ci.yml

• Visit https://gitlab.com/gitlab-com/gl-security/appsec/tooling/depsaster-test-project/
• Change rubygems/Gemfile.checksum (either clone and do a proper bundler change, or just add some whitespace in the web IDE)
• Open an MR

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.