In SPDX, primary package purpose is an optional field that says what a package is for. The allowed values include FIRMWARE, DEVICE, OPERATING-SYSTEM, LIBRARY and APPLICATION. Embedded teams should set it on every package so readers can tell a chip from the code that runs on it.
Definition
The SPDX 2.3.1 specification describes PrimaryPackagePurpose as an enumerated value. The values listed are APPLICATION, FRAMEWORK, LIBRARY, CONTAINER, OPERATING-SYSTEM, DEVICE, FIRMWARE, SOURCE, ARCHIVE, FILE, INSTALL and OTHER. FIRMWARE is described as a package that provides low level control over a device's hardware.
The same list includes SOURCE for a collection of source files and FILE for a single independently distributable file, with a statically linked binary given as an example of a file. That last point matters in firmware, where a prebuilt binary from a supplier is often exactly that.
Why it helps firmware teams
A firmware SBOM can have hundreds of packages. Without a purpose label, a reader sees a flat list and cannot tell which entry is the bootloader, which is the radio stack, and which is a helper library. A purpose value gives a quick filter.
It also helps when you triage. A vulnerability in a package marked LIBRARY inside your image is a rebuild and a release. One in an entry marked DEVICE may need a supplier conversation or a hardware change.
Choosing a value
| Package | Value to consider |
|---|---|
| Your own application image | FIRMWARE or APPLICATION, whichever matches how you ship it |
| RTOS or embedded Linux image | OPERATING-SYSTEM |
| Vendor prebuilt binary delivered as one file | FILE, or FIRMWARE if it controls hardware |
| Open source library compiled in | LIBRARY |
| The board, module or chip itself | DEVICE |
| A tarball you vendored | ARCHIVE or SOURCE |
When two values fit, pick the one a downstream reader would expect to filter on and be consistent across releases.
Steps
- Decide your mapping once and write it down in a short internal note.
- Set the field in your generator or post-process step, so it is not hand edited per release.
- Check that every package has a value. Unlabelled packages are the ones people ask about.
- Review the mapping when a supplier changes how it delivers code, for example from source to a binary.
Limits
The field is optional, and it describes purpose, not safety or quality. It does not replace exact versions, supplier names, hashes or relationships. Nor does a FIRMWARE label tell a scanner which advisory database entry matches. That still depends on identifiers such as package URLs or CPEs.
Tools differ in how well they read the field, so test your consumer with a sample file before you rely on it in a customer workflow.
Where Safeguard fits
Safeguard produces SBOMs and runs dependency scanning on your code. Setting purpose values for physical parts and supplier binaries is a modelling decision your team owns. You can run a free scan on a repository to see what a generated SBOM looks like.
Quick check
Is primary package purpose required in SPDX 2.3?
It is an optional field. Setting it still makes an embedded SBOM much easier to read.
Can one package have several purposes?
The field holds a single primary purpose. If you ship two different things, model them as two packages.
Sources
Last reviewed: 19 October 2026.
