Supply Chain Security Glossary
This glossary defines practical terms used across the handbook. It covers assurance, evidence, practices, controls, lifecycle, technology options, and verification language. It is intentionally practical rather than standards-body-specific.
| Term | Practical definition |
|---|---|
| Assurance | Confidence that a supply chain security practice or control is operating as intended. |
| Assertion | A claim that something is true without supporting reviewable evidence. |
| Attestation | A claim, often signed and based on measurements or protected state, about properties or current state of a device, component, platform, or service. Attestation needs baselines, policies, trust anchors, and interpretation; it does not automatically prove vulnerability status, provenance, or compliance. |
| Attestation evidence | Evidence produced for appraisal by a verifier, often about measured or current state. |
| Audit evidence | Evidence retained to show whether controls operated for a decision, period, product, supplier, or lifecycle event. Audit records do not prove security unless they connect controls, evidence, verification, and decisions. |
| Boot manager | Software or firmware that manages the initial boot process, boot target selection, verification or measurement, recovery paths, configuration, and handoff to the next boot stage, operating system, hypervisor, or embedded application. |
| Chain of custody | Records showing how an item moved through suppliers, logistics, integrators, repairers, owners, or operators. |
| Chain of trust | A sequence of verification or measurement relationships where each stage depends on an earlier trusted stage, root of trust, or trust anchor. A chain of trust still needs documented scope, policy, and evidence to support an assurance decision. |
| Component transparency | Visibility into software, firmware, hardware, or other components present in a product or platform. |
| Documented process | A described process with owner, scope, cadence, and decision points, but not necessarily produced artifacts. |
| Evidence | Any artifact, record, claim, measurement, certificate, attestation, manifest, log, report, or audit material that can help decide whether a practice is operating. |
| Evidence package | A collected set of artifacts, records, context, verification notes, gaps, and exceptions assembled for a decision. |
| Exception | A visible gap, deviation, missing artifact, failed check, expired record, stale claim, or unresolved issue that needs review. |
| Freshness | Whether evidence is recent enough for the decision and has not been superseded by product, supplier, vulnerability, update, or lifecycle changes. |
| Hardware-rooted identity | Identity evidence bound to hardware or a protected trust anchor rather than only to a process or document. |
| Identity evidence | Evidence that identifies a device, product, component, platform, supplier, service, or issuer. Identity alone does not prove current integrity, vulnerability status, safe configuration, or update history. |
| Integrity evidence | Evidence that a product, component, firmware load, configuration, or artifact matches an expected state or has not changed unexpectedly. |
| Lifecycle assurance | Assurance that is retained and updated across product lifecycle stages rather than checked only once. |
| Lifecycle-retained evidence | Evidence retained, refreshed, and reused across deployment, update, repair, transfer, audit, and decommissioning. |
| Lifecycle-state record | Evidence about whether an asset is active, accepted, deployed, repaired, transferred, revoked, retired, or decommissioned. Lifecycle-state records do not prove technical integrity unless connected to integrity evidence. |
| Measured boot | Recording cryptographic measurements of boot components or platform state so a verifier can compare reported state with reference values. Measured boot supports attestation and appraisal, but by itself does not prevent unverified code from executing. |
| Platform Certificate | A certificate or related artifact that can help describe platform identity and composition in some architectures. |
| Provenance | Information about origin, ownership, custody, manufacturing, sourcing, or transfer history. |
| Provenance evidence | Evidence about origin, custody, sourcing, manufacturing, logistics, repair, transfer, or chain of responsibility. Provenance records may not reveal hidden sub-tier risk unless the chain and evidence requirements are defined. |
| Produced artifact | A record, manifest, certificate, SBOM/xBOM, log, measurement, attestation, report, or other output generated by a control. |
| Product/version binding | The link between evidence and the specific product, component, firmware, software, configuration, release, or version under review. |
| Reference integrity measurement | Expected measurement or reference value used to compare current or reported state. |
| Reference value | An expected value, measurement, manifest, baseline, or policy input used to appraise measured or reported state. |
| Relying party | The person, team, customer, service, or workflow that makes a decision based on evidence or verifier results. |
| Retention | Keeping evidence available, access-controlled, explainable, and tied to the decision it supports for as long as later lifecycle, audit, vulnerability, transfer, or decommissioning decisions may rely on it. |
| Revocation | Withdrawal or invalidation of a credential, certificate, key, authorization, product state, access right, or evidence claim. |
| Risk acceptance | A documented decision to proceed despite a gap, exception, residual threat, or evidence limitation, with owner, scope, rationale, and review point. |
| Root of trust | A foundational component, protected environment, key, or immutable starting point that other verification, measurement, or reporting decisions depend on. A root of trust is only useful when its scope, assumptions, and lifecycle handling are understood. |
| SBOM | Software Bill of Materials, a transparency artifact describing software components and dependencies. |
| Scope binding | The link between evidence and the product, service, supplier, component, release, lifecycle stage, control, or decision it covers. |
| Secure boot | In this handbook, we avoid using this as a generic umbrella when "verified boot" or "measured boot" is more precise. In some contexts, especially UEFI, Secure Boot refers to a specific verified-boot implementation. |
| Supersession | Replacement of evidence by newer evidence because a product, version, vulnerability status, update, credential, or lifecycle state changed. |
| Transparency artifact | A software, firmware, hardware, service, dependency, vulnerability, or composition record such as an SBOM or xBOM. It is a transparency input, not proof of secure design, safe configuration, authenticity, or remediation by itself. |
| Technology implementation | The concrete product, component, profile, version, configuration, integration, service, or workflow that realizes a named technology option. Standards, protocols, formats, and architecture patterns only support assurance when the implementation scope and evidence path are clear. |
| Trusted Platform Module | A TCG specification ecosystem and implementation category for hardware-rooted protected keys, measurements, sealing, and attestation. Real systems may use discrete TPM chips, integrated TPMs, or firmware TPMs such as Intel PTT or AMD fTPM; assurance depends on provisioning, credentials, firmware state, integration, and verifier policy. |
| Trust anchor | A root of trust, key, credential, hardware component, or controlled environment that other verification decisions rely on. |
| Update record | Evidence about update approval, authorization, signing, delivery, installation, failure, rollback, recovery, or current update state. Update evidence does not prove provenance or identity by itself. |
| Verifiable artifact | A produced artifact whose origin, integrity, freshness, scope, or consistency can be checked by the recipient. |
| Verifier | A person, team, service, or tool that checks evidence against policy, reference values, trust anchors, or acceptance criteria. |
| Verified boot | Cryptographic verification of boot components before execution, typically using a chain of trust anchored in protected verification material. Unlike measured boot, verified boot is an enforcement mechanism: failed verification should prevent normal execution or trigger a controlled recovery or degraded state. |
| Vulnerability status | A record of whether a vulnerability affects a product, component, release, or service, and what action or risk decision applies. Vulnerability records do not prove remediation unless connected to product versions, update records, and verification. |
| xBOM | A broader bill-of-materials concept that may cover software, firmware, hardware, cryptographic assets, services, or other component types. |