Trivy Config ignored in latest version

[Frituurpanda]

We are currently running Trivy with the latest version:

name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55 #0.19.0
with:
  image-ref: '$ref'
  scan-type: 'image'
  scan-ref: '.'
  severity: "HIGH,CRITICAL"
  scanners: "vuln,config"
  vuln-type: 'library'
  format: 'sarif'
  exit-code: '0'
  output: 'trivy-results.sarif'

Subsequent uploading works perfectly fine with:

name: Upload Trivy scan results to GitHub Security tab
uses: github/codeql-action/upload-sarif@v2
with:
  sarif_file: 'trivy-results.sarif'

And want to start using Trivy in more actions, thus looking at using Trivy with a config file. When we take this exact set, and place it in a .trivy.yml at the root of our repository:

severity: HIGH,CRITICAL
scanners: vuln,config
vuln-type: library
format: sarif
exit-code: 0
output: trivy-results.sarif
ignore-unfixed: false
list-all-pkgs: false

And modifying the action to use trivy-config:

name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55 #0.19.0
with:
  image-ref: '$ref'
  scan-type: 'image'
  scan-ref: '.'
  trivy-config: '.trivy.yml'

fails as the action reports that:

INFO    Secret scanning is enabled

and that should not be the case, as with our previous version. The upload also fails the output does not exist: Path does not exist: trivy-results.sarif

Anything we can do here to resolve this issue? Happy to test and provide more data.

[simar7]

Dupe of https://github.com/aquasecurity/trivy-action/issues/308

Please see the comment here https://github.com/aquasecurity/trivy-action/issues/308#issuecomment-1999710938

[Frituurpanda]

Hey @simar7 - Thanks for looking into this, I don't think this is a dupe. Did some additional testing to show you why. In #308 you mentioned:

The action runs in a docker container and your repository is used as a working directory, so you must specify the path to a configuration file relative to your project, i.e. .trivy.yaml. And we have tried both as Kieran tried in his version:

- name: Cat trivy config with workspace
run: cat ${{ github.workspace }}/.trivy.yaml
- name: Cat trivy config w/o workspace
run: cat .trivy.yaml

Both resulting in the same output:

Run cat .trivy.yaml
severity: HIGH,CRITICAL
...

Given that we know where .trivy.yaml is, we tried both injecting a relative path and absolute path:

      - name: Cat trivy config w/o workspace
        run: cat .trivy.yaml #succeeds
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55 #0.19.0
        with:
          image-ref: '$ref'
          scan-type: 'image'
          trivy-config: '${{ github.workspace }}/.trivy.yaml' 

and

      - name: Cat trivy config w/o workspace
        run: cat .trivy.yaml #succeeds
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55 #0.19.0
        with:
          image-ref: '$ref'
          scan-type: 'image'
          trivy-config: '.trivy.yaml' 

And wtih both cases, in our action, observe that the trivy.yaml file is fully ignored:

Run aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55
  with:
    image-ref: ***
    scan-type: image
    trivy-config:/home/runner/work/our-org/our-repo/.trivy.yaml
    severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL # these should only contain high, critical

Repo structure is currently as follows:

.
├── .github
│   ├── CODEOWNERS
│   └── workflows
│       └── trivy-action.yaml
└── .trivy.yaml

[simar7]

@Frituurpanda thanks for the explanation. @afdesk could you take a look? thank you!

[afdesk]

@simar7 yes, sure. I'll take a look at this issue today

[afdesk]

Hi @Frituurpanda feel free to correct me if i miss something.

Now there is a problem with using Trivy config file:

If trivy-config is set, can't other options be set? https://github.com/aquasecurity/trivy-action/issues/337#issuecomment-2060463944

it's a known issue and will be fixed soon.

But I can see another moment here:

Run aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55 with: image-ref: *** scan-type: image trivy-config:/home/runner/work/our-org/our-repo/.trivy.yaml severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL # these should only contain high, critical

CLI arguments in Trivy have higher priority then trivy-config params, so in this case you can see all vulnerabilities with UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL severities.

You can test it locally:

$ cat .trivy.yaml 
severity: HIGH,CRITICAL

$ trivy image -c .trivy.yaml alpine:3.14.1
2024-04-26T19:17:56.562+0600    INFO    Loaded .trivy.yaml
2024-04-26T19:17:56.580+0600    INFO    Vulnerability scanning is enabled
2024-04-26T19:17:56.580+0600    INFO    Secret scanning is enabled
...
alpine:3.14.1 (alpine 3.14.1)

Total: 37 (HIGH: 34, CRITICAL: 3)
...

$ trivy image -c .trivy.yaml --severity UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL alpine:3.14.1
2024-04-26T19:18:37.006+0600    INFO    Loaded .trivy.yaml
2024-04-26T19:18:37.023+0600    INFO    Vulnerability scanning is enabled
2024-04-26T19:18:37.023+0600    INFO    Secret scanning is enabled

alpine:3.14.1 (alpine 3.14.1)

Total: 47 (UNKNOWN: 0, LOW: 0, MEDIUM: 10, HIGH: 34, CRITICAL: 3)
...

So I think you have a mix of these two moments, @Frituurpanda wdyt?

[Frituurpanda]

Hey @afdesk,

Thanks for investigating!

On our case we are actually using the github action: https://github.com/aquasecurity/trivy-action

Thus are not mixing and matching config parameters and non config parameters. The simplest form that fails is:

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@d710430a6722f083d3b36b8339ff66b32f22ee55 #0.19.0
        with:
          image-ref: '$ref'
          scan-type: 'image'
          trivy-config: '.trivy.yaml' 

with the following in our .trivy.yaml:

severity:
  - HIGH
  - CRITICAL

I'll try to step down through the versions, try to isolate if that's the problem, otherwise it's probably our org that's inherently broken. I've seen the sample provided by @simar7 and can reproduce that this works, I simply can't reproduce that in my org.