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:
myimage:variantX and scan itmyimage:variantY and scan itThe 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?
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!
Thank you @simar7! Will stay tuned for sure
Most helpful comment
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!