For most third-party packages, set the CycloneDX component type to library. Use framework if the package has key framework features, application for a standalone program or when you cannot tell, and container, operating-system or firmware for those things. The type field is required, so every component needs one.
What the type field is for
In CycloneDX 1.6, every component must carry a type and a name. The type tells a reader what kind of thing the entry is, which changes how it is triaged. A vulnerable library in a service is handled differently from a vulnerable base image or a firmware blob.
The allowed values in the 1.6 JSON schema are application, framework, library, container, platform, operating-system, device, device-driver, firmware, file, machine-learning-model, data and cryptographic-asset.
How to choose, value by value
| Type | Use it for |
|---|---|
| library | Reusable code your product links or imports, such as a parsing or HTTP package |
| framework | A library that also has key features of a framework |
| application | A standalone program, or the default when nothing more specific fits |
| container | A packaging and runtime format that isolates software through virtualization |
| platform | A runtime that interprets or executes software, such as a bytecode runtime |
| operating-system | An OS, whatever the deployment model |
| firmware, device | Embedded code and the physical hardware it runs on |
| file | A single file, often listed with a hash |
The spec itself gives the tie-breaker for libraries. It says all third-party and open source reusable components will likely be a library, that a library with key framework features should be a framework, and that library is recommended when the answer is unknown.
For software components with no better classification, the spec says to use application.
Common mistakes
Labeling everything application. It is the spec's fallback, but if your whole inventory says application, a reader cannot separate your own service from the packages inside it.
Putting the base image as a library. A container image and its operating system packages describe different layers. Record the image as a container and the distribution as operating-system, then list the packages beneath.
Skipping type because a tool left it blank. The field is required, so a file without it will fail schema validation. Treat that as a signal to fix the generator settings, not to patch by hand.
Hardware gets two entries. The spec says a hardware device that contains firmware should include a component for the hardware itself and another of type firmware or operating-system.
A quick way to audit your own file
Count components by type. A healthy application SBOM is mostly library entries, a handful of framework entries, one application at the root, and possibly a container and operating-system pair. If you see hundreds of application entries, the generator is defaulting. If you see zero container entries for a containerized product, the image layer was probably skipped.
Safeguard can generate SBOMs and run dependency scanning across your repositories, so the fields discussed here are checked on real projects instead of by hand. You can try the free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo, click through the component list, and look at how each package is identified and what is missing.
Click through it at your own pace, or open it full screen.
Quick check
Is component type required in CycloneDX?
Yes. In the 1.6 JSON schema both type and name are required on every component.
What type should an open source package get?
Library is the recommended value, unless it has key framework features, in which case use framework.
Sources
Last reviewed: 19 October 2026.
