grype db search GHSA-mrrh-fwg8-r2c3 doesn't return results

[TimBrown1611]

What happened:
yesterday i saw this vulnerability was published - GHSA-mrrh-fwg8-r2c3
i've tried to run grype db search GHSA-mrrh-fwg8-r2c3 with no results.
I have few questions:

1. at which time the job of syncing the new vulnerabilities runs?
2. do we cover malicious vulnerabilities from github advisory?
3. why when I run grype db search I didn't see any action of downloading the newest version of db (i manually run grype db update)
   What you expected to happen:
4. find the vulnerability
5. run automatically grype db update before of grype db search
   How to reproduce it (as minimally and precisely as possible):
   grype db search GHSA-mrrh-fwg8-r2c3

Anything else we need to know?:

Environment:

• Output of grype version: 0.89.1
• OS (e.g: cat /etc/os-release or similar): mac

[kzantow]

Can confirm db search returns no results and this does not appear in the database. I believe this is due to grype not matching vulnerabilities from this ecosystem (note there is no mention of GH Actions in the supported ecosystems). The data sync log says it drops ACTIONS as an unmapped/unsupported ecosystem. This issue might be a good driver to implement matching for GH actions! Although I think GH has already blocked it so there won't be further malicious action runs, but this would be a great one to surface to people!

[TimBrown1611]

I think this issue is a good example how important is to cover github actions since it becomes a popular supply chain vector attack. I think the main issue is how can we map between vulnerable commits \ versions since the advisory doesn't always specifies it. I suggest raising it in the next community OSS discussion since this is a major issue which grypes can't cover right now :) @kzantow

[kzantow]

We had a discussion about this, I just wanted to note a complication here: Grype normally does version matching based on version ranges, but a common/best practice in GitHub actions is to use SHA to pin the action to a commit, rather than a version. For these cases we wouldn't have a great way to identify a vulnerable version without some supplemental data: either something in the grype db or somehow looked up against the GH API either in Syft or Grype.

[kzantow]

A little investigation: we may be able to parse the version from a comment, investigation needed: https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/githubactions/parse_workflow.go#L56