feat: auto-scanning for SBOMs in a directory

[terriko]

Currently when you run cve-bin-tool $directory it will pick up the following:

1. Binary files which are scanned with our binary checkers
2. Files that the language parsers understand (e.g. go.mod, requirements.txt, etc.)

But I believe we won't pick up SBOMS. Currently you need to specify those explicitly using the --sbom file (similarly to how we handle our older input file types of .csv and .json).

@b31ngd3v is currently working on a github action: https://github.com/intel/cve-bin-tool-action and it's got me thinking that I'd like to make the default "scan everything in your github directory" config work for as many people as possible, which means automatically finding and scanning sboms would be a valuable feature. I think we should probably change this behaviour so we try to find them in directories (by file extension + some checking of schemas since .json and .xml could be other things?) and scan them appropriately. I don't actually expect we'd get great results for all SBOMs (since the quality is so variable) but I feel like getting some results is a gateway to getting better here and will help people see the capabilities of our tool without having to read the whole manual to figure them out.

@b31ngd3v -- I'll suggest you might want to take first crack at this since it'll be useful for your Action, but if you want to just dump some thoughts about what will make the action work best here and leave implementation to someone else, that works too.

[anthonyharrison]

@terriko Scanning a group of SBOMs would be interesting. However, I think we would need to ensure that we track a vulnerability to the relevant SBOM otherwise it become difficult to understand which one to change.

Each SBOM has a name, some maybe that needs to be extracted with the list of components and then passed through to the output engine.

[terriko]

Yeah, I think we'd have to treat scanning multiple sboms similarly to how we handle things like zip files and make it clear where each issue was found. And we'd have to figure out if this means "it all goes into the one big report" (similar to what we do now with mixed binaries and language data) or if it would result in a report per SBOM file found (potentially viable but very much not like what we do now with reports). We definitely wouldn't want to remove the ability to scan individual sbom files while doing this; this would be just extending what you get out of a default scan.