Collect additional metadata for vulnerabilities from OSV

[hown3d]

Description of the PR

This PR introduces a new flag, add-vuln-metadata, that enables the collection of severity information for CVEs directly from the OSV API. When this flag is enabled, the collected severity data is ingested into GUAC as a VulnerabilityMetadata nodes, enriching vulnerability data with additional context on severity levels.

Key Changes:

• New Flag: Adds the add-vuln-metadata CLI flag.
• Ingestion to GUAC: Captures the retrieved severity data and stores it as a VulnerabilityMetadata node, allowing for improved vulnerability assessment and analysis within GUAC.

This enhancement provides better visibility into CVE severity, enabling users to prioritize vulnerabilities more effectively based on standardized severity metrics.

PR Checklist

• All commits have a Developer Certificate of Origin (DCO) -- they are generated using -s flag to git commit.
• All new changes are covered by tests
• If GraphQL schema is changed, make generate has been run
• If GraphQL schema is changed, GraphQL client updates/additions have been made
• If OpenAPI spec is changed, make generate has been run
• If ent schema is changed, make generate has been run
• If collectsub protobuf has been changed, make proto has been run
• All CI checks are passing (tests and formatting)
• All dependent PRs have already been merged

Signed-off-by: Lukas Hoehl [email protected]

[pxp928]

Thanks @hown3d this is a great addition! Will review this soon!

[hown3d]

For now I've only included the severity field from the OSV API.

I see potential in ingesting additional metadata like summary, details and references into GUAC.
Those are not part of the vulnerability attestation (yet?) though, so it's not clear how to parse these from the attestation into VulnerabilityMetadata nodes.

[pxp928]

For now I've only included the severity field from the OSV API.

I see potential in ingesting additional metadata like summary, details and references into GUAC. Those are not part of the vulnerability attestation (yet?) though, so it's not clear how to parse these from the attestation into VulnerabilityMetadata nodes.

For the vulnerability summary, details..etc, our thought process was that information did not need to be stored in the graph. Rather, it can be retrieved client side when needed. The CVE - severity field are needed to make decisions.

So only information that is needed by admission control or some other policy engine should be in the graph and queryable. Other information can be obtained client side when needed from OSV.

[pxp928]

Sorry for the delay! I will review this soon!

[pxp928]

Overall this is a great PR, very comprehensive! We should just remove it from "on ingestion" otherwise this is good to go! Thank You!

[hown3d]

Overall this is a great PR, very comprehensive! We should just remove it from "on ingestion" otherwise this is good to go! Thank You!

Rechecking the code i don't think it's necessary to use a flag instead just defaulting to add vulnerability metadata. It introduces so many places to add this flag that it gets quite confusing.
I don't thinks it's a problem to always store the information for vulnerabilities in GUAC.

[pxp928]

Rechecking the code i don't think it's necessary to use a flag instead just defaulting to add vulnerability metadata. It introduces so many places to add this flag that it gets quite confusing.
I don't thinks it's a problem to always store the information for vulnerabilities in GUAC.

For on ingestion we should default it to false (no need for a flag). The certifier can have a flag which the user can enable/disable if they want.

[lumjjb]

Awesome - this is a great addition to the OSV certifier, thanks @hown3d ! I have one request, else LGTM!

[pxp928]

LGTM! I just have a concern on the timestamp that I may be misunderstanding?

[lumjjb]

see follow up too comment. minor change