new triage framework and automated triaging!

[luhring]

trafficstars

Design 🗺️

This introduces a new triaging framework centered on this new interface:

type Triager interface {
	// Triage takes a scan result and returns a triage conclusion.
	Triage(ctx context.Context, vulnFindings scan.VulnFindings) (*advisory.Request, error)
}

The idea is that we arrange findings for a single vulnerability in an APK package as a scan.VulnFindings, such that triager implementations can take this and return their conclusion on whether the vulnerability truly affects the APK package. The result is an advisory.Request — i.e. new advisory data all ready to be applied to our advisory data set.

The consumer can wire up as many triagers as needed. Each triager can bring along its own state or network clients as necessary. So while some triagers may only need access to the APK data, others might want to access other local information or even do online lookups.

Features 🚀

Automated triaging! 🎉

This PR adds two concrete implementations of the Triager interface, which have already been massively helpful at dealing with vulnerabilities (these dealt with ~130 vulnerabilities in ~10 minutes net runtime):

1. "govulncheck" — Based on the tool govulncheck, this implementation cross-references the input findings with an analysis of symbols found in Go binaries to decide if an otherwise present vulnerability has no impact on the APK.
2. "gogitversion" — This clones git repositories for affected Go modules to do version-control-aware analysis of whether remediating commits have been incorporated into the version of the Go module used in a binary in an APK package. The implementation maintains a local cache of git repositories to drastically speed up triaging.

Orthogonal to these features, this PR also was designed for incorporating into future services, and therefore has been instrumented with lots of logging and tracing. 📊

Caveats ☠️

Since this PR was written to illustrate a concept, with more work originally intended to come later, there are several aspects that would need further work before considering this logic ready-to-use in production.

1. There are no tests — and this is the kind of logic that needs THOROUGH testing. We cannot afford inaccurate advisory data to be automatically added to our data set without proper verification of the validity of triaging assessments.
2. There are many spots in the execution when context cancellation should be considered due to the long-running nature of several pieces in the logic flow.
3. We need a more robust strategy for mapping fixed version data to tags in a source code repo (for "gogitversion"); so far I've been manually adjusting code to expect a leading v prefix and to not expect one.
4. The "gogitversion" implementation can likely be generalized to handle cases beyond Go.
5. The commit-to-later-tag version check needs to be taken with a grain of salt, since we're not checking all affected version ranges, only a simple comparison to the "fixed version" reported by Grype.
6. This code doesn't understand the notion of APK "build groups" yet (i.e. an origin packages and its subpackages all produced in the same Melange build). This matters! Because we should not draw a conclusion about a vulnerability affecting an APK package without assessing the impact on the entire build group, since the advisory data is used to apply to the entire build group.
7. Same thing as above, but for multiple architectures instead of multiple packages within a build group.
8. More care should be taken on understanding the latest advisory data for a given vulnerability before proceeding to triage. For example, if we've already drawn our conclusion about a vulnerability (say as a TP or FP), we probably don't want to automatically append an updated triage assessment after that, in contexts when we're not certain that the automated triaging has as much context as went into the previous triage assessment.
9. We should use a better source of truth for fixed version data than the Grype database. Perhaps a local OSV database.

[hectorj2f]

@luhring I have tried the cli to generate some advisory data but i didn't get anything and the command exited successfully.

wolfictl adv triage -a ../advisories -p ingress-nginx-controller --built-packages-dir ~/os/packages/aarch64

[luhring]

Yeah @hectorj2f this isn't meant to be used yet 😄 still a draft PR — I just wanted to show the general idea and the progress toward that idea so far

[luhring]

Note: The team has decided not to pursue merging this PR. We'll leave it here for a short time to serve as a reference for other work.

[hectorj2f]

Thanks @luhring 👍🏻 !

[luhring]

Migrated to another repo 👍