An SPDX 3.0 profile is a named set of classes, properties and rules for one domain, such as software, security or licensing. A document lists the profiles it follows in profileConformance. Declaring one is a claim that all contained elements meet that profile's restrictions. Declare only what you have actually checked.
What a profile is
SPDX 3.0 is organized as a core model plus profiles. The specification explains that a profile consists of a namespace that may add properties and classes to the Core profile for its domain, and may add restrictions on existing properties and classes defined elsewhere.
That last part matters. A profile is not just a vocabulary. It can make optional things required. Claiming it means you met those requirements.
The ten profile identifiers
The 3.0.1 specification enumerates the valid values of its profile identifier type. These are the entries it lists.
| Identifier | The element follows the specification for |
|---|---|
| core | The Core profile |
| software | The Software profile |
| security | The Security profile |
| lite | The Lite profile |
| simpleLicensing | The Simple Licensing profile |
| expandedLicensing | The Expanded Licensing profile |
| build | The Build profile |
| ai | The AI profile |
| dataset | The Dataset profile |
| extension | The Extension profile |
The specification page for the Security profile describes it simply as capturing security related information. The Software profile is the one that covers packages, files and snippets and the SBOM class.
What declaring conformance means
The specification says that if the creator of a collection of elements includes a profile in the profileConformance list, they are claiming that all contained elements conform to all restrictions defined for that profile.
So the claim is about every element, not a sample. That is a strong statement for a tool to make, and it should be backed by validation. A generator that writes the list of profiles from a fixed template, without checking, is making claims it cannot support.
A decision guide
- Include core, since other profiles add to it.
- Include software for a normal software bill of materials.
- Include security only if your document carries vulnerability or VEX style assessments and you validated them against that profile.
- Include lite if you deliberately produce the reduced form and want consumers to know that.
- Include licensing profiles only if you use their classes.
- Include ai or dataset only for AI and data components, as relevant.
- Re-check the list when you change what the generator emits.
What consumers should do
A consumer that reads profileConformance can decide how to treat the file. If it expects software and security data, it can reject a file that lists neither. It should not assume the claim is true without validation, though. Run a validator for the profiles you rely on, and treat a mismatch as a quality problem to report back.
Plan also for files in older SPDX versions from suppliers who have not moved yet. See how SPDX 3.0 relates to AI BOMs.
Try it yourself
Click through it at your own pace, or open it full screen. See the inventory a software profile would describe: components, versions and relationships.
Where this fits
Profiles tell a consumer what to expect from a document before parsing it deeply. Safeguard offers SBOM and dependency scanning, and the free scan lets you see inventory output for a real project.
Quick check
Does listing a profile make a document conformant?
No. Listing is a claim by the creator that all elements conform. Validation is what backs it up.
Is the lite profile a different format?
It is one of the profile identifiers in the same model, for elements that follow the Lite profile specification.
Sources
Last reviewed: 19 October 2026.
