Specify on SARIF report which Dockerfile/image is being scanned

[WolfangAukang]

I want to implement Trivy Github Action on a repo that contains multiple variants of a container image. The idea is that I am running a workflow for each version, like:

• Workflow 1 will build image myimage:variantX and scan it
• Workflow 2 will build image myimage:variantY and scan it

The problem I'm having currently and I don't know if a solution is already available is that on the Security > Code Scanning Alerts > Trivy section at the repo, I can see the issues are referring to a Dockerfile, which is okay.

But in the case we are doing a scan for each image variant, I want to see to which image/Dockerfile specifically is the alert referring to.

I see the sarif template at contrib/sarif.tpl has the following section:

...
 "locations": [{
            "physicalLocation": {
              "artifactLocation": {
                "uri": "Dockerfile"
              },
...

Which I would believe it is where it specifies the name.

Is that factible to be done?

[simar7]

hi @WolfangAukang - good question! Currently GitHub Code Scanning requires the service (Trivy Github Action) to specify a source of the vulnerability that is being flagged. For the initial release of the Trivy Github Action we went in with assumption that the user is scanning an image that they've built from a Dockerfile. And that the said Dockerfile is present inside the repo being scanned (so we can use it to flag it as the source).

As of now, Trivy doesn't have the capability to show you which layer in the Dockerfile the vulnerability originated from. This would be handy when making annotations that are more specific, for e.g. Line 123 in Dockerfile is introducing this vulnerability. This further can be shown in the SARIF output as you mentioned.

It is something we're considering on adding, so stay tuned. Hope that helps!

[WolfangAukang]

Thank you @simar7! Will stay tuned for sure

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.

[danielhoherd]

Another use case for having the image or Dockerfile specified is when one is scanning many images inside of a single repo. Currently the sarif does not specify what image was scanned, so all images inside a repo appear to have the same vulnerabilities.

This feature seems like low hanging fruit, and crucial information that keeps context within the report. I'd love to see the priority on this bumped up.

[frankgrimes97]

Currently the sarif does not specify what image was scanned, so all images inside a repo appear to have the same vulnerabilities.

We've also been bitten by this. We have one GitHub repository with many subdirectories with separate Dockerfiles each. When doing a scheduled trivy scan and subsequent upload of the SARIF results for the whole repository (main branch) to GitHub we sometimes see the following expected path which is nice and allows us to filter and show each separately: e.g. Detected by Trivy in docker-image-name:1

However, some SARIF results show paths within the Docker images which can have many duplicates across different Dockerfiles. e.g. Detected by Trivy in /opt/lib/*

This makes it very hard to manage the full results for the entire repository and forces us to resort to hunting for which Dockerfiles are reporting the bugs/CVEs. Any advice on how to address this problem? Is this a bug in how Trivy writes out the SARIF results? e.g. wrong physicalLocation?