Composition and generation
| Term | Definition | Practical guide |
|---|---|---|
| SBOM | A structured inventory of software composition for a defined target and observation context. | Explore → |
| Component | An independently tracked unit of software. Granularity can vary: package, library, file or another defined unit. | Explore → |
| Direct dependency | A component explicitly required by the target product or component. | Explore → |
| Transitive dependency | A dependency reached through another dependency. It can affect the target without being chosen directly. | Explore → |
| Dependency graph | Nodes representing components and edges recording dependency relationships. Shared nodes and cycles mean it is not always a tree. | Explore → |
| Provenance | Evidence about origins and how software or inventory data was produced. Preserve its source and context. | Explore → |
| Known unknown | A documented information gap. It is different from absent data or an affirmative statement that no dependency exists. | Explore → |
| BOM completeness | Coverage relative to a declared target, scope and method. A larger component count does not establish completeness. | Explore → |
| Generation context | The lifecycle point and available evidence used to create an inventory, such as before build, build or after build. | Explore → |
| Software supply chain | The producers, components, tools and delivery relationships involved in creating and operating software. | Explore → |
| Package manager | A tool that resolves, retrieves and manages software packages. Resolved output can be useful generation evidence. | Explore → |
| Build artifact | An output such as an executable, package, firmware image or container. Bind inventories to exact artifacts. | Explore → |
| Release binding | The explicit association between an inventory and an identified product version, variant and artifact. | Explore → |
| Inventory revision | A change to the inventory data, which can occur without changing the underlying software release. | Explore → |
| Normalization | Resolving and organizing identities and relationships for use across inventories while retaining original evidence. | Explore → |
Standards and identifiers
| Term | Definition | Practical guide |
|---|---|---|
| SPDX | System Package Data Exchange: an open BOM data model with profiles for software and other information. Stable 3.0.1 is used in this edition. | Explore → |
| CycloneDX | An open BOM specification from the OWASP project. Published version 1.7 is used in this edition. | Explore → |
| SWID | Software Identification tags: software identity metadata referenced among NTIA’s 2021 automation options. Assess real receiving-tool support. | Explore → |
| PURL | Package-URL: ecosystem-aware package identification syntax, standardized in ECMA-427. It is not an SBOM format. | Explore → |
| CPE | Common Platform Enumeration: structured naming used for product/platform identification, including vulnerability correlation. | Explore → |
Security and assurance
| Term | Definition | Practical guide |
|---|---|---|
| VEX | Vulnerability Exploitability eXchange: a product-context vulnerability-status assertion. | Explore → |
| CVE | Common Vulnerabilities and Exposures: identifiers for vulnerability records. A CVE identifier does not prove a match applies to your product. | Explore → |
| SCA | Software Composition Analysis: analysis capabilities commonly concerned with third-party components, vulnerabilities and licenses. | Explore → |
| SSDF | NIST Secure Software Development Framework: secure development practices. This build distinguishes final 1.1 from draft 1.2. | Explore → |
| Attestation | An attributable assertion about software, a process or evidence. Its trust and scope need evaluation. | Explore → |
| Exploitability | Whether a vulnerability can be exploited in a specified context; inventory membership alone does not answer it. | Explore → |
| Applicability assessment | A decision about whether a candidate vulnerability affects the identified product and configuration. | Explore → |
Buying and implementation
| Term | Definition | Practical guide |
|---|---|---|
| Acceptance test | A defined observable condition a supplier’s delivery needs to satisfy for the buyer to accept it. | Explore → |
A delivery can be standard, configured, custom, provided by a partner, on the roadmap or unavailable. These categories describe implementation responsibility and current capability; they are not quality scores. A requirement becomes useful when it includes scope, evidence and an acceptance condition.
Use definitions with their context
When exchanging data, use the exact vocabulary of the selected specification and version. A glossary definition is explanatory; it does not override a schema, contractual definition or legal provision.
When procuring software, define ambiguous units such as application, project, scan and inventory revision in the agreement. A shared technical definition can still conceal a different billing interpretation. Preserve both the technical meaning and the commercial unit.
Primary sources
- NTIA · Framing Software Component Transparency (2021)Multistakeholder guidance
- Ecma International · ECMA-427 Package-URLStandard
- SPDX · Stable specification 3.0.1Published specification
- CycloneDX · Specification overviewPublished specification
- NIST · SSDF 1.1, SP 800-218Final government guidance
- NIST · SSDF 1.2, SP 800-218 Rev. 1Initial public draft