Rename --list-all-pkgs to --scanners sbom

[knqyf263]

Description

Currently, we have the --scanners flag, which supports the following options: vuln, misconf, secret, and license. To align with this structure, I'm considering renaming the --list-all-pkgs flag to --scanners sbom.

This proposed change aims to:

• Enhance the CLI's intuitiveness by grouping all scanner-related functionalities under the --scanners flag.
• Provide a more consistent user experience for those familiar with the --scanners flag.

However, I have a concern: while vuln, misconf, secret, and license are directly tied to security issues, the Software Bill of Materials (SBOM) is not directly a security concern. It's more about transparency and understanding the components within a software. By grouping it under the --scanners flag, there might be a potential for confusion among users regarding its purpose.

I'd appreciate feedback from the community on this proposal.

[itaysk]

some additional consideration: if someone wants to create an [output plugins](https://aquasecurity.github.io/trivy/v0.50/docs/configuration/reporting/#plugin that operates on an SBOM, they can't as of today since the --output flag is used both to control SBOM, and to control the output plugin.
The design of output plugin assumes the plugin input is always a native trivy json, and the plugin should convert to whatever it needs, which is fine, but there's no way for the user to specify that they want to create an SBOM (if they used the output plugin=) option.
in this case, I would expect the sbom output plugin to generate a trivy sbom json. and the plugin to be able to use a trivy library to convert it to the desired SBOM format and process it.

[knqyf263]

I think you're confused with --format and --output. As documented here, --format works with an output plugin.

While the example passes JSON to the plugin, other formats like SBOM can also be passed (e.g., --format cyclonedx).

[knqyf263]

We realized after starting the implementation of this issue that treating SBOM generation the same as the existing scanners is indeed challenging. In particular, since SBOM is not a security issue (as I commented in the description), its handling does not align with that of other scanners. For example, there is the question of what to do with SBOM information in table displays, and in SARIF it isn’t included at all. The --severity flag currently applies to all scanners but not to SBOM, and the same goes for .trivyignore, --show-suppressed and other flags. We believe that introducing --scanners sbom would require numerous exceptions both in implementation and in user experience, potentially leading to even more confusion and bugs.

I originally created this Issue to gather feedback from the community, but since there were no specific requests or comments, I have decided to revert it back to a Discussion. Unless a good idea emerges to resolve these issues or there is strong motivation to proceed with this change, it is not planned to be implemented in the near future.