Dependencies vulnerability scanning

[shahar-h]

Description:
Currently There is an underlying dependency vulnerability scan as part of OpenSSF Scorecard workflow which is triggered on push to main branch.
OpenSSF is using osv-scanner behind the scenes:
https://github.com/ossf/scorecard/blob/49c0eed3a423f00c872b5c3c9f1bbca9e8aae799/docs/checks.md#vulnerabilities
https://google.github.io/osv-scanner/
We currently have score 7 since there are several vulnerabilities:

It is not clear what is the origin of the vulnerabilities unless we run osv-scanner locally.
Do you think we should add an additional scan as part of separate GH workflow or keep it like it is?
We can use either trivy or osv-scanner. I think osv-scanner should be preferred so we can be aligned with OpenSSF scorecard.

In addition, should this be triggered also on PRs? It has the downside of blocking PRs in case of unfixed vulnerabilities.

Please share your thoughts.

[shahar-h]

When running osv-scanner locally I could see that all identified vulnerabilities are related to non-root go modules:

• site/go.mod
• tools/src/buf/go.mod
• tools/src/controller-gen/go.mod
• tools/src/protoc-gen-go-grpc/go.mod
• tools/src/setup-envtest/go.mod
  These vulnerabilities are displayed in ossf scorecard grouped by vulnerability id, except stdlib vulnerabilities which are ignored by ossf-scorecard(which are all related to old go version in site/go.mod).

I have some thoughts/questions regarding the way forward:

1. Do we care about vulnerabilities in non-root modules?
2. In case we don't how should we handle them?
   1. Scan only root module? In this case the vulnerabilities will still influence openssf scorecard since it triggers osv-scanner with recursive mode.
   2. Scan recursively and triage all non-root modules vulnerabilities? This means adding a osv-scanner.toml file with triaged vulnerabilities in each relevant module. This also means that we need to remember to clean fixed vulnerabilities once they are updated.
   3. Scan recursively and fix issues in non-root modules by adding temporary replace directives(assuming all dependencies are periodically upgraded by dependabot). Also here we need to remember to clean stale replace directives.
3. What should be our policy for vulnerabilities which have no fix yet? Should we temporarily add them to ignored list so PRs won't be blocked? Or maybe run the scan only upon merge?