Document status: ⚠️ DRAFT

[!CAUTION] What you see here is a DRAFT of the Glossary used by the CPAN Security Group (CPANSec). As long as this document is in DRAFT, all of the points and ideas below are suggestions, and open to revision, deletion or amending – by you!

This document is visionary and a proposal

Some aspects of this document – including those related to the role of Open Source Stewards, the Cyber Resilience Act and CE Marking – are presented as suggestions, proposals or visions of a possible future.

Please take this into account when commenting this document.

Legend

[!NOTE]

  • ⚠️ — The definition has problems or errors or may be confusing, and therefore requires correction or additional explanation.
  • ✍️ — Changes have been made to the original definition, mostly for clarity or consistency.

Glossary

Artifact ✍️

[!NOTE] Component and Artifact seem to have overlapping definitions. We recommend using the term Artifact specifically when referring to files (as defined), and Component in other situations. (CPANSec)

  1. (SLSA-2023) An immutable blob of data; primarily refers to software, but SLSA can be used for any artifact.
    • E.g. a file, a git commit, a directory of files (serialized in some way), a container image, a firmware image.

See also: Component.

(Ref: SLSA-2023, CPANSec-2024)

Author

  1. (NTIA-2021) An entity that creates an SBOM.
    • author and supplier will often be different. In the case of SBOMs, the author creates the SBOM. The supplier is the provider of the software included in the SBOM.
  2. (CPANSec-2024) A developer that publishes something as Open Source software.

See also: Author in the Supply-chain SBOM Roles document.

(Ref: NTIA-2021, CPANSec-2024)

Attestation

  1. An authenticated statement (metadata) about a software artifact or collection of software artifacts.
    • E.g. a signed SLSA Provenance file.

(Ref: SLSA-2023)

Build

  1. (SLSA-2023) Process that transforms a set of input artifacts into a set of output artifacts.
    • The inputs may be sources, dependencies, or ephemeral build outputs.
    • E.g. .travis.yml (process) run by Travis CI (platform).

(Ref: SLSA-2023)

CE Marking ⚠️

  1. (CRA-2024-03) A marking by which a manufacturer indicates that a product with digital elements and the processes put in place by the manufacturer are in conformity with the essential requirements set out in EU Cyber Resilience Act, Annex I and other applicable European Union harmonization legislation providing for its affixing.

(Ref: CRA-2024-03)

Chain of custody

  1. (SCVS-2020, CDXAG-2024) Auditable documentation of point of origin as well as the method of transfer from point of origin to point of destination and the identity of the transfer agent.

(Ref: SCVS-2020, CDXAG-2024)

Component ✍️

[!NOTE]

  1. (CPANSec) Component and Artifact seem to have overlapping definitions.
    • Recommendation: use the term Artifact specifically when referring to files (as defined), and Component in other situations.
  1. (CRA-2024-03) Software or hardware intended for integration into an electronic information system.
  2. (NTIA-2021) A unit of software defined by a supplier at the time the component is built, packaged, or delivered. Many components contain sub-components. Examples of components include a software product, a device, a library, or a single file.

See also: Artifact.

(Ref: CRA-2024-03, NTIA-2021, CPANSec-2024)

Component function

  1. (SCVS-2020, CDXAG-2024) The purpose for which a software component exists.
    • Examples of component functions include parsers, database persistence, and authentication providers.

(Ref: SCVS-2020, CDXAG-2024)

Component, second-party ✍️

  1. (CPANSec-2024) Any software component created through the interaction with a second party, including open source, “source available”, and proprietary software where the source is made available for either inspection, use, modification, building or sharing.
    • Open Source software components that an application has as dependencies should be considered as “second-party” components or dependencies, since the application owner has an ongoing relationship with the FOSS component project, by the fact that the owner has accepted the open source project’s license.

(Ref: CPANSec-2024)

Component, third-party ✍️

  1. (SCVS-2020, CDXAG-2024) Any software component not directly created including open source, “source available”, and commercial or proprietary software.
  2. (CPANSec-2024) Any software component not directly created including “source available”, commercial or proprietary software.

(Ref: SCVS-2020, CDXAG-2024, CPANSec-2024)

Component type

  1. (SCVS-2020, CDXAG-2024) The general classification of a software components architecture.
    • Examples of component types include libraries, frameworks, applications, containers, and operating systems.

(Ref: SCVS-2020, CDXAG-2024)

Consumer

CycloneDX ✍️

  1. (SCVS-2020) An OWASP managed software bill of materials specification designed to be lightweight and security-focused.
    • CycloneDX is considered to be one of the three SBOM formats, together with SWID and SPDX.

(Ref: SCVS-2020)

Dependency ⚠️ ✍️

[!CAUTION]

  • (CPANSec-2024) Dependencies may be declared/stated/referenced or included/embedded or assumed/implied/detected, development phase-specific (e.g. developer, build, test, deploy, or runtime-specific), dynamic or static, unresolved or resolved, direct or transitive, or required, recommended or suggested.
    • The NTIA-2021 definition above is therefore not only wrong, but also entirely insufficient — is for any practical purpose useless and should not be used.
    • The SLSA-2023 definition above is preferrable, though it doesn’t sufficiently distinguish between stated, embedded and assumed dependencies.
  1. (SLSA-2023) An Artifact that is an input to a build process but that is not a source.
    • In the SLSA model, it is always a package.
    • E.g. an Alpine package (package) distributed on Alpine Linux (platform).
  2. ⚠️ (NTIA-2021) Characterizing the relationship that an upstream component X is included in software Y.

(Ref: SLSA-2023, NTIA-2021, CPANSec-2024)

Dependency (Direct) ✍️

  1. (SCVS-2020, CDXAG-2024) A software component that is referenced by a program itself.
  2. (CPANSec-2024) A software program, library, plugin, service, resource or component that is required for another software program or component to function as expected.

(Ref: SCVS-2020, CDXAG-2024, CPANSec-2024)

Dependency (Dynamic)

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Transitive) ✍️

  1. (SCVS-2020) A software component that is indirectly used by a program by means of being a dependency of a dependency.
  2. (NTIA-2021) Characterizing the relationship that if an upstream component X is included in software Y and component Z is included in component X then component Z is included in software Y.
  3. (CPANSec-2024) Dependencies of transitive dependencies are also transitive dependencies (it’s dependencies all the way down!).

(Ref: SCVS-2020, NTIA-2021, CPANSec-2024)

Dependency (Embedded, Included, Pre-resolved) ✍️

  1. (CPANSec-2024) A dependency that is supplied as part of a software package, and therefore already resolved by the Author of the package.

(Ref: CPANSec-2024)

Dependency (Pinned at Source) ✍️
Dependency (Resolved at Source) ✍️

Dependency (Assumed, Implied, Phantom, Unstated) ✍️

[!NOTE]

  • FIXME: Expand on this topic
  1. (CPANSec-2024) A dependency that is used but unstated.
    • An implied dependency is a component that is required to perform an action or functionality, but has not been explicitly stated as required.
    • An implied dependency should be considered as a bug in the component, and corrected as soon as possible.
    • If a dependency has to be implied due to lacking capabilities in the tooling used to create the package.
      • This should be considered as a bug in the tooling.

(Ref: CPANSec-2024)

Dependency (Detected during Analysis) ✍️

Dependency (Unresolved, Required) ✍️

  1. (CPANSec-2024) A dependency that that needs to be resolved for a software component to function as expected.
    • Requirements are expected to be resolved by the Builder or Packager of the component.
    • An unresolved dependency has always a version constraint associated with it (implied or explicitly), to be used during dependency resolution.

(Ref: CPANSec-2024)

Requirement ✍️
Pre-Requirement ✍️

Dependency (Resolved during Configuration) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Resolved during Build) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Resolved during Deploy) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Resolved at Runtime) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Pinned during Build) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (In-ecosystem) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Out-of-ecosystem) ✍️

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Service) ✍️

[!NOTE]

  • FIXME: Expand on this topic
  1. (CPANSec-2024) A network service dependency that are required for component to function as expected
  2. (PCISSF-2023) Required by the PCI Software Security Framework version 1.2.1

(Ref: CPANSec-2024, PCISSF-2023)

Dependency (Static)

[!NOTE]

  • FIXME: Expand on this topic
Dependency (Dynamic)

[!NOTE]

  • FIXME: Expand on this topic

Dependency (Virtual)

[!NOTE]

  • (CPANSec) A dependency that is present, but cannot be represented by an actual software package.
    • e.g. The OS kernel and base file-system and services that have to be in place before the first regular package may be installed.
  • FIXME: Expand on this topic

Distributor ⚠️

[!WARNING]

  1. (CPANSec-2024) The Cyber Resilience Act defines a distributor as someone who does not Substantially Modify a package/component.
    • (CRA-2024-03 Article 21, 22) This means if an Importer or Distributor applies a patch with Substantial Modifications, they are to be treated as a manufacturer, including any consequences this may entail.
    • (CPANSec-2024) To disambiguate, we recommend Open Source Supply-chain Roles like this to be referred to as Provider

[!NOTE]

  • FIXME: Expand on this topic
  • FIXME: Confirm with legal counsel after final version of CRA is adopted.
  1. (CRA-2024-03) A natural or legal person in the supply chain, other than the manufacturer or the importer, that makes a product with digital elements available on the Union market without affecting its properties.
  2. (EUBG-2022-3) The distributor is a natural or a legal person in the supply chain, other than the manufacturer or the importer, who makes a product available on the market.
    • Distributors are subject to specific obligations and have a key role to play in the context of market surveillance.

(Ref: CRA-2024-03, EUBG-2022-3, CPANSec-2024)

Provider ✍️

  1. (CPANSec-2024) The Role that is tasked with ensuring a component artifact is available for download by anyone downstream.

(Ref: CPANSec-2024, Distributor)

Downstream

  1. (NTIA-2021) Referring to how a component is subsequently used in other pieces of software at a later stage in the supply chain.

(Ref: NTIA-2021)

Economic operator

  1. (CRA-2024-03) The Manufacturer, the authorised representative, the Importer, the Distributor, or other natural or legal person who is subject to obligations in relation to the manufacture of products with digital elements or to the making available of products on the market in accordance with [the Cyber Resilience Act];

(Ref: CRA-2024-03)

Electronic information system

  1. (CRA-2024-03) A system, including electrical or electronic equipment, capable of processing, storing or transmitting digital data.

(Ref: CRA-2024-03)

End-user

  1. (NTIA-2021) Entity that obtains SBOMs.
    • An entity can be both a supplier and consumer, using components with SBOM data in its own software, which is then passed downstream.
    • An “end-user” consumer (that is not also a supplier) may also be called an operator or a leaf entity.
  2. (EUBG-2022-3) The end user is any natural or legal person residing or established in the European Union, to whom a product has been made available either as a consumer outside of any trade, business, craft or profession or as a professional end user in the course of its industrial or professional activities.
    • Many products covered by European Union product harmonisation legislation are used at work and thus also subject to Union safety at work legislation.

(Ref: NTIA-2021, EUBG-2022-3)

Hardware

  1. (CRA-2024-03) A physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data.

(Ref: CRA-2024-03)

Importer

  1. (CRA-2024-03) A natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the European Union.
  2. (EUBG-2022-3) The importer is a natural or legal person established in the Union who places a product from a third country on the EU market.
    • [Their] obligations build on the obligations of the manufacturer.

(Ref: CRA-2024-03, EUBG-2022-3)

Life-cycle Phase

  1. (NTIA-2021) The stage in the software life-cycle where an SBOM is generated (e.g. from source, at the time of build or packaging, or from a built executable).

(Ref: NTIA-2021)

Making available on the market

[!NOTE]

  • FIXME: Expand on this topic
  • FIXME: Add some clarification regarding Manufacturers, Importers, Distributors and Open Source Stewards.
  1. (CRA-2024-03) The supply of a product with digital elements for distribution or use on the European Union market in the course of a commercial activity, whether in return for payment or free of charge.
  2. (EUBG-2022) A product is made available on the market when supplied for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge.
    • The concept of making available refers to each individual product.
    • A product is made available on the market when supplied for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge.
    • Such supply includes any offer for distribution, consumption or use on the Union market which could result in actual supply in relation to products already manufactured (e.g. an invitation to purchase, advertising campaigns).

(Ref: CRA-2024-03, EUBG-2022)

Manufacturer

  1. (CRA-2024-03) Any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment, monetisation or free of charge.
  2. (EUBG-2022-3) The manufacturer is any natural or legal person who manufactures a product or has a product designed or manufactured, and places it on the market under his own name or trademark.
    • The manufacturer is responsible for the conformity assessment of the product and is subject to a series of obligations including traceability requirements.
    • When placing a product on the Union market, the responsibilities of a manufacturer are the same whether he is established outside the European Union or in a Member State.
    • The manufacturer must cooperate with the competent national authorities in charge of market surveillance in case of a product presenting a risk or being non-compliant.

(Ref: CRA-2024-03, EUBG-2022-3)

Open-source software

  1. (NTIA-2021) Software that can be accessed, used, modified, and shared by anyone.

(Ref: NTIA-2021)

Open-source software steward ⚠️

[!NOTE]

  • FIXME: Expand on this topic
  • FIXME: This is a definition that was added to the CRA on 2023-12-20, meaning it may change in the final version of the regulation.
  1. (CRA-2024-03) Any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products.

(Ref: CRA-2024-03)

Package ⚠️ ✍️

  1. (SLSA-2023) [An] Artifact that is “published” for use by others.
    • In the model, it is always the output of a build process, though that build process can be a no-op.
    • E.g. a Docker image (package) distributed on DockerHub (platform).
    • E:g. a ZIP file containing source code is a package, not a source, because it is built from some other source, such as a git commit.
  2. (CPANSec-2024) An identifiable unit of software intended for distribution, ambiguously meaning either an “artifact” or a “package name”.
    • Only use this term when the ambiguity is acceptable or desirable.

(Ref: SLSA-2023, CPANSec-2024)

Package manager ✍️

  1. (SCVS-2020, CDXAG-2024) A distribution mechanism that makes software artifacts discoverable by requesters of a specific package ecosystem.
  2. (CPANSec-2024) A distribution mechanism that makes software artifacts discoverable and installable by users of a specific package ecosystem.

(Ref: SCVS-2020, CDXAG-2024, CPANSec-2024)

Package URL (PURL)

  1. (SCVS-2020, CDXAG-2024) An ecosystem-agnostic specification which standardizes the syntax and location information of software components.
    • (CPANSec-2024) The PURL spec can be found in GitHub. As it is an open source project it is constantly evolving.

(Ref: SCVS-2020, CDXAG-2024, CPANSec-2024)

Pedigree

  1. (SCVS-2020, CDXAG-2024) Data which describes the lineage and/or process for which software has been created or altered.
  2. (NTIA-2021) Data on the origins of components that have come together to make a piece of software and the process under which they came together. This could include data beyond the minimum elements, such as compiler details and settings.

(Ref: SCVS-2020, CDXAG-2024, NTIA-2021)

Placing on the market

  1. (CRA-2024-03) The first making available of a product with digital elements on the Union market.
  2. (EUBG-2022) A product is placed on the market when it is made available for the first time on the Union market.
    • According to Union harmonisation legislation, each individual product can only be placed once on the Union market. * Products made available on the market must comply with the applicable Union harmonisation legislation at the moment of placing on the market.

(Ref: CRA-2024-03, EUBG-2022)

Point of origin ⚠️ ✍️

  1. (SCVS-2020, CDXAG-2024) The supplier and associated metadata from which a software component has been procured, transmitted, or received.
    • Package repositories, release distribution platforms, and version control history are examples of various points of origin.
  2. (CPANSec-2024) Discouraged term – Confusing definition, having common meaning with both Source, Manufacturer and Distributor.

(Ref: SCVS-2020, CDXAG-2024, CPANSec-2024)

Presumption of Conformity

[!CAUTION]

  • FIXME: Find a better definition! The one in the Blue Guide is more of an explanation with context. In the meantime, please read the Blue Guide text.
  1. (EUBG-2022)
    • The terms ‘standard’, ‘national standard’, ‘European standard’, ‘harmonised standard’ and ‘international standard’ are subject to concrete definitions in Article 2 of Regulation (EU) No 1025/2012.
    • Standards are technical specifications and are therefore useful and effective in promoting and disseminating good technical practises and technical solutions.
    • Standards are in themselves of voluntary application.
    • Harmonised standards are European standards adopted on the basis of a request made by the Commission for the application of Union harmonisation legislation.
    • If references of harmonised standards have been published in the Official Journal of the European Union (OJEU), they provide a presumption of conformity with the essential or other legislative requirements they aim to cover.

Procurement ✍️

  1. (SCVS-2020, CDXAG-2024) The process of agreeing to terms and acquiring software or services for later use.
    • (CPANSec-2024) This includes agreeing to Open Source licenses.

(Ref: SCVS-2020, CDXAG-2024, CPANSec-2024)

Product with digital elements

  1. (CRA-2024-03) A software or hardware product and its Remote Data Processing solutions, including software or hardware components being placed on the market separately.

(Ref: CRA-2024-03)

Provenance ✍️

  1. (SCVS-2020, CDXAG-2024) The chain of custody and origin of a software component.
    • Provenance incorporates the point of origin through distribution as well as derivatives in the case of software that has been modified.
  2. (NTIA-2021) Data about the chain of custody of the software and all of the constituent components, potentially including data about the authors and locations from where the components were obtained.

(Ref: SCVS-2020, NTIA-2021, CPANSec-2024)

Remote Data Processing

  1. (CRA-2024-03) Data processing at a distance the software for which is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions.

(Ref: CRA-2024-03)

Second-party component ✍️

SBOM (Software Bill of Materials)

  1. (CRA-2024-03) A formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.
  2. (SCVS-2020, CDXAG-2024) A complete, formally structured, and machine-readable inventory of all software components and associated metadata, used by or delivered with a given piece of software.
  3. (NTIA-2021) A formal record containing the details and supply chain relationships of various components used in building software.
    • Software developers and vendors often create products by assembling existing open source and commercial software components.
    • The SBOM enumerates these components in a product.

(Ref: CRA-2024-03, SCVS-2020, CDXAG-2024, NTIA-2021)

SBOM Attributes

SBOM Author Name (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

SBOM Timestamp (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

SBOM Type (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

SBOM Primary Component (Attribute)

  1. (CISA-2024-9) The Primary Component, or root of dependencies, is the subject of the SBOM or the foundational component being described in the SBOM.
    • […] component attributes […] are also identified for this component, just as they are for the direct and transitive components.

(Ref: CISA-2024-9)

Component Name (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

Version (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

Supplier Name (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

Cryptographic Hash (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

Unique Identifier (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

Relationships (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

License (Attribute)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

[!NOTE]

  • FIXME: Expand on this topic

(Ref: CISA-2024-9)

SBOM Roles

  1. (CPANSec-2024) A person, agent or actor that does something with an SBOM document, or with specific metadata attributes in an SBOM document.
    • This may include operations like Creating, Updating, Verifying, Censoring or Sharing SBOM documents or attributes.
  2. (CISA-2024-3) “Data is only good if it is in the hands of the right people.”

(Ref: CISA-2024-3)

SBOM Assembler (Role) ✍️

  1. (CPANSec-2024) An 🟨 SBOM Author (Non-authoritative)

(Ref: CPANSec-2024)

SBOM Author (Authoritative) (Role) ✍️

[!NOTE]

  1. (CPANSec-2024) SBOM Authors who are not authoritative sources, but instead gather SBOM metadata from different dependencies, may be referred to as an SBOM Assembler.
  2. (CPANSec-2024) SBOM Authors may also collect, assemble, update, or annotate SBOM metadata — They make sure the metadata and related artifacts are Current.
    • They may for example collect SBOMs throughout build dependency resolution, and assemble (merge), translate (transform), to produce SBOMs for analysis or audit purposes. (NTIA-2021, “Transform” category, paraphrased)
  3. (CPANSec-2024) An SBOM Author who is tasked with removing (censoring) sensitive information from SBOM documents may be called SBOM Censor
  1. (CPANSec-2024) 🟥 SBOM Author (Authoritative).
    • An authoritative source of an SBOM, or an SBOM metadata attributes.
  2. (CISA-2024-3) Creates an SBOM.
  3. (CPANSec-2024) SBOM Authors create, define, or sign SBOM metadata — They make sure the attributes and related artifacts Exist.
    • This mostly means authoritative metadata attributes as laid out in the different Supply-chain Roles.
    • In addition to attributes encountered throughout the supply-chain, they care about the attributes listed in the table below.
    • They may edit SBOM files manually or use tooling for analyzing artifacts, or ideally – use have SBOMs generated automatically as part of a build process. (NTIA-2021, “Produce” category)

(Ref: CISA-2024-3, NTIA-2021, CPANSec-2024)

SBOM Author (Non-authoritative) (Role)

  1. (CPANSec-2024) 🟨 SBOM Author (Non-authoritative)
  2. (CPANSec-2024) Someone that gathers, assembles or updates SBOMs from different sources into a new SBOM.
    • This is a informal Role separate from “SBOM Author” for clarifying the responsibility when the Role intends to gather, assemble or update metadata attributes, instead of being the authoritative creator of an attributes.
    • This assumes some attributes may be in need of updating as an SBOM is passed down a supply-chain – for example to correct upstream assumptions like ‘Download location’, add missing attributes, or update the list of resolved dependencies.
    • The intention is to distinguish between “SBOM Author” and “SBOM Assembler” in the same way as one distinguishes between “Create” and “Update” in CRUD – to clarify responsibilities and expectations for who is the original source of some metadata attributes.

(Ref: CISA-2024-3, NTIA-2021, CPANSec-2024)

SBOM Distributor (Role)

  1. (CPANSec-2024) 🟩 SBOM Distributor.
    • SBOM Distributor roles distribute, curate, or index SBOM metadata — They make sure the metadata and related artifacts are made Available to others.
    • They don’t have any specific metadata attributes that are commonly used across the different supply-chain consumer roles, beyond ensuring that SBOMs are available for others to use and refer to.
  2. (CISA-2024-3) Receives SBOMs for the purpose of sharing them with SBOM Consumers or other Distributors.
  3. (CISA-2023) Additionally, an SBOM Distributor may care about the following activities.
    • Discovery: Mechanism used by the consumer to know the SBOM exists and how to access it.
    • Access: Access control mechanisms used by the author or provider to regulate who can view or use an SBOM.
    • Transport: Mechanism provided by the author or distributor to transfer an SBOM. Also, the action of the consumer receiving an SBOM.

(Ref: CISA-2023, CISA-2024-3, CPANSec-2024)

SBOM Consumer (Role)

  1. (CPANSec-2024) 🟦 SBOM Consumer.
    • SBOM Consumer roles gather, inspect, analyze, aggregate or verify SBOM metadata — They make sure metadata and related artifacts are Useful, Complete, Correct or Compliant.
    • They don’t have any specific metadata attributes that are commonly used across the different supply-chain Consumer roles.
  2. (CISA-2024-3) Receives the transferred SBOM.
    • This could include roles such as third parties, authors, integrators, and end users.
  3. (NTIA-2021, “Consume” category) They may view SBOM files to understand the contents, and use this information to support decision making & business processes, or to compare and contrast SBOMs to discover significant changes or vulnerabilities.

(Ref: CISA-2024-3, NTIA-2021, CPANSec-2024)

SBOM Censor (Role)

  1. (CPANSec-2024) 🟪 SBOM Censor.
    • An SBOM Author that removes or anonymizes sensitive metadata from an SBOM before distribution.

(Ref: CPANSec-2024)

SBOM Types

  1. (CPANSec-2024) Software Bill of Materials variations, produced under certain circumstances.

(Ref: CPANSec-2024)

Design SBOM (Type)

  1. (CISA-2023) SBOM of intended, planned software project or product with included components (some of which may not yet exist) for a new software artifact.

(Ref: CISA-2023)

Source SBOM (Type)

  1. (CISA-2023) SBOM created directly from the development environment, source files, and included dependencies used to build an product artifact.

(Ref: CISA-2023)

Build SBOM (Type)

  1. (CISA-2023) SBOM generated as part of the process of building the software to create a releasable artifact (e.g., executable or package) from data such as source files, dependencies, built components, build process ephemeral data, and other SBOMs.

(Ref: CISA-2023)

Analyzed SBOM (Type)

  1. (CISA-2023) SBOM generated through analysis of artifacts (e.g., executables, packages, containers, and virtual machine images) after its build.
    • Such analysis generally requires a variety of heuristics.
    • In some contexts, this may also be referred to as a “3rd party” SBOM.

(Ref: CISA-2023)

Deployed SBOM (Type)

  1. (CISA-2023) SBOM provides an inventory of software that is present on a system.
    • This may be an assembly of other SBOMs that combines analysis of configuration options, and examination of execution behavior in a (potentially simulated) deployment environment.

(Ref: CISA-2023)

Runtime SBOM (Type)

  1. (CISA-2023) SBOM generated through instrumenting the system running the software, to capture only components present in the system, as well as external call-outs or dynamically loaded components.
    • In some contexts, this may also be referred to as an “Instrumented” or “Dynamic” SBOM.

(Ref: CISA-2023)

Software

  1. (CRA-2024-03) The part of an electronic information system which consists of computer code.

(Ref: CRA-2024-03)

Software Bill of Materials (SBOM)

Software Identification (SWID)

  1. (SCVS-2020) An ISO standard that formalizes how software is tagged.
    • SWID is considered to be one of three SBOM formats, together with CycloneDX and SPDX.

(Ref: SCVS-2020)

Software Package Data Exchange (SPDX)

  1. (SCVS-2020) A Linux Foundation project which produces a software bill of materials specification and a standardized list of open source licenses.
    • SPDX is considered to be one of three SBOM formats, together with CycloneDX and SWID.

(Ref: SCVS-2020)

Source ⚠️ ✍️

  1. (SLSA-2023) An artifact that was directly authored or reviewed by persons, without modification.
    • It is the beginning of the supply chain; we do not trace the provenance back any further.
    • E.g. a git commit (source) hosted on GitHub (platform).

(Ref: SLSA-2023, CPANSec-2024)

SPDX (Software Package Data Exchange)

Substantial Modification

  1. (CRA-2024-03) A change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential requirements set out in the EU Cyber Resilience Act, Annex I, Part I, or which results in a modification to the intended purpose for which the product with digital elements has been assessed.
    • Where products with digital elements are subsequently modified, by physical or digital means, in a way that is not foreseen by the manufacturer […], the modification should be considered as substantial. (CRA-2024-03, Recital 38)
    • Security updates are not Substantial Modifications. (CRA-2024-03, Recital 39)

(Ref: CRA-2024-03)

Supplier ⚠️

[!CAUTION]

  • (CPANSec-2024) The term ‘Supplier’ is not well defined, and should be either avoided in favor of a more precise term, or otherwise be disambiguated.
  1. (NTIA-2021) An entity that creates, defines, and identifies components and produces associated SBOMs.
    • A supplier may also be known as a manufacturer, vendor, developer, integrator, maintainer, or provider.
    • Ideally, all suppliers are also authors of SBOMs for the suppliers’ components.
    • Most suppliers are also consumers.
    • A supplier with no included upstream components is a root entity.
  2. (CDXAG-2024) The name of an entity that creates, defines, and identifies components.

(Ref: NTIA-2021, CDXAG-2024)

SWID (Software Identification)

Third-party component ✍️

Transitive Dependency

Vendor

References and terms

This glossary is partly based on terms from the following sources.

About this document

You may use, modify and share this file under the terms of the CC-BY-SA-4.0 license.

Acknowledgements

Several people have been involved in the development of this document

  • Salve J. Nilsen (main author)
  • Josh Bressers