feat(security): support project vulnerability scanning and VEX statements

[brandtkeller]

Description

Users have been (appropriately) approaching the project with scanner findings from Zarf. Many of these are occurrences of transitive indirect dependency vulnerabilities that do not affect Zarf itself and are not reachable. In order to reduce cognitive burden for both maintainers and users - we're creating policy and VEX statements to help provide releasable evidence to suppress scanner findings with context from the maintainers.

At the same time, monitoring the vulnerability surface has been adhoc and not automated.

This PR addresses this gap and adds automation to support earlier identification of findings and discoverable (and transient) adjudication information.

1. This adds a nightly (or manually executed) workflow to scan for CVE's using both govulncheck and grype. govulncheck provides scanner findings directly to the project security dashboard and adds context we can then correlate to grype which publishes potentially non-reachable findings that users otherwise would want information about why they are not applicable. If there are high/critical findings the workflow will fail.

2. We create a vex workflow (documented) that offers a point of adjudication and supression method for the aforementioned grype scanning above. Maintainers can author vex statements for non-applicable findings for which the next subsequent run of the scan will supress said findings.

3. The VEX is packaged with the Init Package as a document file (any findings therein are directly applicable to both the Agent and CLI) as well as released as a release artifact for a given version.

4. Make targets are provided for the workflows to use locally.

Related Issue

Fixes #3842

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[netlify]

✅ Deploy Preview for zarf-docs ready!

Name	Link
🔨 Latest commit	f86dcb1
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/6a502bdb97674100083f1226
😎 Deploy Preview	https://deploy-preview-5029--zarf-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brandtkeller]

Note: these dependency changes are a result of the tool directive below. It feels like a neat utility but I am not tied to this versus other installation methods.

[AustinAbro321]

This is cool to see. Some questions and comments

[AustinAbro321]

"It has no suppression mechanism;"

What does suppression mean in this context? In this PR we are suppressing GHSA-fqw6-gf59-qr4w that seemingly has an equivalent for govulncheck. Does that fact that it's in the vex file mean that we're suppressing the govulncheck vulnerability as well?

Said another way, where should users look for a list of active Zarf CVEs? If this list exists will the equivalent govulncheck for GHSA-fqw6-gf59-qr4w be included or excluded from that list ?

[brandtkeller]

govulncheck findings are project contributor/maintainer facing and also have no suppression mechanism (to flag findings as ignored). Grype findings are the list that zarf users will typically be using and of which we can point them to running against our artifacts with VEX statements.

Grype is working on closing the gap between govuln and current scanning - so I expect to see more overlap with grype being the more wholistic story.

[AustinAbro321]

Gotcha, the "every finding must be addressed upstream" just made me feel like there is an action to take on every govulncheck finding even if the finding is not relevant.

[AustinAbro321]

It's rare, but I think there are cases where a critical should be updated directly. Using the replace directive will avoid any go.mod drift in that case.

I would also start this section with the evaluation bullet, then combine this point with the third point (prefer direct dependency upgrade, if deemed necessary patch with replace directive).

[brandtkeller]

language could be more flexible for nuance