Components

After import, each entry in your SBOM is a component record. Components are first-class items, not rows in a file, so they carry identity and history and connect to the rest of your work.

What a component records

A component captures the details that matter for managing a dependency:

• Name and version — which package, at which release
• Package URL (purl) — the precise, ecosystem-aware identifier
• Supplier — who provides the component
• License — the license it’s distributed under (the basis for license policy, covered in part two)

Together these answer the questions an audit or a security review asks: what’s in the product, where it came from, and under what terms.

The dependency picture

The component list is the inventory of everything your software depends on — direct and transitive. Having it as structured records, rather than a static document, means you can search it, review it, and act on it: find every place a given package is used, or every component from a particular supplier.

Components on the thread

Because components are items, they join the thread. A component can be linked to the risks it introduces and the tests or controls that address them, so a third-party part isn’t an island — it’s connected to the same analysis as your own requirements and architecture. This is what lets a supply-chain concern flow into your risk picture (see Linking risk).

From inventory to analysis

An accurate component inventory is the foundation everything else builds on. The next step is checking those components against known issues — covered in Vulnerabilities — and against your license policy.