Supporting whitelisting CVE's / Dependencies

[AtzeDeVries]

It would be nice to be able to ignore / whitelist certain dependencies. This way we can keep working if no fix exist yet/

[febuiles]

@AtzeDeVries this sounds like something we could do in a future. What format do you envision to specify the dependencies?

[AtzeDeVries]

I thought about having some config which sits with the code (so not in .github dir) which contains a whitelist (or ignorelist) which at least contains

• CVE
  Possible also
• End date until whitelist is valid (so required a review after x months)

And also i don't now how the CVE's on dependencies work, but i guess CVE's on a dependency can also be updated (added text, change of severity) so it would be nice to link the ignore a certain version of the CVE.

[febuiles]

We'll likely move our config options (licenses and allow/denylist) to an external config file in the upcoming months to make this Action easier to install in big organizations. Will take a look at this when we do the migration.

[AtzeDeVries]

Thnx for taking a look at it!

[LiuVII]

I don't see how this can be fully utilized without whitelisting really, looks like a must for anything beyond the MVP phase.
Is there some workaround in a meantime at least?

upd: well, maybe the GHA check can't be enforced really without whitelisting is what I mean, the action itself is pretty useful as it is 🙂 but making this check required would be really nice

[febuiles]

@LiuVII what do you think about adding a new config option (a list called ignore?) that is checked against the advisory_ghsa_id field of the API response? We don't receive CVEs in the API response, hence the fallback to GHSA ids.

If you need help getting a PR started please let me know!