Refactoring the codebase to reuse CycloneDX's project detection feature (by parsing the "universal" SBOM) before analyzing per-project

[saketjajoo]

The idea here is to leverage CycloneDX's capability to generate an SBOM for various kinds of projects and then use the 'aggregate' SBOM to detect the types of projects (based on purls). The aggregate SBOMs can be broken down into per-project SBOMs and can be saved to disk. Once the types of projects are detected, we can then perform the risk analysis, auditing, licensing and scanning for vulnerabilities.

Currently, dep-scan, by default, performs a universal type of scan to create SBOM (via cdxgen) when -t and --bom flags are not provided. However when --no-universal flag is provided, dep-scan attempts to detect the project type(s) of the source project by inspecting it's file extensions and then starts the scanning process (which includes creating an SBOM via CycloneDX). However, since CycloneDX can generate an aggregate SBOM, we can directly create one and then break it down into per-project SBOMs and then perform the scanning process. This would save some time during iterating on project types.

Note: The changes mentioned in this discussion/idea would need to be thoroughly tested for all the corner cases before merging into the main branch. Hence, all the PRs related to this discussion would go into a separate dedicated branch (fix/project-type).

The current flow of dep-scan and the new proposed flow is available in this flowchart.

Proposed Changes

• Refactoring the codebase to leverage CycloneDX's aggregate SBOM generating capabilities.

Minor Changes

• Fixing the -i parameter's view.
  Currently, -i ("src_dir") accepts both files and filepaths as input. However, while processing src_dir in the detect_project_type() function, it is treated in 2 different ways:
  a. As a filename while detecting project types for container related projects.
  b. As a directory while detecting project types for non-container related projects (e.g. java, python, npm, etc.).
• Respecting the --reports-dir parameter while saving the VEX files to disk.
  Currently, even if a --reports-dir is explicitly provided, the VEX file gets stored in the directory where the BOM file is present. The VEX file path is generated just by replacing the .json from the BOM file to .vex.json. Hence the --reports-dir is not respected in this case.