search

intel / cve-bin-tool

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions.
https://cve-bin-tool.readthedocs.io/en/latest/
GNU General Public License v3.0
1.23k stars 463 forks source link

Docs: Add triage guide #1747

Closed terriko closed 6 months ago

terriko commented 2 years ago

I've started adding some additional information on how to use triage and merged reports in #1746 but we could probably use a more complete guide about how to triage a cve-bin-tool report.

terriko commented 2 years ago

Possible topics:

raboof commented 2 years ago

I think this would be great (especially "how to re-use triage") and I would be interested in helping out. I suspect we would like to make some code changes first, though.

Regarding #1746, I don't think that tests what it seems to test (anymore?): AFAICT -i and -m are currently mutually exclusive, and adding -m will cause any -i to be ignored. So what that test does is ignore the scan and only output the information from the triage report.

AFAICT the status of combining triage data with scan data is currently as follows:

In other words: AFAICT currently only the variation cve-bin-tool -i triage.json.vex thing/to/scan does what we want - and that one can be pretty slow because of the scanning :).

cve-bin-tool -i triage.json.vex --sbom cyclonedx --sbom-file scan.sbom.json also does what we want, but we have no good way to produce the sbom that matches what we expect when we do the vulnerability matching.

I see two ways forward: 1) find a way to perform the equivalent of cve-bin-tool -i triage.json.vex thing/to/scan but with previously-scanned content. From my limited experience with the code it seems like everything to make this possible is mostly in place, and we mainly just need to come up with a sensible way to make this available from the CLI . Perhaps we should introduce a new flag explicitly meant for providing triage files as input? That'd also fix the slightly confusing behavior that providing a vex file with a '.json' extension doesn't work ;) 2) implement #1697 and recommend cve-bin-tool -i triage.json.vex --sbom cyclonedx --sbom-file scan.sbom.json. This is appealing for additional reasons mentioned in that issue, but probably a chunk more work.

Does this make sense at all? Perhaps we should first do '1' as a quick win, document it, and then leave '2' for later?

terriko commented 2 years ago

Yeah, let's at least get 1 working.

For 2 we already have the ability to use @anthonyharrison 's https://pypi.org/project/sbom4python and get an SBOM (and code showing how in the github actions files since we're generating them once per week to figure out how often things change) so maybe adding the vex triage wouldn't be that hard to get working from there? I admit, I haven't experimented with that at all.

raboof commented 2 years ago

Yeah, let's at least get 1 working.

:+1: let me see if I can cook up an initial PR tomorrow! :)

mastersans commented 8 months ago

@terriko Although newer triage documention would be handled in Gsoc project, But this one in already been taken care of with https://github.com/intel/cve-bin-tool/pull/2335 : )

terriko commented 6 months ago

Closing this as per comment above.