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.