feat: simplify default operation of cve-bin-tool

[terriko]

I'm currently working on updating our README.md and MANUAL.md file in preparation for the 3.3 release, and right now we list a few types of operation that could maybe be combined into one:

• cve-bin-tool <directory/file> -- this tries to auto-detect components, including using the binary checkers and language component list parsers.
• cve-bin-tool --input-file <file> -- this treats a single file (in .json or .csv format) as a bill of materials list
• cve-bin-tool --sbom <sbom_filetype> --sbom-file <filename> -- scans an SBOM

What I think I'd like is for

cve-bin-tool <directory/file>

to work basically as expected no matter whether it's run as

cve-bin-tool my-directory/

or

cve-bin-tool my-component-list.csv

or

cve-bin-tool my-sbom.json

The first two already do work, but they throw an error encouraging people to use --input-file. I'm thinking we should leave the info message saying "this looks like a component list so I'm scanning it as such." but maybe plan to deprecate --input-file in a future release depending on how much of a pain that is.

I'm guessing SBOM auto-detection is more of a pain, since sbom quality is all over the map, but it should be doable at least for ones that have appropriate info in them. @anthonyharrison do you have any thoughts there?

And anyone else -- thoughts on streamlining? I'm basically just reading the docs and thinking "wow, this is way more complicated for the user than it needs to be.

[anthonyharrison]

@terriko - auto detection of an SBOM is possible primarily based on file extension which is what lib4sbom does. I think what might be useful would be a simple helper function is_sbom() which returns True if the file is an SBOM and False otherwise.

[terriko]

We could also look for some of the schema stuff so we can tell the difference between arbitrary .json files and actual sboms in a given format. And by "look for the schema stuff" I mean both "does it have a stated schema/version/etc" and also "does it have the expected fields/variables/attributes/whatever-they-are-called-in-json.

I wonder if I could turn this into something well-defined enough to be a hacktoberfest issue....

[terriko]

Actually you know what, I'm just gonna put the hacktoberfest label on and see if anyone's interested enough to work on this.

[mastersans]

Hey @terriko I have been exploring and learning about a tool for some time now. In my understanding, to identify an SBOM using the schema, we can use the following approaches:

For CycloneDX, which can be in .json and .xml formats, I think using the 'bomFormat' field for identification in .json format, as it is required according to the specification. For .xml, checking for the presence of 'bom' and 'xmls' seems appropriate.

For SPDX, using 'SPDXID' in .yaml, .json, and Tag-Value formats appears to be a valid method. Similarly, for .xml, checking for 'spdx:SPDXDocument', and for .rdf, 'rdf:RDF' tags can be effective, do let me know if i am on a correct track.

[terriko]

Yes, I think that's the right track!

[mastersans]

Great, I'll delve deeper into this. I think fixing this might also help with #3116.
Also is it okay for me to work on this one?

[terriko]

@mastersans It's totally ok, and actually you don't really have to ask -- if an issue is open and doesn't have someone working on it, it's considered to be up for grabs and available to anyone who wants to claim it.