Gitlab and Trivy

Currently trying to get dependency_scanning with Trivy and Gitlab working (free self hosted version v17.0.1). While the scanning works fine like that in the pipeline:

vulnerability-scan:
  image: aquasec/trivy:latest
  stage: vulnerability-scan
  script:
    - trivy fs --scanners vuln --severity HIGH,CRITICAL --format template --template "@/contrib/gitlab.tpl" Gemfile.lock --output gitlab_trivy_gemfile_report.json
  artifacts:
    when: always
    reports:
      dependency_scanning: gitlab_trivy_gemfile_report.json
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: always

and while the gitlab_trivy_gemfile_report.json file can be downloaded within the Gitlab merge request once the scan is over, I do not see any graphical results in Gitlab Merge request itself like the vulnerablity report. Is my command wrong? Do I need to add something more? I thought using the correct template, as I do, would actually do the trick, but something is still missing.

best
Martin

The MR widget should say Security scans have run, or if you are using the Ultimate tier, it will parse the reports artifact and render a summary of the scan results.

hi @dnsmichi OK Thanks for the hint. I’m on the free version so as you say this MR widget sold show me at least Security scans have run but it seems that is not the case, see screenshot attached. Do I have to activate something else then what I have in the Pipeline to see this widget?

Screenshot from 2024-06-10 20-36-161462×640 71.4 KB

Untested but you could try rename the reports file to how GitLab expects it.

hi @dnsmichi

I now changed it like this:

vulnerability-scan:
  image: aquasec/trivy:latest
  stage: vulnerability-scan
  script:
    - trivy fs --scanners vuln --severity HIGH,CRITICAL --format template --template "@/contrib/gitlab.tpl" Gemfile.lock --output gl-dependency-scanning-report.json
    # Print the trivy report as table (can be removed once we get the report in the MR widget)
    - trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 --format table Gemfile.lock
  artifacts:
    when: always
    reports:
      dependency_scanning: gl-dependency-scanning-report.json
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: always

but unfortunately the graphic is still not showing up. Open for ideas

Maybe there is no report artifact file created?

The following modified snippet should report the JSON file as job artifact to download and inspect.

It will have the same effect as what you are trying to achieve, but in a different download location. Parsing the JSON file and, for example, creating a markdown table as MR comment, will be a manual or custom script task. An older example implementation can be found in Fantastic Infrastructure as Code security attacks and how to find them

Hi @dnsmichi

sorry for the late reply. Actually the file is there:

Screenshot from 2024-06-13 21-01-041474×639 73.6 KB

and the File downloaded looks like this:

{
  "version": "15.0.7",
  "scan": {
    "analyzer": {
      "id": "trivy",
      "name": "Trivy",
      "vendor": {
        "name": "Aqua Security"
      },
      "version": "0.52.1"
    },
    "end_time": "2024-06-13T18:36:02",
    "scanner": {
      "id": "trivy",
      "name": "Trivy",
      "url": "https://github.com/aquasecurity/trivy/",
      "vendor": {
        "name": "Aqua Security"
      },
      "version": "0.52.1"
    },
    "start_time": "2024-06-13T18:36:02",
    "status": "success",
    "type": "container_scanning"
  },
  "vulnerabilities": [
    {
      "id": "CVE-2024-27456",
      "name": "rack-cors: Insecure File Permissions in rack-cors",
      "description": "rack-cors (aka Rack CORS Middleware) 2.0.1 has 0666 permissions for the .rb files.",
      "severity": "High",
      "solution": "Upgrade rack-cors to >= 2.0.2",
      "location": {
        "dependency": {
          "package": {
            "name": "rack-cors"
          },
          "version": "2.0.1"
        },
        "operating_system": "Unknown",
        "image": "Gemfile.lock"
      },
      "identifiers": [
        {
          "type": "cve",
          "name": "CVE-2024-27456",
          "value": "CVE-2024-27456",
          "url": "https://avd.aquasec.com/nvd/cve-2024-27456"
        }
      ],
      "links": [{
          "url": "https://access.redhat.com/security/cve/CVE-2024-27456"
        },{
          "url": "https://github.com/advisories/GHSA-785g-282q-pwvx"
        },{
          "url": "https://github.com/cyu/rack-cors"
        },{
          "url": "https://github.com/cyu/rack-cors/blob/878063987bd1ca956282dda95697fd821bf24d2e/CHANGELOG.md#changed"
        },{
          "url": "https://github.com/cyu/rack-cors/issues/274"
        },{
          "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack-cors/CVE-2024-27456.yml"
        },{
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27456"
        },{
          "url": "https://www.cve.org/CVERecord?id=CVE-2024-27456"
        }
      ]
    }
  ],
  "remediations": []
}

So imho this looks correct or?

Let me also check your alternative version. However I might only be able to test this one next week!

Best
Martin