Vulnerability check with OSV might result false positives for Go

[rdimitrov]

This needs investigating as it's not necessarily a bug in Minder, but probably a corner case of OSV we have to take care of.

Prerequisite:

• This assumes that the related ruletype is created and instantiated

Context:

• When a PR is opened, Minder parses the patch for go.mod (if any) and extracts a list of all dependencies being added.
• Then we query OSV (or any other vulnerability db that might be) to see if they include existing vulnerabilities.

Details: Part 1: The dependency example that reproduces this is https://github.com/hashicorp/vault/api.

• If you import it in your code it will be added as an entry to the go.mod file.
• If you search for that in OSV we'll see that there's no vulnerability being reported for it.
• In that case Minder will say - hey, there's nothing that I found for this package in OSV so it's okay to use it.

Part 2: There's a vulnerability for https://github.com/hashicorp/vault though

• If you search for that in OSV we'll see that it actually mentions there are vulnerabilities related to the api part, but it lists that as a version, not as part of the repo/package.

Questions:

Should we strip the name of the new packages to be in the format of github.com/owner/repo discarding what's after that and use that to query OSV?

• If so, we hit another issue where the version that we get from OSV (which should include the fix) is different from the versioning this repo uses for their api package. (the vault package is versioned differently than the api package even though they both come from the same repo)

[mesembria]

Revisit when we move the rule implementation from go to rego.