Introduce semantic versioning with Secure stage vendored templates
Problem to solve
There are a number of Secure features which have orchestrators: Category:SAST, ~"Category:Dependency Scanning", Category:Container Scanning, etc. These orchestrators allow us to have a great deal of flexibility and power when detecting what analyzers should be run to properly scrutinize a merge request. However, they come with a negative side effect of requiring a Docker-in-Docker approach. Docker-in-Docker is being deprecated and the detection logic has been moved to the respective feature category vendored templates.
While the move of detection logic to vendored templates is good, it currently means we're losing the ability to version our detection logic. This is a gap in our current plan as it forces customers which upgrade GitLab versions to implicitly accept changes, which will be problematic when we introduce breaking changes. This will be an impediment for customers to upgrade to newer versions.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Simone (Software Engineer in Test)
Further details
Proposal
Provide a layer of indirection within our vendored templates. Within each template:
- Introduce a configuration variable like
SAST_VERSION
. - Move all detection logic from existing vendored template to a child template named something like
SAST_v<SAST_VERSION>.gitlab-ci.yml
. - Semantically version the child templates.