feat: .trivyignore allow import / export from / to project via gitlab API

[childnode]

getting a .trivyignore generated is cool but what about the cases

I already have a .trivyignore file and I want to

• filter the findings dependend on this ignore list
• find which ignores can be removed
• merge back the new ignore file

I can think of getting s.th. like:

1. a load from project button predefined (project HTTPS URL is given, PAT can be used)
2. paste a ignore file I actually have
3. with 1): hit a button to jump back to the single file editor on gitlab with the changed file content
   btw. yes it's that easy to add &content=test1%0Atest2 to the ${GITLAB_PROJECT_URL}/-/edit/main/.trivyignore?ref_type=heads&content=test1%0Atest2 resp. creating it by /-/new/main?file_name=.trivyignore&content=test

[Morl99]

Thanks @childnode for your input. In order to use the features you described it would be necessary to run a trivy scan without the .trivyignore file. Do I understand correctly, that you are trying to target the use case to have a clutter free .trivyignore file in your repository?

Actually in our team we have this partially automated. We run a full scan (without the .trivyignore) and compare the results with the real scan (with the .trivyignore). We then compare the results and output the list of CVEs that can be removed. Here is a code snippet that achieves that. The trivy-results.json contains the results of the full scan (without the ignore file) and the .trivyignore.orig is the file that is committed to the repository.

      export FOUND_CVES=$(cat trivy-results.json | jq -r -c '.Results[]|objects| select ( .Vulnerabilities != null) | .Vulnerabilities[].VulnerabilityID')
      export IGNORED_CVES=$(cat .trivyignore.orig | grep -v "^#")
      for OLDCVE in $(echo ${IGNORED_CVES})
      do
        echo ${FOUND_CVES} | grep -q ${OLDCVE}
        ERROR=$?
        if [ ${ERROR} -ne 0 ]
        then
          echo ${OLDCVE}
          export EXIT_CODE=1
        fi
      done
      exit ${EXIT_CODE}

I am not yet sure if I think it is worth to include such a feature in the UI, as the resulting process is kind of tedious. One thing that is missing in any case is the preservation of comments. We use comments in the file to explain WHY a finding is ignored, and if we would want to implement a roundtrip of the trivyignore file, these comments have to be preserved. Do you have any thoughts on that?