trivy-config input is not respected anymore

[marcrohlfs]

We prefer having or Trivy configurations in trivy.yaml config files over passing the configurations via action inputs. It's more flexible (we can use configurations we couldn't when using the inputs) and the GitHub workflow code looks a bit cleaner. This worked fine until now, but after we updated to v0.26.0, the configurations in the trivy.yaml are not respected anymore. After #399 has been merged and released, the trivy-config input still exists, but it's not passed to the entrypoint.sh anymore, nor used in there.

Please re-implement passing the trivy-config to the Trivy command.

Remark: Looks like some more inputs got lost, but they could also be configured via trivy.yaml.

As an example, our Trivy actions look like this:

      - name: Run Trivy image scan
        uses: aquasecurity/trivy-action@0.26.0
        with:
          scan-type: image
          image-ref: my-image
          trivy-config: .github/workflows/config/trivy.yaml

And the trivy.yaml:

format: sarif
output: trivy-results.sarif

ignorefile: .github/workflows/config/trivyignores.txt

severity:
  - MEDIUM
  - HIGH
  - CRITICAL

scan:
  skip-files:
    - /prometheus/jmx_prometheus_javaagent.jar
    - /usr/bin/confd

pkg-types:
  - library

[nikpivkin]

Hi @marcrohlfs !

Have you tried updating the action to the latest 0.28 version? It works for me.

2024-10-16T13:09:20Z    INFO    Loaded  file_path=".github/workflows/config/trivy.yaml"

[marcrohlfs]

Hi @nikpivkin,

sorry for the late answer. I didn't try before, but I tested it successfully now. Many thanks!

Actually, I wasn't aware that the regarding code is in another repository. When it didn't work, I just checked the code updates in here.

Testing if the new version fixed the problem was a bit cumbersome (for me). Unfortunately there're not hints in the workflow run's output that give information if the config's settings are actually applied. Maybe it would be useful to expose such information, a least when debug logging is activated. Just an idea... 😉

Best regards!

[marcrohlfs]

Unfortunately I have to come back on this, there still seems to be a problem. I just noticed that there're still reports for CVEs that should not be reported.

With the configuration I already outlined above (now using aquasecurity/trivy-action@0.28.0, of course), I got a new OS-level CVE reported.

As the trivy.yaml configures pkg-types: [library] (without os), this shouldn't happen. I suppose that the trivy-action overwrites some trivy.yaml settings with its defaults. Unfortunately I don't see any hint in the GitHub workflow's console output that could provide any more useful information to analyze this.

[marcrohlfs]

Just discovered that we tripped over config changes in Trivy versions:

• vulnerability.type: deprecated since Trivy v0.54, still usable
• pkg-types: only used in Trivy v0.54
• pkg.types: Trivy v0.55 and newer

Unfortunately we changed to pkg-types some time in the Trivy v0.54 version window. We didn't get aware of the change to pkg.types in Trivy v0.55. After changing to pkg.types in our trivy.yaml, it finally works like expected.

Some final thoughts:

• Would have been nice if the pkg-types configuration would have also been deprecated instead of being removed in v0.55 and newer.
• After the latest changes, it's hard(er) to find out what Trivy version the trivy-action is actually using. This information was added to the action's release notes until v0.25.0, but now it isn't anymore.
• Respect to my findings, I just checked the Changelog of v0.55.0: they don't contain any information that would have told us that we had to change the our trivy.yaml again. What a pity!