Security Policy definition not respected with scheduled scan action

Why are we doing this work

There is an issue when running scheduled jobs through scan execution policy at the same time that there is a compliance framework applied to the same project.

How to reproduce

1. Create a group which will be referred as group1
2. Create a project under group1 which will be referred as project-compliance
3. Create a file under project-compliance the following name and content:
   .compliance-ci.yaml

stages:
  - pre
  - regular

a_compliance_job:
  stage: pre
  script: 
    - echo "Hallo from Compliance Team, checking if you have a Dockerfile in your repo!"
    - env

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  project: '$CI_PROJECT_PATH'
  file: '$CI_CONFIG_PATH'
  ref: '$CI_COMMIT_REF_NAME' # Must be defined or MR pipelines always use the use default branch

4. Go to group1 settings -> general -> compliance framework and enable with .compliance-ci.yaml@group1/project-compliance (if group1 is a subgroup adjust the name accordingly).
5. Create a project under group1 which will be referred as project-ci-with-compliance
6. Go to project-ci-with-compliance settings -> general -> compliance framework and select project-compliance
7. Create a file under project-ci-with-compliance with the following name and content:
   .gitlab-ci.yml

image: alpine:latest
# stage regular does not need to be defined as it has been already defined in the compliance project
regular_job:
  stage: regular
  before_script:
    - "# No before scripts."
  script:
    - echo "running regular_job"
  after_script:
    - "# No after scripts."

8. Create a file under project-ci-with-compliance with any extension supported by sast, like rb for instance.
9. Go to security&compliance -> policies and create a new scan execution policy matching the following values:

---
scan_execution_policy:
- name: CS
  description: CS with and without container in registry
  enabled: true
  rules:
  - type: schedule
    branches:
    - main
    cadence: "*/1 * * * *"
  actions:
  - scan: sast

10. After the respective background workers have been completed. The schedule pipeline will be created only the CI job regular_job and compliance job a_compliance_job as the following:

Extra steps for verification

1. Create a project under group1 which will be referred as project-ci-only
2. Create a new file under project-ci-only with the following name and content:
   .gitlab-ci.yml

image: alpine:latest

stages:
  - regular

regular_job:
  stage: regular
  before_script:
    - "# No before scripts."
  script:
    - echo "running regular_job"
  after_script:
    - "# No after scripts."

3. Create a file under project-ci-only with any extension supported by sast, like rb for instance.
4. Go to security&compliance -> policies and set the policy project to the same one used in the previous section.
5. After the respective background workers have been completed. The schedule pipeline create only the scan job sast(including its related downstream pipeline) as the following:
   

Implementation plan

• backend Update compliance so it doesn't override when either parameter or bridge are available.

  • For example a project with compliance returns Gitlab::Ci::Pipeline::Chain::Config::Content::Compliance while a project with scan execution policy returns Gitlab::Ci::Pipeline::Chain::Config::Content::Parameter and Gitlab::Ci::Pipeline::Chain::Config::Content::Bridge.
  • Those are contents used in both CE and EE versions.

• backend As only the first content is returned this logic might have to be updated

  • This is the place where the sequence of chain (including Config::Content) get used.