GitHub code scanning alerts missing information about grype HOT 8 CLOSED

Thanks for getting back to me @lucacome -- I realized there is an alpine:3.17 in the screenshot that should be plenty to work with for now.

from grype.

Hi @kzantow thanks for this!
The last screenshot looks good to me, it has all the info I need.
I'm not sure if the path adds a lot of value, especially for installed packages, but more info is always better IMHO 😄

to tie the results between runs, what would be the most reliable, stable, and useful set of fields? image name and file? something else?

yeah I think image name and file should not change very often and should be a good way to tie the results

from grype.

Hi @lucacome, thanks for the report. Are you able to share the yaml code of the GitHub action you are running, or some other way to reproduce this issue? That would help us out. Thanks!

from grype.

Hi @tgerla you can see the action here https://github.com/nginxinc/kic-test-containers/blob/main/.github/workflows/ci.yaml#L242:L253

from grype.

any updates? I got this alert but I'm not sure from which image is coming...

image//usr/local/lib/python3.12/site-packages/pip-23.2.1.dist-info/METADATA:1

from grype.

Hi @lucacome -- sorry for the delay on this; do you happen to have any specific images you could point to that exhibit this behavior? Are these being built locally or are you pulling from a remote registry?

Regardless, I'm going to move this to the backlog to investigate improving this, but there are some GitHub limitations to what we're able to do here that come into play, too, unfortunately.

from grype.

Hi @kzantow no worries! I think it happened in pretty much all the images I scanned. In the workflow that I linked previously we're building images locally with a few base images, like python and go.

Unfortunately, I don't have more examples anymore because I'm in the process of switching my workflows to scan the SBOM from the image instead of the image directly, but I still have to get a CVE there to see if the same happens there 🙂

from grype.

Hi @lucacome -- I've revisited this a bit and could use some feedback about how to proceed. The biggest issue is that we have a limited set of fields that GitHub will use to display the code scanning alerts, and these have limitations themselves. Aside from the numeric stuff like severity, from what I've been able to tell, we essentially have 4 things we can use to convey information in the UI:

• match file name (the image//lib/apk/db/installed:1 in your screenshot)
• match details (the descriptive text below it "The path...")
• rule short title (the main title displayed)
• rule description (the expandable text with a table, only field supporting markdown)

The report we submit to GitHub has these 2 main types: matches and rules. The rules are not supposed to be specific to a match, so a location isn't generally supposed to show up there (even though we have that and a specific version included, etc.) and if we included multiple with identical IDs, it could cause some issue, so I'd prefer not to add image information there. This also would rule out the short title for including the location, so we're left with: match file name and/or match details.

What would be the most helpful?

We could modify one or both of these to include the image in one way or another. The file name shows up in the list before clicking details, but this is truncated fairly quickly, and truncated after a larger amount of text in the detail view. I added a couple example images that include the image in the filename (from these alerts) -- it can get a bit unwieldy and start cutting things off when a SHA is involved, but at least there's a way to get the full value clicking the copy icon. This field has some limitations: basically it needs to look like a relative path or GitHub will reject the upload so we need to encode the image and path in some meaningful way while still playing nice with the GitHub validation.

We could also update the descriptive text. I took a stab at rewriting this a bit. If this included the image, package, and file, would this do the trick? For example, "A critical vulnerability in apk package: ssl_client, version 1.34.1-r7 was found in image alpine:3.15@sha256:19b4bcc4f60e99dd5ebdca0cbce22c503bbcff197549d7e19dab4f22254dc864 at: lib/apk/db/installed".

We could do both things, if that helps, too.

There's one more consideration: these alerts have a key to tie them together between scanning runs. For example, the ssl_client mentioned above might be something that includes the name and/or image sha. The problem I would expect is that a common use is to scan locally built images, which are likely to have SHAs changing so they wouldn't match between runs. The good news is we have control over this key independent of what is displayed, but it would be good to know what is the most useful for you and others.

So, to summarize in question form:

• for the file name, what should we include for image scans? just the image name without tag/sha? full tag/sha request? just the image? also the file path within the image? definitely open to suggestions here!
• for the description, is there other information to include? do the modifications suggested work to get the information you need? also open to suggestions!
• to tie the results between runs, what would be the most reliable, stable, and useful set of fields? image name and file? something else?

Sorry for the small dissertation, but thanks for any feedback; and the examples mentioned are below:

List view truncation:

File path with image scan of "alpine:3.15" added:

Scan of image with sha, updated text:

Maybe a good combination of image name in the path, full SHA in the description:

I went ahead and made a PR with the last details; we can tweak this if it makes sense.

from grype.