Proposal: Automate SAST Analyzers Monthly Updates

What is the problem we are trying to solve?

Every month groupstatic analysis team performs a routine check to see if all the SAST analyzers(over a dozen) are up to date with their dependencies. Here is an example issue: https://gitlab.com/gitlab-org/security-products/release/-/issues/122+. Although this process is mundane yet necessary, taking ~15min per analyzer * 17 analyzers == ~4.25 hours of the team every month.

What are the usual set of steps involved in updating a SAST Analyzer?

  • Check for minor/patch version upgrades of the analyzer repository dependencies. If available, update the repository.
  • Check for underlying OSS scanner's new version upgrades. If available, update the version in the repository's Dockerfile(s).
  • Pull all the version upgrades made and add them in the CHANGELOG.md. Bump the version in the Changelog and push the changes to remote.
  • Create a Merge Request with GitLab template containing
    • All the dependencies that are updated in the Issue description
    • Link the Planning Issue under Relevant Issue Numbers
    • All the labels
  • Once MR is created, append Merge Request ID to all the recent entries in the CHANGELOG.md. Push changes again to the remote.
  • Check the Vulnerability Report for any vulnerabilities introduced with new changes.

Potential Solutions

  • Dependabot
    • Pros: Dependency updates are determined flawlessly.
    • Cons: Not a complete solution as dependency updates are just part of our process. Raises MR per dependency library. Manual intervention would be as effortful as without using it.
  • Renovate:
    • Pros: Dependency updates are determined flawlessly. Exhaustive set of features in terms of customizations.
    • Cons: Not a complete solution as dependency updates are just part of our process. Manual intervention would be as effortful as without using it.
  • Custom Solution:
    • Pros: Capable of providing a complete solution by replicating the exact process except Vulnerabilities check.
    • Cons: Engineering effort.

Both bots do not allow us to intercept at any stage to add our logic before they raise MR so that adds to a big limitation.

Final Solution: Custom Soltuion

Going with our own custom solution would help in tuning the code as per our current process and any future changes. Since all our analyzers are written in Go so we have to retrieve dependencies only for gomod ecosystem. The rest of the process steps can be achieved relatively easily.

I have built a POC on the above custom solution, primarily for SAST analyzers at the moment. Repository link: https://gitlab.com/vbhat161/analyzer-dependabot. More about this in the README.md file.

How it looks

Sample MR: https://gitlab.com/vbhat161/semgrep-forked/-/merge_requests/7 (Labels and Milestone aren't properly in place due to non-gitlab-org repo)

How it works

We make use of GitLab Job Schedules(CI > Schedules) in the analyzer-dependabot repository where we schedule a CRON Job for each analyzer on a Monthly-basis. I've already added schedules for some analyzers in the given repository.

SAST Analyzer compatibility

As per what I've tested using dry-run, the POC works for all the analyzers except sobelow. More information about this is in README.md.

Problem identification checklist

  • The root cause of the problem is identified.
  • The surface of the problem is as small as possible.

What are the potential solutions?

  • All potential solutions are listed.
  • A solution has been chosen for the first iteration: Custom Solution

Verify that the solution has improved the situation

TBA

Edited by Vishwa Bhat