Skip to content

Legacy sast, dependency_scanning job triggered when rules are set

Summary

In projects where the CI config overrides the definition of sast and forces the rules, the legacy Docker-in-Docker orchestrator is triggered even though SAST_DIND_DISABLED is not set (default value is now true). The pipeline ends up having the legacy DinD orchestrator and the new scanning jobs running in parallel. Also, the rules are not applied to the new scanning jobs. Same goes with Dependency Scanning.

When SAST and Dependency Scanning (DS) used to run in a single job, users could easily override the job definition of sast and dependency_scanning, and change the conditions on which the scanning jobs are triggered. With the removal of the Docker-in-Docker (DinD) orchestrator and non-DinD becoming the default, users now have to override multiple scanning jobs. See #218444

Bug information (click to expand)

Steps to reproduce

  • create a project w/ a CI config that includes the SAST template
  • in the CI config, override the job definition of sast and disable the job using rules

Same with the Dependency Scanning template and the dependency_scanning job.

This CI configuration used to work prior to making no-DinD a default.

Example Project

https://gitlab.com/gitlab-org/release-tools/pipelines/147562588

See release-tools@cfdc0901

What is the current bug behavior?

There's a legacy sast job (DinD orchestrator).

What is the expected correct behavior?

There should only be a brakeman-sast job, assuming the project is compatible with Brakeman (actually it's not, but this is another issue).

Relevant logs and/or screenshots

See pipeline.

Implementation plan

Update user documentation:

  1. Create a new section in the Application Security page to document the steps needed when using a stage other than the default test stage

  2. Change the Getting error message sast job: stage parameter should be... error in the main application security page to make it more generic so it applies to all the security jobs, and move it from being nested in the troubleshooting section to the new section created in 1. above.

  3. Click for previous details

    Add another sub-section to the Troubleshooting section of the Application Security docs to explain that for SAST and Dependency Scanning, there are old jobs which remain for backwards compatibility reasons, and if the sast or dependency_scanning jobs are overridden with custom rules, then this will result in a legacy sast or dependency_scanning job being run, which will fail with the following text in the CI job log:

    sast is used for configuration only, and its script should not be executed

    We need to emphasize that these jobs must not run, so they can be used to configure a lot of things that apply to all "real" jobs, but not the rules property (as we need that one to stay with never value).

    We should also include that this behaviour will eventually be fixed by Improve extendability of SAST, Dependency Scanning template rules

    This step is no longer necessary, since it's been addressed in Explain new sast / dependency_scanning error that was introduced in 13.4 .

Issues with possible fix above

our linting makes the proposed documentation complex

Is there a way to modify the linting so this is a more simple fix if one follows our proposed documentation?

/cc @nolith @theoretick @twoodham

Edited by Adam Cohen