Reconsider the versioning of the SAST Analyzers

Problem to solve

Current release process for Security Products implies to generate a new docker image for all analyzers on each major or minor release of GitLab.

While this can eventually be automated to ease the process it still makes useless work, creates unnecessary noise and add room for potential mistakes.

Further details

An analyzer is a wrapper around a third party tool. Its update cycle is tied to changes in:

  • analyzer AKA wrapper
  • third party tool AKA upstream project
  • main SAST project and the common lib

A change may be, for instance:

  • a change in the output format of the analyzer or third party tool
  • a change in the arguments of the cli
  • a bug fix

It is likely that once implemented, the analyzer/wrapper won't change a lot. It doesn't make sense to publish a new release each month while nothing has changed.

What really matters is to ensure compatibility between the analyzer and the main SAST project:

  • when the main SAST project starts the analyzer
  • when it collects the output

Debugging should be easy. When inspecting the job in the CI, it should be easy to know the version of the wrapper, upstream project and common lib that were used to build the Docker image.

Reproducibility matters. Assuming that a customer runs an old version of the analyzer (thus an old Docker image), it should be possible for the support team to run the exact same Docker image. In other words, it's not OK to erase Docker images that have been previously published.

Old upstream versions don't matter. We simply assume that the upstream project improves over time, so we're not maintaining and building multiple Docker images corresponding to multiple upstream versions. If the upstream project introduces a major breaking change with downsides for our users, then it's likely that we fork the wrapper project.

Old minor versions of Common don't matter. Semantic versioning implies backward compatibility anyway. Onward!

Proposal

Make the versions of the analyzers tight to the versions of SAST itself, see #7139 (closed).

Consider that the common library describes the communication protocol established b/w SAST and its analyzers. The version of common is the version of the protocol itself.

Publish a Docker image whose tag reflects, in that order:

  • the version of the common lib (mandatory)
  • the version of the upstream project (optional)
  • the version/iteration of the wrapper (optional)

It's not important that the tag reflects all these versions as long as there's a way to retrieve these informations from the log or from the command line (running a version subcommand).

If we can't create a tag with all these versions, then we may simply publish a Docker image whose tag reflects the MAJOR of the common lib (MAJOR number of the version) and that is unique to make sure there's no collision (using commit id or ISO date).

Then tag the Docker image with the MAJOR of the common lib and push that image, possibly overriding the existing one.

SAST will fetch the MAJOR-tagged images of the analyzers. It will fetch the latest compatible version of each analyzer.

How to migrate

It's all about configuring the CI in order to build and tag the Docker images following the new versioning scheme.

The migration won't impact the users. See #7139 (closed)

What does success look like, and how can we measure that?

Analyzers follow a clean versioning and we're able to release them seamlessly.

Edited by Fabien Catteau