Skip to content

Security policy approvals do not update when pipeline re-runs and finds no new findings

Summary

  • If a scan runs for an MR and returns no new findings, but is re-run and returns new findings, the MR approval rules update the MR to require approvals
  • If a scan is run for an MR and returns new findings (MR approvals required), but is re-run and returns no findings, the required approvals stay in place (expected: they would be removed). If a new commit is pushed, the approvals are removed upon pipeline completion.

Are we re-evaluating pipeline scan results against MR approval rules when jobs are re-run, or only in certain circumstances?

This is with a 3rd party scanner, and they're resolving a vulnerability externally so that it no longer shows up in the scan job's security report (or at least that's my understanding).

Steps to reproduce

  1. Get 2 secret detection report artifacts: one with no detected secrets, one with detected secrets
  2. Put them to a new project that has a security policy requiring approval on any new vulnerability
  3. In that repo, create a CI job definition that produces a secret detection report. Depending on the CI_RUNNER_ID, copy one of the reports from #1 (closed) to the appropriate report name
  4. Open an MR and run a pipeline on a runner that triggers a "with detected secrets" report. MR requires approval
  5. Pause that runner and re-run the same job. Now the MR shows no vulnerabilities detected, however approvals are still required. The pipeline security tab shows no new vulnerabilities, but it also still shows that there is a secret detection report artifact with a new finding

CI job for reference:

build:
  stage: build
  script: echo "Build done"

secret-detection:
  stage: test
  script: 
    - |
      echo Runner ID: $CI_RUNNER_ID
      if [[ $CI_RUNNER_ID == "9" ]]; then
        echo Returning no new findings
        cp gl-secret-detection-report-no-secrets.json gl-secret-detection-report.json
      else
        echo Returning new findings
        cp gl-secret-detection-report-with-secrets.json gl-secret-detection-report.json
      fi
  artifacts:
    access: 'developer'
    reports:
      secret_detection: gl-secret-detection-report.json

Example Project

What is the current bug behavior?

When violations are removed and the pipeline re-runs, approvals are not updated to 0.

What is the expected correct behavior?

When violations are removed and the pipeline re-runs, approvals should be updated as there are no remaining violations.

Relevant logs and/or screenshots

image.png

image.png

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

Verification Steps

  • Create a public project (report-project) and add gl-container-scanning-report.json that has 0 vulnerabilities
Report without vulnerabilities 
{
    "vulnerabilities": [
    ],
    "remediations": [],
    "scan": {
        "scanner": {
            "id": "trivy",
            "name": "Trivy",
            "url": "https://github.com/aquasecurity/trivy/",
            "vendor": {
                "name": "GitLab"
            },
            "version": "0.56.2"
        },
        "analyzer": {
            "id": "gcs",
            "name": "GitLab Container Scanning",
            "vendor": {
                "name": "GitLab"
            },
            "version": "7.3.11"
        },
        "type": "container_scanning",
        "start_time": "2024-11-13T19:23:59",
        "end_time": "2024-11-13T19:24:06",
        "status": "success"
    },
    "version": "15.1.1"
}
  • Create another public project (target-project) with .gitlab-ci.yml that reads the report from the first project:
variables:
  GIT_STRATEGY: none

container_scanning:
  image: "busybox:latest"
  stage: test
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
    paths: [gl-container-scanning-report.json]
  dependencies: []
  script:
    - wget -O gl-container-scanning-report.json <first project url>/-/raw/main/gl-container-scanning-report.json
  • Enable use_latest_security_scans_for_security_policies feature flag for the project
  • Create a MR approval policy in target-project to require approval on newly detected vulnerabilities
Policy 
type: approval_policy
name: Newly introduced vuln
description: ''
enabled: true
rules:
  - type: scan_finding
    scanners: []
    vulnerabilities_allowed: 0
    severity_levels: []
    vulnerability_states: []
    branch_type: protected
actions:
  - type: require_approval
    approvals_required: 1
    role_approvers:
      - developer
  - type: send_bot_message
    enabled: true
approval_settings:
  block_branch_modification: false
  prevent_pushing_and_force_pushing: false
  prevent_approval_by_author: false
  prevent_approval_by_commit_author: false
  remove_approvals_with_new_commit: false
  require_password_to_approve: false
fallback_behavior:
  fail: open
  • Update the report in report-project with vulnerabilities:
Report with vulnerabilities ```json { "vulnerabilities": [ { "id": "dc8b383b295c777c8f9ff44cd2ceb2475b29a347", "severity": "Critical", "location": { "dependency": { "package": { "name": "apache2" }, "version": "2.4.25-3+deb9u5" }, "operating_system": "debian 9.5", "image": "vulnerables/web-dvwa" }, "identifiers": [ { "type": "cve", "name": "CVE-2019-10082", "value": "CVE-2019-10082", "url": "https://access.redhat.com/security/cve/CVE-2019-10082" } ], "links": [ { "url": "https://access.redhat.com/security/cve/CVE-2019-10082" }, { "url": "https://errata.almalinux.org/8/ALSA-2020-4751.html" }, { "url": "https://httpd.apache.org/security/vulnerabilities_24.html" }, { "url": "https://linux.oracle.com/errata/ELSA-2020-4751.html" }, { "url": "https://lists.apache.org/thread.html/r03ee478b3dda3e381fd6189366fa7af97c980d2f602846eef935277d%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r06f0d87ebb6d59ed8379633f36f72f5b1f79cadfda72ede0830b42cf%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r3c5c3104813c1c5508b55564b66546933079250a46ce50eee90b2e36%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r76142b8c5119df2178be7c2dba88fde552eedeec37ea993dfce68d1d%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/rc998b18880df98bafaade071346690c2bc1444adaa1a1ea464b93f0a%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/rd18c3c43602e66f9cdcf09f1de233804975b9572b0456cc582390b6f%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/rd2fb621142e7fa187cfe12d7137bf66e7234abcbbcd800074c84a538%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/re3d27b6250aa8548b8845d314bb8a350b3df326cacbbfdfe4d455234%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10082" }, { "url": "https://ubuntu.com/security/notices/USN-4113-1" }, { "url": "https://www.cve.org/CVERecord?id=CVE-2019-10082" }, { "url": "https://www.openwall.com/lists/oss-security/2019/08/15/3" }, { "url": "https://www.oracle.com/security-alerts/cpuapr2020.html" }, { "url": "https://www.oracle.com/security-alerts/cpujul2020.html" }, { "url": "https://www.oracle.com/security-alerts/cpujul2022.html" }, { "url": "https://www.oracle.com/security-alerts/cpuoct2021.html" }, { "url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html" } ], "details": { "vulnerable_package": { "name": "Vulnerable Package", "type": "text", "value": "apache2:2.4.25-3+deb9u5" }, "vendor_status": { "name": "Vendor Status", "type": "text", "value": "fixed" } }, "description": "In Apache HTTP Server 2.4.18-2.4.39, using fuzzed network input, the http/2 session handling could be made to read memory after being freed, during connection shutdown.", "solution": "Upgrade apache2 to 2.4.25-3+deb9u8" }, { "id": "d4d88701a58794ec89d236051db4557e24b5fcd4", "severity": "Critical", "location": { "dependency": { "package": { "name": "apache2" }, "version": "2.4.25-3+deb9u5" }, "operating_system": "debian 9.5", "image": "vulnerables/web-dvwa" }, "identifiers": [ { "type": "cve", "name": "CVE-2021-26691", "value": "CVE-2021-26691", "url": "http://httpd.apache.org/security/vulnerabilities_24.html" } ], "links": [ { "url": "http://httpd.apache.org/security/vulnerabilities_24.html" }, { "url": "http://www.openwall.com/lists/oss-security/2021/06/10/7" }, { "url": "https://access.redhat.com/security/cve/CVE-2021-26691" }, { "url": "https://errata.almalinux.org/8/ALSA-2021-3816.html" }, { "url": "https://httpd.apache.org/security/vulnerabilities_24.html" }, { "url": "https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-26691" }, { "url": "https://linux.oracle.com/errata/ELSA-2022-0143.html" }, { "url": "https://lists.apache.org/thread.html/r50cae1b71f1e7421069036b213c26da7d8f47dd59874e3bd956959fe%40%3Cannounce.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r50cae1b71f1e7421069036b213c26da7d8f47dd59874e3bd956959fe@%3Cannounce.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r7f2b70b621651548f4b6f027552f1dd91705d7111bb5d15cda0a68dd%40%3Cdev.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/re026d3da9d7824bd93b9f871c0fdda978d960c7e62d8c43cba8d0bf3%40%3Ccvs.httpd.apache.org%3E" }, { "url": "https://lists.debian.org/debian-lts-announce/2021/07/msg00006.html" }, { "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SPBR6WUYBJNACHKE65SPL7TJOHX7RHWD/" }, { "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZNCYSR3BXT36FFF4XTCPL3HDQK4VP45R/" }, { "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26691" }, { "url": "https://security.gentoo.org/glsa/202107-38" }, { "url": "https://security.netapp.com/advisory/ntap-20210702-0001/" }, { "url": "https://ubuntu.com/security/notices/USN-4994-1" }, { "url": "https://ubuntu.com/security/notices/USN-4994-2" }, { "url": "https://www.cve.org/CVERecord?id=CVE-2021-26691" }, { "url": "https://www.debian.org/security/2021/dsa-4937" }, { "url": "https://www.oracle.com/security-alerts/cpujan2022.html" }, { "url": "https://www.oracle.com/security-alerts/cpuoct2021.html" } ], "details": { "vulnerable_package": { "name": "Vulnerable Package", "type": "text", "value": "apache2:2.4.25-3+deb9u5" }, "vendor_status": { "name": "Vendor Status", "type": "text", "value": "fixed" } }, "description": "In Apache HTTP Server versions 2.4.0 to 2.4.46 a specially crafted SessionHeader sent by an origin server could cause a heap overflow", "solution": "Upgrade apache2 to 2.4.25-3+deb9u10" }, { "id": "edebb32d993601bdea5d9fbf54c19c33b9904350", "severity": "Critical", "location": { "dependency": { "package": { "name": "apache2" }, "version": "2.4.25-3+deb9u5" }, "operating_system": "debian 9.5", "image": "vulnerables/web-dvwa" }, "identifiers": [ { "type": "cve", "name": "CVE-2021-39275", "value": "CVE-2021-39275", "url": "https://access.redhat.com/security/cve/CVE-2021-39275" } ], "links": [ { "url": "https://access.redhat.com/security/cve/CVE-2021-39275" }, { "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-685781.pdf" }, { "url": "https://errata.almalinux.org/8/ALSA-2022-0891.html" }, { "url": "https://httpd.apache.org/security/vulnerabilities_24.html" }, { "url": "https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-39275" }, { "url": "https://linux.oracle.com/errata/ELSA-2022-0891.html" }, { "url": "https://lists.apache.org/thread.html/r3925e167d5eb1c75def3750c155d753064e1d34a143028bb32910432%40%3Cusers.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r61fdbfc26ab170f4e6492ef3bd5197c20b862ce156e9d5a54d4b899c%40%3Cusers.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r82838efc5fa6fc4c73986399c9b71573589f78b31846aff5bd9b1697%40%3Cusers.httpd.apache.org%3E" }, { "url": "https://lists.apache.org/thread.html/r82c077663f9759c7df5a6656f925b3ee4f55fcd33c889ba7cd687029%40%3Cusers.httpd.apache.org%3E" }, { "url": "https://lists.debian.org/debian-lts-announce/2021/10/msg00001.html" }, { "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SPBR6WUYBJNACHKE65SPL7TJOHX7RHWD/" }, { "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZNCYSR3BXT36FFF4XTCPL3HDQK4VP45R/" }, { "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39275" }, { "url": "https://security.gentoo.org/glsa/202208-20" }, { "url": "https://security.netapp.com/advisory/ntap-20211008-0004/" }, { "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-httpd-2.4.49-VWL69sWQ" }, { "url": "https://ubuntu.com/security/notices/USN-5090-1" }, { "url": "https://ubuntu.com/security/notices/USN-5090-2" }, { "url": "https://www.cve.org/CVERecord?id=CVE-2021-39275" }, { "url": "https://www.debian.org/security/2021/dsa-4982" }, { "url": "https://www.oracle.com/security-alerts/cpuapr2022.html" }, { "url": "https://www.oracle.com/security-alerts/cpujan2022.html" } ], "details": { "vulnerable_package": { "name": "Vulnerable Package", "type": "text", "value": "apache2:2.4.25-3+deb9u5" }, "vendor_status": { "name": "Vendor Status", "type": "text", "value": "fixed" } }, "description": "ap_escape_quotes() may write beyond the end of a buffer when given malicious input. No included modules pass untrusted data to these functions, but third-party / external modules may. This issue affects Apache HTTP Server 2.4.48 and earlier.", "solution": "Upgrade apache2 to 2.4.25-3+deb9u11" } ], "remediations": [], "scan": { "scanner": { "id": "trivy", "name": "Trivy", "url": "https://github.com/aquasecurity/trivy/", "vendor": { "name": "GitLab" }, "version": "0.56.2" }, "analyzer": { "id": "gcs", "name": "GitLab Container Scanning", "vendor": { "name": "GitLab" }, "version": "7.3.11" }, "type": "container_scanning", "start_time": "2024-11-13T19:23:59", "end_time": "2024-11-13T19:24:06", "status": "success" }, "version": "15.1.1" } ```
  • Create a MR that updates the README in the target-project and verify that the approval is required as the MR introduces 2 new vulnerabilities
  • Now update the report in the report-project with Report without vulnerabilities
  • Re-run the container_scanning job in the MR and verify that the approval is not required as the latest job does not have any new vulnerabilities
Edited by Sashi Kumar Kumaresan