feat: no-scan mode

[terriko]

Description

Add the ability to generate an SBOM without doing a cve scan of the components found. We could potentially make this work for other formats other than SBOM (such as an HTML report) but I suspect that SBOM will be by far the preferred mode.

Right now, the tool expects you to initialize the database with data from NVD and will always provide whatever scan results it finds. But the binary signatures and our collection of parsers could be used just to give you a list of components without any vulnerability information attached. While we've alleviated some of our problems with NVD reliability using the mirror, it's still a lot of data to download if you're not even going to use it, so it would be nice to have a way for people to turn that off if they don't want it.

I'm not sure off the top of my head exactly how much re-wiring this would take. We may be able to fake something up by initializing an empty database if no database exists, but I don't want it generating a bunch of reports that says "0 cves found" if in fact no data was downloaded. At a guess, we'd need to refactor in a few places:

• Code to skip every single database call, similar to what we do with --offline for network calls.
• Generation of reports: will need to take out all the parts of reports that refer to cves and (where appropriate) instead have some boilerplate text saying that cve-bin-tool was run in no-scan mode
• probably a new flag (e..g --no-scan) to trigger the behaviour
• I think it would also be nice to have something with a different name than cve-bin-tool so people can call something more obvious like generate-sbom after they've pip installed cve-bin-tool.
  • We already do this with csv2cve link to the syntatic sugar that is that file

Why?

• Related discussion in bug: application should not use nvd statistics when nvd is disabled or nvd is using api2 #3801

It turns out that some users. particularly in the embedded community, find our ability to generate SBOMs from binaries useful but don't need to use the cve-scanning portion of cve-bin-tool (either because they only want a component list or because they use another tool for this part of things).

This was a bit of a surprise to me. The embedded tools I use most can generate their own (more accurate) SBOMs, and I'd assumed that existing tools used for licensing had already covered the binary analysis gap reasonably well. But it sounds like we have a little niche with our combo of binary signature and sbom export capabilities. Even if it feels a bit at odds with our original goals for this project, I'd really like to support our users better!

[anthonyharrison]

@terriko Generating SBOMs from binaries is a very useful feature and not found in many other OSS products.

However I wonder whether we need to start thinking about a bit of refactoring to offer a number of different 'scripts' which support the different use cases we are now seeing. There are a number of features which could become useful standalone modules

• Binary vulnerability analyser (the original core use case)
• SBOM vulnerability analyser
• CVE scanner for a product
• Report generator
• SBOM generator
• VEX processor

These could then be put together to create some new apps e.g.

• CVE-BIN SCAN = Binary analyser + cve scanner + report generator
• SBOMGEN = Binary analyser + SBOM generator
• SBOMSCAN = SBOM vulnerability analyser + cve scanner + VEX processor + report generator
  etc

[terriko]

Version compare should probably be a separate module too (see #4801), but I still haven't decided if it should really just be a separate pip dependency or what.

Other than the "I really only want component analysis" request, I feel like a lot of our bugs are people who just want to run cve-bin-tool and have it do magic and they don't really know or understand what they're scanning, so the all-in-one we're trending towards may be the right solution for them. But the idea of refactoring is pretty tempting. I'd divide it very subtly differently, more in line with our architecture diagram, and group all of the binary/language parser/sbom parser stuff together into a big "component analysis" blob:

We'd want to merge the download and CVE parts (red and green boxes) but the rest could probably be separate:

1. Component analysis: cve-bin-tool components <directory>

• includes binary analysis, sbom and language parsers.
• By default: run it on a directory/file and have it spit out an SBOM
• Options to disable individual scanners/parsers or groups of them (e.g you should be able to skip both a single binary component or all language parsers at once)
• Input: directory/file, ouput: SBOM (?)

2. Vulnerability scanner (+CVE download): cve-bin-tool vulns <SBOM>

• Give it the output of component list generation, have it generate list of CVEs.
• Optional: if you give it a directory instead of files it could call component list generation itself.
• Input: SBOM (or providing a directory will call sbom generation), output: SBOM+VEX (?)

3. Triage (VEX processing) cve-bin-tool triage <SBOM> <VEX>

• apply triage to output of component list generation and/or vuln scanning
• Optional: if you give it a directory, have it call the previous two components to make the input
• Input: SBOM+VEX, Output: SBOM+VEX with annotations/removals/additions

4. Report generation (+epss / metrics annotation) cve-bin-tool report <SBOM> <VEX>

• make pretty reports out of all other formats.
• Optional: if you give it a directory, have it call steps 1, 2, 3 directly
• Input: SBOM+VEX, output: html/pdf

5. version compare: cve-bin-tool version_compare <version1> <version2>

• not really the same as the others, but a simple interface to let people experiment with or use version_compare by itself
• output: -1, 0, 1 representing < == >

Some open questions:

• I'm not sure if we could use SBOM and VEX directly or if we'd need some sort of SBOM+ / VEX+ formats to store some data as we go. (I'm thinking particularly of stuff like error messages that we'd want to percolate all the way to the report generation step, but there may be other things.) Depending on what else there is, we might just want to make a separate error.json file or find a way to add it into existing freeform fields available in the formats.
• right now the CPE data for binaries is embedded in the checkers, so we'd have to find a way to embed that in the SBOM so the vuln scanner would use it correctly. Should be doable but definitely isn't happening right now
• We could conceivably group triage and metrics together (instead of having report+metrics), or maybe have triage+metrics+report be a single component with SBOM+VEX as an output option