SBOM may contain data covering many different use cases and scenarios (e.g. license compliance, supply chain security). In SPDX version 2.X, a monolithic design for all the information which led to unnecessary complexity for users interested in a small set of use cases. To solve this, we’re introducing the concept of profiles in SPDX 3.0.
On the surface, profiles are pretty straight forward – they are a way of organizing a specification that covers a broad array of use cases into “profiles” more specific to what a specific producer or consumer of SPDX data may be interested in. Each profile contains only the parts of the specification that are associated with the relevant use cases and scenarios. For example, security professionals may be interested in the security profile while legal compliance professionals may be interested in the legal profile.
What is a Profile
In order to make the best use of profiles, it is important to separate out 3 different profile related concepts:
- Profile conformance points
- Profile workgroups
- Profile namespaces
Profile conformance points
The profile conformance point defines the requirements for SPDX data to be considered valid for that profile. This allows a producer of SPDX data to state that they intend for the SPDX data to be used in the context of their profiles and they are asserting that the data includes all the required fields for that purpose. The consumer of SPDX data can quickly determine which profile(s) the producer intended to support and can properly validate the SPDX data. The profile conformance points are defined in the SPDX spec and are included in various schema artifacts to make it easier for those writing software to produce valid output and validate the SPDX input.
A simple profile conformance point is the Licensing profile which requires all packages to have a concluded license. The package concluded license is optional in the Core and Software profiles.
Profile workgroups
Profile workgroups are how we organize our work in the SPDX community. We have a very large and diverse community with many different interests. Each workgroup consists of individuals with interest and expertise in the profile domain. The output of the workgroups are the profile namespace definitions and the profile compliance points specification.
Examples of the different workgroups can be found in the SPDX meetings repo.
Profile namespaces
A profile namespace is a way of organizing the specification by profile. The specification consists of type definitions (classes and properties, for those of you with an object oriented background). Each type definition belongs to a namespace. This allows you to focus on the type definitions of most interest to you – and more importantly, ignore those type definitions you’re not interested in. It’s a bit like being able to look up the right chapter in a text book.
The bigger picture: profiles in a world of BOMs
So how do these profiles relate to different types of Bills of Materials (e.g. SaaSBOMs, HBOMs, DataBOMs, AIBOMs)? Profiles and BOM types tend to be highly correlated since the BOM type is just an expression of a profile’s output. If a creator of SPDX data indicates that it supports the AI profile, you can be confident it contains the data for an AI BOM. One difference to separate BOMs for different types, however, is that the SPDX data can include multiple profiles. This reduces the need to provide duplicate data when producing multiple BOM types for the same system (e.g. repeating the same file level information if it is used by more than one profile). If you want, you can use the profile namespaces to filter out everything except the BOM data you’re interested in.
For further reading, check out the SPDX 3.0 profile use cases and overviews.