Identify Security jobs in the pipeline
Open source projects get Gold features for free. Yet, security features are not enabled by default, and sometimes a bit tedious to setup. We should make the adoption of these features as easy as possible. Security should never be optional.
If we are able to identify them, we could:
- Run only them (and their depending jobs) when needed (https://gitlab.com/gitlab-org/gitlab-ee/issues/4913). This would prevent to run the whole pipeline when the branching commit has outdated reports, and prevent to deploy things if CD is enabled.
- Run security jobs without burning the minutes budget of our users.
- Enforce Secret Detection at the instance level. The more I think about it, the more I think we should split secrets from SAST @andyvolpe (following our discussion). That way, we could move all basic Secrets features to Core, and keep the other features in Ultimate for a bit longer. Users could always disable the job if needed, but by default, it's enabled for ALL projects.
- Run only them from our WebIDE
- Detect if projects are using or not security checks, and display this info in the dashboard. https://gitlab.com/gitlab-org/gitlab-ee/issues/7521 might make this useless, as the last run is also a good metric.
Security jobs are identified by an artifacts:reports:{sast | dast | ...}
entry in their job options.
CI configuration. Unfortunately, obtaining the current CI configuration is hard:
- Parsing the CI configuration can take longer than 30 seconds. This is because external templates can be referenced, and the external site may be slow
- Parsing the
.gitlab-ci.yml
isn't enough to determine whether or not Secure jobs are configured. The environment is also required, otherwise variables such asSAST_DISABLED
won't be taken into consideration. - A pipeline could be created, then reverted. Doing this in a transaction would create unwanted locks on the Database, doing it in memory alone is still an expensive tasks (5-30 seconds for pipelines with many jobs)
Proposal
Secure jobs can be found in a pipeline by searching for jobs with artifacts:reports:{sast | dast | ...}
in their job options. This allows us to find Secure jobs that have previously run.
To find out whether Secure jobs will run in future pipelines, the latest run (or running) project pipeline will be used to search for jobs with artifacts:reports:{sast | dast | ...}
in their job options. For the majority of cases, this will work:
- Most projects have a pipeline if they have CI configured
- If a change is made to the
.gitlab-ci.yml
, a new pipeline is triggered. A running / pending pipeline is enough to be able to query for Secure jobs.
There are known cases where this does not work:
- Importing a project by URL does not trigger a pipeline.
While not an ideal solution to determining if Secure jobs will run in future pipelines, building this will unblock other features. Each of these features will be required to deal with the case where no pipeline has ever been run. A new issue has been created #33982 to determine if Secure jobs will run in future based on configuration alone.
/cc @gl-secure for thoughts