Skip to content

Compliance pipelines do not expand `.extends` blocks before including developer pipelines

Summary

I'm not able to create a Compliance Pipeline that enforces running auto-SAST. Auto-SAST is significant because it supports scanning any repo in the group regardless of the programming language used. I have set up what I think should work but think I have encountered a corner case where the rules to enforce the auto-SAST job rules:when:always in the Compliance Pipeline conflict with the rules used by the auto-SAST template rules:if:when:never that determine which scanner to run for a given language. A sast: job in the developer project pipeline will override the sast: job from the compliance pipeline.

Steps to reproduce

  1. Create a compliance pipeline in a project in a group following docs at https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration that includes the auto-SAST template (this is where I'm stuck)
  2. Create a Compliance Framework at the group level that uses Compliance Pipeline following the docs at https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-frameworks
  3. Apply the Compliance Framework to a project in the group
  4. In the project create a CI pipeline that includes a build job (the example below uses include:template:Auto-DevOps.gitlab-ci.yml as well as a sast: job.
  5. Set the sast: job to have a script:block that does effectively nothing (e.g.echoortrue`)

Example Project

Compliance Pipeline in project https://gitlab.com/midwest-apps/compliance-frameworks/common-sense Compliance Framework in group: Common Sense::Security in group https://gitlab.com/midwest-apps Developer Project: https://gitlab.com/midwest-apps/sg-spring

What is the current bug behavior?

Compliance pipelines do not expand .extends blocks before including developer pipelines

A sast: job in the developer project pipeline will override the sast: job from the compliance pipeline.

What is the expected correct behavior?

Compliance pipelines do expand .extends blocks before including developer pipelines

The sast: job in the developer project will be ignored or cause an error

Relevant logs and/or screenshots

Job out put from sast job in developer project:

.  
.  
.  
Executing "step_script" stage of the job script 00:01
Using docker image sha256:520b8437b29fc3e63f47e7cce9a596554470cd9da8a1149428ae2be97aa7ff67 for registry.gitlab.com/gitlab-org/security-products/analyzers/spotbugs:2 with digest registry.gitlab.com/gitlab-org/security-products/analyzers/spotbugs@sha256:e394e48d4b542407dcc609b096c0c53bc4582c7f6fbaff775651f72a01f4401a ...
$ echo "Overriding SAST job script"
Overriding SAST job script
$ echo "CI_CONFIG_PATH is " $CI_CONFIG_PATH
CI_CONFIG_PATH is  .gitlab-ci.yml
$ echo "CI_COMMIT_BRANCH is " $CI_COMMIT_BRANCH
CI_COMMIT_BRANCH is  master
$ echo "$CI_COMMIT_REF_NAME is " $CI_COMMIT_REF_NAME
master is  master
Uploading artifacts for successful job
.  
.  
.

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Make compliance pipelines expand .extends block as part of the immutable content of the pipeline. Do not allow it to be overridden by the included files.

Edited by Sam Kerr