[FEATURE]: Introduce a New Component Type for scratch Base Images

[hbandi]

Describe the feature & ## Possible solutions

We are using scratch as the base image for our application images. When generating the SBOM, there is currently no ideal component type to represent the scratch base image in the schema. The supported component types are:

"application"
"framework"
"library"
"container"
"operating-system"
"device"
"firmware"
"file"
etc

Among these, "container" is the closest representation. However, using "container" to represent scratch can lead to confusion because:

Containers typically include operating system libraries, files, or components. Labeling scratch as a "container" could be misleading, as it implies the presence of a runtime environment, which scratch lacks.

Avoiding misrepresentation: Mislabeling scratch as a "container" may lead teams to expect filesystem or runtime components. By introducing a new component type (such as "base-image"), we could explicitly represent scratch as the foundational layer upon which containers are built, without implying the existence of unnecessary components.

Introducing a new type like "base-image" (or another name we can discuss) would enhance clarity for both automated tools and human reviewers. SBOM tools could recognise specific markers for this new type and handle it differently from fully-fledged containers.

This distinction would streamline SBOM processing, particularly in tools focused on security and compliance scanning. For auditors, it would provide a clear indication that the image is not a traditional container and does not include components or an operating system.

Benefits of Introducing a New Type:

Accuracy and Transparency: Clearly communicates that the image is not a functional container but a foundational layer.

Clearer Security Practices: Enables security teams and SBOM readers to easily identify the starting point with zero components to evaluate.

Alignment with Industry Norms: Keeps SBOMs consistent with how scratch is viewed in the containerisation and SBOM communities.

Additional Notes:
While introducing a new component type would resolve this specific case, it is essential to ensure that we do not create an excessively long list of types for every use case.

Do you have a solution in mind?
As mentioned, adding a new component type will help address the confusion regarding scratch. However, we should discuss the naming and implementation of this new type to ensure it serves the intended purpose without cluttering the schema.