Distinguish unknown license from unsupported package type in License Scanning

Problem to solve

The License scanning of CycloneDX files supports specific package types listed here: https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/#supported-languages-and-package-managers

Thoughs, we have more and more feature relying on the SBOM report artifact as their source of data and more package type (PURL type) can be supported there (e.g. Dependency list, Continuous Vulnerability Scanning).

The current implementation of License Scanning related functionality doesn't distinguish components for which we can't scan their license from components we can scan but for which the license is unkown.

This situation can create confusion and even prevent some feature from working adequately like the License Approval Policies for instance.

Example project

In this test project, we have 2 dependencies with an unknown license shown in the dependency list. Though, only one of them is actually supported by License Scanning:

• abot/abot is a maven package for which our License DB reports an unknown license for version 0.12.3
• apt is a deb package which is a type not supported by our License Scanning feature.

In this example MR, the License Approval Policy is preventing the merge due to both abot/abot and apt having an unknown license. While it is expected that the former abot/abot should block, the later apt should not effect the policy as we'll never be able to report its license.

Proposal

Ensure License Scanning is only executed for PURL type that are supported, and clarify the difference between

• a component being scanned and having an unknown detected license
• a component that has not been scanned for their license due to unsupported package type

Implementation

Quick term solution: DRAFT MR for a short term fix for License Policies started by @alan and filter based on supported PURL type: Prevent CS SBOM to be parsed as ready for Licen... (!158831 - merged)

Long term solution: TODO

NB: as we move forward with User provided license information for components (&10861 - closed) and specifically Ingest component licenses from CycloneDX SBOMs (#370013 - closed), we will no longer be able to hardcode the list of PURL type that are supported for license scanning. At least, we can't prevent the downstream features to consider the license for a component based on it's PURL type. This certainly requires to have different states stored for the various situations (not scanned yet, scanned but no license found, etc.).