SBOM Roles in a supply-chain
- Document status: ⚠️ DRAFT
- About this document
- The relation between Supply-chain Roles and SBOM Roles
- SBOM Roles
- Color-coding legend for SBOM Roles
- An idealized Open Source supply-chain graph
- Supply-chain Ecosystems and Environments
- Supply-chain roles and metadata
- Are you… a Manufacturer, Steward or Author?
- References
- Commentary and FIXME points (FIXME: remove when done)
- License and use of this document
Document status: ⚠️ DRAFT
[!CAUTION] What you see here is a DRAFT of the Supply Chain SBOM roles & responsibilities overview, 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!
- Contribute on Github: https://github.com/CPAN-Security/security.metacpan.org/tree/supplychain-sbom/docs/supplychain-sbom.md
- Discuss on IRC: ircs://ssl.irc.perl.org:7063/#cpan-security
About this document
- In Open-Source Software supply chains, we find people filling distinct roles that each care about some metadata or tasks in SBOMs.
- This document attempts to offer an overview of these roles, how they are related, and what each role cares about.
- The rationale behind this document lays in the document author’s perceiving that there were no good sources that described how SBOMs should (or could!) be used throughout an Open Source Software supply-chain.
- Much of existing documentation focused heavily on SBOMs from the perspective of a software suppliers (businesses) or consumers.
- Frustration with the lack of a clear Open Source perspective brought the author to the SBOM devroom at FOSDEM 2024 to offer a rant about what he perceived as a less-than-ideal state of affairs.
- This document exists in large part due to the author’s attempt at taking notes while figuring out what the state of the art in SBOM.
- Please take this document as it is – a public set of notes, intended as a source for illumination and as an ongoing conversation, taking incremental steps toward more transparent and accountable Open Source supply-chains.
For license information and acknowledgements, see the end of this document.
Purpose TL;DR
In this document we’re trying to identify and expose all places and roles in an Open Source supply chain where someone cares about some metadata (and it’s associated code) that someone downstream needs for detecting and mitigating vulnerabilities.
The relation between Supply-chain Roles and SBOM Roles
- Any single person working within a supply-chain may have one or more roles, and switch between them as needed.
- Each supply-chain role described in this document MAY care about some specific SBOM metadata and their accompanying artifacts.
- Each SBOM role described in this document MUST also have a supply-chain role.
- If a supply-chain role cares about some SBOM metadata, they have one or more of the following SBOM roles.
- When a Supply-chain Role creates or updates an SBOM, we call them an SBOM Author.
- When a Supply-chain Role distributes an SBOM, we call them an SBOM Distributor.
- When a Supply-chain Role consumes an SBOM, we call them an SBOM Consumer
SBOM Roles
It may be useful to distinguish between roles that are focused on the SBOM documents themselves, from roles that are involved in a supply-chain activity. For further reading, please see CISA’s “SBOM Sharing Roles and Considerations” recommendations (CISA-2024).
stateDiagram-v2
direction LR
state "🟥 SBOM Author (Authoritative)" as sbom_author
state "🟨 SBOM Author (Non-authoritative)" as sbom_assembler
state "🟩 SBOM Distributor" as sbom_distributor
state "🟦 SBOM Consumer" as sbom_consumer
[*] --> sbom_author
sbom_author --> sbom_assembler
sbom_author --> sbom_consumer
sbom_author --> sbom_distributor
sbom_assembler --> sbom_distributor
sbom_assembler --> sbom_consumer
sbom_distributor --> sbom_assembler
sbom_distributor --> sbom_consumer
sbom_consumer --> [*]
Color-coding legend for SBOM Roles
The color-coding is used in this document to help illustrate different SBOM activities any role may perform.
- 🟥 Create, define, sign SBOM metadata — Authoritative roles make sure the metadata and related artifacts they are the author of, Exist.
- 🟨 Assemble, update, maintain, attest, annotate SBOM metadata — Non-authoritative roles make sure the metadata and related artifacts they process, are Updated.
- 🟩 Distribute, curate, index SBOM metadata — Distributing roles make sure the metadata and related artifacts they have, are made Available to others.
- 🟦 Consume, aggregate, verify, validate, survey, analyze or report SBOM metadata — Consuming roles makes sure the metadata and related artifacts they consume, are Complete, Correct or Compliant.
SBOM Author
[!NOTE] FIXME – Check if this is sane.
- Creates an SBOM. (CISA-2024)
- An authoritative source of an SBOM, or an SBOM metadata field. (CPANSec-2024)
- See also SBOM Author in the glossary.
- SBOM Authors create, define or sign SBOM metadata — They make sure the fields and related artifacts Exist. (CPANSec-2024)
- This mostly means authoritative metadata fields as laid out in the different Supply-chain Roles below.
- In addition to fields encountered throughout the supply-chain, they care about the fields 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)
- SBOM Authors who are not authoritative sources, but instead gather SBOM metadata from different dependencies, may be referred to as an SBOM Assembler. (CPANSec-2024)
- SBOM Assemblers may 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)
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟥 | SBOM Type | No | ||||
🟥 | SBOM Author | Yes | Text | bom.metadata.author | creationInfo.creators[] | NTIA-SBOM, DE-TR.5.2.1 |
🟥 | SBOM Creation Time-stamp | Yes | DateTime | bom.metadata.timestamp | creationInfo.created | NTIA-SBOM, DE-TR.5.2.1 |
🟥 | SBOM Generation Tool | No | List | bom.metadata.tools[] | creationInfo.creators[] | |
🟥 | SBOM Serial Number | Yes | UUID | bom.metadata.serialNumber | SPDXID | |
🟥 | CycloneDX bomFormat | Yes | Enum | bom.properties.bomFormat | N/A | CycloneDX 1.6 |
🟥 | CycloneDX specVersion | Yes | Int | bom.properties.specVersion | N/A | CycloneDX 1.6 |
(Ref: CISA-2024, NTIA-2021, CPANSec-2024)
SBOM Assembler
- A non-authoritative SBOM Author
SBOM Distributor
[!NOTE] FIXME – Check if this is sane.
- SBOM Distributor roles distribute, curate, or index SBOM metadata — They make sure the metadata and related artifacts are made Available to others. (CPANSec-2024)
- They don’t have any specific metadata fields that are commonly used across the different supply-chain consumer roles, beyond ensuring that SBOMs are available for others to use and refer to.
- Receives SBOMs for the purpose of sharing them with SBOM Consumers or other Distributors. (CISA-2024)
- Additionally, an SBOM Distributor may care about the following activities. (CISA-2023)
- 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, CPANSec-2024)
SBOM Consumer
[!NOTE] FIXME – Check if this is sane.
- SBOM Consumer roles gather, inspect, analyze, aggregate or verify SBOM metadata — They make sure metadata and related artifacts are Useful, Complete, Correct or Compliant. (CPANSec-2024)
- They don’t have any specific metadata fields that are commonly used across the different supply-chain consumer roles.
- 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. (NTIA-2021, “Consume” category)
- Receives the transferred SBOM. (CISA-2024)
- This could include roles such as third parties, authors, integrators, and end users.
(Ref: CISA-2024, NTIA-2021, CPANSec-2024)
An idealized Open Source supply-chain graph
stateDiagram-v2
direction TB
accTitle: An idealized Open Source supply-chain graph
%%
state "🟦 Importer" as author_importer
state "🟥 Owner" as author_owner
state "🟨🟥 Author\n🟨 Custodian" as author
state "🟩 Distributor" as repository_distributor
state "🟦 Importer" as language_importer
state "🟦🟨 Packager" as language_packager
state "🟦🟨 OSS Steward" as language_steward
state "🟨 Curator" as language_curator
state "🟩 Distributor" as language_distributor
state "🟦 Contributor" as contributor
state "🟦 Importer" as package_importer
state "🟨 Patcher" as package_patcher
state "🟨🟦 Builder\n🟨🟦 Packager\n🟨🟦 Containerizer" as package_packager
state "🟨 Curator" as package_curator
state "🟩 Distributor" as package_distributor
state "🟦 Importer" as integrator_importer
state "🟥 Owner\n🟥 Manufacturer" as integrator_owner
state "🟦🟨🟥 Integrator\n🟦🟨🟥 Developer" as integrator_developer
state "🟩 Publisher" as integrator_publisher
state "🟨 Deployer\n🟨 Installer" as deployer
state "🟦🟨 Builder" as integrator_builder
state "🟦 Vuln. Checker" as integrator_checker
state "🟦 Consumer\n🟦 User" as consumer
state "🟦 Auditor" as auditor_internal
state "🟦 Auditor" as auditor_external
%%
classDef createsSBOM stroke:red,stroke-width:3px;
classDef updatesSBOM stroke:yellow,stroke-width:3px;
classDef assemblesSBOM stroke:yellow,stroke-width:3px;
classDef distributesSBOM stroke:green,stroke-width:3px;
classDef verifiesSBOM stroke:#07f,stroke-width:3px;
%%
class author_importer verifiesSBOM
class author_owner createsSBOM
class manufacturer_owner createsSBOM
class author assemblesSBOM
class package_importer verifiesSBOM
class package_patcher updatesSBOM
class package_packager assemblesSBOM
class package_curator distributesSBOM
class package_distributor distributesSBOM
class language_importer verifiesSBOM
class language_packager assemblesSBOM
class language_steward updatesSBOM
class language_curator distributesSBOM
class language_distributor distributesSBOM
class repository_distributor distributesSBOM
class integrator_importer verifiesSBOM
class integrator_owner createsSBOM
class integrator_developer assemblesSBOM
class integrator_publisher distributesSBOM
class integrator_builder assemblesSBOM
class integrator_checker verifiesSBOM
class deployer assemblesSBOM
class auditor_internal verifiesSBOM
class auditor_external verifiesSBOM
state "Author Environment" as ecosystem_author {
[*] --> author_importer
[*] --> author
author_importer --> author
author_owner --> author
author --> language_packager
}
[*] --> ecosystem_author
state "Language Ecosystem" as ecosystem_lang {
[*] --> language_importer
[*] --> language_steward
[*] --> language_curator
[*] --> language_distributor
language_importer --> language_distributor
language_importer --> language_curator
language_steward --> language_curator
language_curator --> language_distributor
}
language_packager --> ecosystem_lang
ecosystem_lang --> ecosystem_lang
state "Public Collaboration Ecosystem" as ecosystem_repo {
[*] --> repository_distributor
}
author --> ecosystem_repo
ecosystem_repo --> author
repository_distributor --> contributor
contributor --> repository_distributor
state "Package Ecosystem" as ecosystem_package {
[*] --> package_importer
[*] --> package_packager
[*] --> package_patcher
package_importer --> package_patcher
package_importer --> package_packager
package_patcher --> package_packager
package_packager --> package_curator
package_packager --> package_distributor
package_curator --> package_distributor
}
repository_distributor --> ecosystem_package
language_distributor --> ecosystem_package
ecosystem_package --> ecosystem_package
state "Integrator Environment" as ecosystem_integrator {
[*] --> integrator_importer
[*] --> integrator_developer
integrator_importer --> integrator_developer
integrator_owner --> integrator_developer
integrator_builder --> integrator_publisher
integrator_developer --> integrator_checker
integrator_checker --> integrator_developer
auditor_internal --> integrator_developer
integrator_developer --> integrator_builder
integrator_developer --> auditor_internal
}
repository_distributor --> ecosystem_integrator
language_distributor --> ecosystem_integrator
package_distributor --> ecosystem_integrator
state "Production Environment" as ecosystem_prod {
[*] --> deployer
}
integrator_publisher --> [*]
integrator_developer --> ecosystem_prod
integrator_builder --> ecosystem_prod
integrator_publisher --> ecosystem_prod
deployer --> consumer
deployer --> auditor_external
%% Copyright © 2024 Salve J. Nilsen <sjn@oslo.pm>
%% Some rights reserved. Licenced CC-BY-SA-4.0
Supply-chain Ecosystems and Environments
Author Environment
One or more developers that publish an Open-Source component.
- Publishes Open-Source Software
- May have a project development life-cycle
Integrator Environment
A business or institution that is responsible for developing and building the application that is required to have an accompanying SBOM document. Management is expected to ensure that this assembled SBOM document describes the application as required by law.
- Operates commercially
- May publish Open-Source Software
- Has a project development life-cycle
Manufacturer Environment
- Used specifically in the context of the EU Cyber Resilience Act, to mean a commercial entity that places a product with digital elements on the EU market.
- See Integrator Environment.
[!WARNING]
- FIXME - Much more to add!
- e.g. from https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/
Language Ecosystem
A language ecosystem hosts, indexes and distributes components specific for a programming language
- Examples: CPAN (Perl), PyPI (Python), NPM (Node/JS)
- May have upstream language ecosystems
- May have downstream language ecosystems
- May have automated Patcher
- May be Public
- May be Private
Package Ecosystem
A package ecosystem patches, repackages, curates, indexes and hosts either components for a specific OS distributions, or collections of components for use in container registries, available for easy download and use.
- Examples of package systems: APT (Debian, Ubuntu), RPM (AlmaLinux, SuSE), Ports (FreeBSD, OpenBSD)
- Examples of container systems: Docker
- May have upstream package ecosystems
- May have downstream package ecosystems
- May be Public
- May be Private
Production Environment
The environment and systems where a product or service is executed on behalf of a customer, and thereby made available to their users.
- See also Customer Environment.
Customer Environment
The environment and systems where a product or service is executed by a customer and thereby made available to their users.
- See also Production Environment
Public Collaboration Ecosystem
A website or tool that offers a public collaboration repository to Authors, so they may cooperate and share ongoing work in public.
- Examples: Github, Codeberg, Bitbucket, Gitlab, Gitea and others.
Repository Ecosystem
Supply-chain roles and metadata
Owner
Operates in an Author Environment or Integrator Environment. Has the legal ownership rights and liabilities for the component. Is usually the Author, a business or some other type of legal entity. May decide the name of the project and other project parameters for (or on behalf of) the Author or Developer.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟥 | Owner Name | Yes | Text, URL | bom.metadata[supplier,manufacturer,author], bom.components[].supplier | creationInfo.creators[], packages[].originator, packages[].supplier | CRA-AII(1), NTIA-SBOM, DE-TR.5.2.2 |
- See also Manufacturer
Manufacturer
Is a role within an Integrator Environment. When doing business within the European Economic Area (EEA), has the duty to ensure that the conformity obligations in the EU Cyber Resilience Act are met. (CRA-AV)
- See also Owner
Do | Field name | Required | Data type | CycloneDX (PRE-PROPOSAL; UNSUPPORTED) | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟥 | Owner Name (Manufacturer) | Yes | Text, URL | bom.metadata[supplier,manufacturer], bom.components[].supplier | creationInfo.creators[], packages[].originator, packages[].supplier | CRA-AII(1), NTIA-SBOM, DE-TR.5.2.2 |
🟥 | CE Declaration of Conformity | Yes | URL | bom.externalReferences[?(@.conformity-declaration)] | CRA-AII(6), CRA-AV | |
🟥 | CE Support End Date | Yes | DateTime | bom.externalReferences[?(@.support-horizon)] | CRA-AII(7) | |
🟥 | CE Technical Documentation | Yes | URL | bom.externalReferences[?(@.documentation)] | CRA-AII(8), CRA-AVII | |
🟥 | CE Conformity Assessment Body | Yes | URL | bom.externalReferences[?(@.conformity-body)] | CRA Article 47.1, CRA-AV |
[!NOTE] Manufacturer has a specific defined meaning in the Cyber Resilience Act, so until this definition is established, be careful when using the term. These fields are in addition to the fields listed under Owner.
Supplier
- Is a role within an Integrator Environment.
- The term is used within the NTIA “SBOM Minimum Elements” document as the legal source of a component.
-
The name of an entity that creates, defines, and identifies components. (CycloneDX-1.6)
- See Manufacturer, Owner, Open-Source Software Steward, Supplier in the glossary.
Author (SBOM)
- See SBOM Author
Author
Operates within an Author Environment. The initial and/or main creator of the component in question. Typically works on all aspects of the code, including features, bug fixes, tests and security issues. Has the final say on the original contents of the package. The Author can be a group of people, though a single point of responsibility is common. If an Author has upstream (reverse) dependencies, the Author is also considered to be a Developer (as seen from the upstream Author’s perspective; See below). Not to be confused with the SBOM Author role.
- See also Author in the Glossary.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟥 | Component Name | Yes | Text | bom.components[].name | packages[].name | NTIA-SBOM, DE-TR.5.2.2, CRA-AV |
🟥 | Version | Yes | Text | bom.components[].version | packages[].versionInfo | NTIA-SBOM, DE-TR.5.2.2 |
🟥 | Dependencies | Yes | List | bom.components[], bom.dependencies[] | relationships[].[spdxElementId,relatedSpdxElement] | CRA-AII(5), NTIA-SBOM |
🟥 | Security contact | Yes | URL | bom.externalReferences[].security-contact | CRA-AII(2) | |
🟥 | Unique ID, Product ID | Yes | PURL | bom.components[].purl | packages[].externalRefs.referenceCategory = “PACKAGE-MANAGER”, packages[].externalRefs.referenceType = “purl”, packages[].externalRefs.referenceLocator | CRA-AII(3), NTIA-SBOM, CRA-AV |
🟥 | Purpose, Intended Use | Yes | Text | bom.components[].description | packages[].comment | CRA-AII(4) |
🟨 | Licenses | Yes | SPDX License | bom.components[].licenses[] | packages[].licenseConcluded, packages[].licenseDeclared | |
🟥 | Public Code Repository | Yes | bom.metadata.component.externalReferences[].vcs | packages[].externalRefs.referenceCategory = “PERSISTENT_ID”, packages[].externalRefs.referenceType = “gitoid”, packages[].externalRefs.referenceLocator | ||
🟥 | Intended for Commercial Use | No | Boolean | CRA-Rec-15 | ||
🟥 | Open-Source Software Steward | No | URL | CRA | ||
🟥 | Code Commit Revision | No | ||||
🟨 | Code Repository | Yes | bom.metadata.component.externalReferences[].vcs | packages[].externalRefs.referenceCategory = “PERSISTENT_ID”, packages[].externalRefs.referenceType = “gitoid”, packages[].externalRefs.referenceLocator | ||
🟨 | Owner Name (Author) | Yes | Text, URL | bom.components[].supplier | creationInfo.creators[] | CRA-AII(1), NTIA-SBOM, DE-TR.5.2.2, CRA-AV |
🟨 | SBOM Location | No | URL | bom.externalReferences[].bom, bom.components.externalReferences[].bom | CRA-AII(9) | |
🟨 | SBOM Type | Yes | ||||
🟨 | SBOM Author | Yes | Text | bom.metadata.author | creationInfo.creators[] | NTIA-SBOM, DE-TR.5.2.1 |
🟨 | SBOM Creation Time-stamp | Yes | DateTime | bom.metadata.timestamp | creationInfo.created | NTIA-SBOM, DE-TR.5.2.1 |
🟨 | SBOM Generation Tool | No | List | bom.metadata.tools[] | creationInfo.creators[] | |
🟨 | SBOM Serial Number | Yes | UUID | bom.metadata.serialNumber | SPDXID |
Custodian
Operates within an Author Environment. A type of Author with reduced responsibilities, working on behalf of the actual author. Cares about the ongoing security of the code. Typically only concerned with updating dependencies or applying security fixes. Works with the Author primarily, and may take responsibility on their behalf when it comes to security concerns. May work on behalf of the author if they are unavailable or unresponsive.
Contributor
Operates independently, but through a Public Collaboration Ecosystem. Interacts with component with bug reports, feedback, quality assurance, testing, patches or pull requests. May or may not have repository commit privileges. May also have additional roles, including being a downstream Developer, Patcher or Author.
Steward
[!NOTE]
- Steward has a specific defined meaning in the EU Cyber Resilience Act, so it’s better to avoid using the term as a synonym for Custodian.
- See also Open Source Software Steward
Importer
May operate in any ecosystem or environment. A role specifically used when a EU entity makes available software on the EU market, Is required to verify that the imported software is compliant with the EU Cyber Resilience Act according to it’s Article 19.
See also Importer definition in the glossary.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟦 | Security contact | Yes | URL | bom.metadata.[supplier,manufacturer,author].contact.email | CRA-AII(2) | |
🟦 | Unique ID, Product ID | Yes | PURL | bom.components[].purl | packages[].externalRefs.referenceCategory = “PACKAGE-MANAGER”, packages[].externalRefs.referenceType = “purl”, packages[].externalRefs.referenceLocator | CRA-AII(3), NTIA-SBOM |
🟦 | Purpose, Intended Use | Yes | Text | CRA-AII(4) | ||
🟦 | SBOM Location | No | URL | bom.externalReferences[].bom, bom.components.externalReferences[].bom | CRA-AII(9) | |
🟦 | Licenses | Yes | SPDX License | bom.metadata.licenses[], bom.components[].licenses[] | packages[].licenseConcluded, packages[].licenseDeclared | |
🟦 | CE Declaration of Conformity | No | URL | (unsupported) | CRA-AII(6), CRA-AV | |
🟦 | CE Support End Date | No | URL | (unsupported) | CRA-AII(7) | |
🟦 | CE Instructions (Documentation) | No | URL | (unsupported) | CRA-AII(8) | |
🟦 | CE Conformity Assessment Body | No | URL | (unsupported) | CRA Article 47.1, CRA-AV | |
🟦 | Download location | Yes |
Patcher
Operates within a Package Ecosystem. Applies security and/or bug fixes to packages before building and packaging. Works mainly with a downstream Packager, and has Author’s downstream ecosystems as upstream.
This role is necessary when…
- Upstream Author roles are not responsive or available, and thereby security fixes aren’t applied there.
- When downstream constraints and requirements call for it – e.g. when back-porting of fixes are needed due to downstream LTS requirements.
[!NOTE]
- Patchers (a role that often is held by the same person as the Packager), may select and apply patches before building.
- These patches may include back-ports of features, security fixes or other accommodations necessary for distributing multiple releases of the same upstream project, but within publishing constraints decided by the Curator of the Ecosystem (e.g. LTS releases, support contracts, etc.).
- A Packager can both be found in-house (e.g. a business who uses a company-internal package mirror), for a Package Ecosystem provider (e.g. Debian), or a Language Ecosystem provider (e.g. a company-internal CPAN mirror that distributes patched packages).
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟨 | Version | Yes | Text | bom.components[].version | packages[].versionInfo | NTIA-SBOM, DE-TR.5.2.2 |
🟨 | Unique ID, Product ID | Yes | PURL | bom.components[].purl | packages[].externalRefs.referenceCategory = “PACKAGE-MANAGER”, packages[].externalRefs.referenceType = “purl”, packages[].externalRefs.referenceLocator | CRA-AII(3), NTIA-SBOM |
[!WARNING] FIXME – Not done
Builder
[!IMPORTANT] Builders should add build environment metadata (including resolved dependencies) in an accompanying SBOM file.
- See also Packager, Containerizer, Deployer.
Packager
Operates within a Package Ecosystem or an Author Environment. Within a package ecosystem, builds and creates packages from components received from an upstream source, optionally with patches applied from the Patcher. Within an author environment, creates packages from their own project in preparation for publication in a downstream Language Ecosystem (e.g. create a CPAN package for uploading to CPAN using the PAUSE interface). Concerns themselves with correct package format and structure, and that package metadata is preserved and updated.
[!NOTE]
- Packagers take upstream components from an upstream source and build and install them into a custom environment for producing system packages for their native packaging ecosystem (e.g. APT).
- Upstream sources may be…
- Author’s repository, or a Custodian’s if a project is dormant (e.g. a repository on Codeberg).
- Language-specific packages distributed by a Language Ecosystem (e.g. CPAN).
- E.g. someone in the #debian-perl group downloads, builds, tests and installs something from CPAN, but instead of doing a regular install, they us tooling like
dh-make-perl
to produce a custom installation directory that can be incorporated into a .deb archive.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟨 | Dependencies | Yes | List | bom.components[], bom.dependencies[] | CRA-AII(5), NTIA-SBOM | |
🟨 | Download location | No | URL | |||
🟨 | SBOM Location | No | URL | bom.components.externalReferences[].bom | CRA-AII(9) |
Containerizer
Operates within a Package Ecosystem, creating containers. Builds, installs package dependencies and creates container images from a base images.
[!NOTE]
- FIXME – “Containerizer” probably isn’t the best name for the role that creates container images. If you have suggestions for a better single-word name for this role, that isn’t ambiguous or obscure, then please reach out!
- FIXME – Flesh out details
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX | Required by |
---|---|---|---|---|---|---|
🟨 | Dependencies | Yes | List | bom.components[], bom.dependencies[] | CRA-AII(5), NTIA-SBOM | |
🟨 | Download location | No | URL | |||
🟨 | SBOM Location | No | URL | bom.components.externalReferences[].bom | CRA-AII(9) |
Deployer
Operates within a Production Environment. Final preparation and installation of the software into a CI/CD or other deployment method an Integrator or Production Environment.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟥 |
[!WARNING] FIXME – Not done
Installer
[!NOTE] Mentioned once in the EU Cyber Resilience Act.
- See Deployer
Open-Source Software Steward
Within a Language Environment, the OSS Steward has the duty to ensure that the obligations in the EU Cyber Resilience Act Articles 14, 15 and FIXME are met.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟦 | Open-Source Software Steward | Yes | URL | CRA-Rec-19 | ||
🟦 | Intended for Commercial Use | Yes | Boolean | CRA-Rec-15, CRA-Rec-18 | ||
🟥 | Security Attestation | Yes | URL | CRA-Rec-21 |
[!NOTE] FIXME – Not done
- See also Author, Open-Source Software Steward in the glossary.
Curator
Operates within a Package Ecosystem or a Language Ecosystem. Selects or pins which components are suitable for use downstream of the package ecosystem. Works mainly with the Distributor role. Concerns themselves with both the stability and predictability of components, and how this is prioritized against the need for features, bug fixes and security updates.
[!NOTE]
- Curators may decide both whether and where the output of a Packager is distributed.
- Curators may operate both in-house, in order to keep an eye on what is being automatically installed there, or they may make the decisions that happen on the Package or Language Ecosystem provider side.
- Typically, a curator may consider LTS status, support contract terms or other reasons for distributing a package.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟥 | Download location | No | URL | |||
🟥 | SBOM Location | No | URL | bom.externalReferences[].bom | CRA-AII(9) |
[!WARNING] FIXME – Not done
Distributor
Operates within a Package Ecosystem or a Language Ecosystem. Ensures the availability of packages or containers, that they are indexed correctly, and that any related metadata is up-to-date, correct and available.
[!NOTE]
- Distributors take packages or containers that Patchers and Packagers produce, and ensure these are made available in a reliable way for downstream users according to the Curator’s requirements. (e.g. by setting up and managing a Debian APT repository, or a CPAN mirror, or a Docker container registry, or similar).
- If SBOM metadata is expected to accompany the packages or containers in question, the Distributor makes sure this happens.
- Distributors have additional requirements and considerations laid out in CISA-2024.
- Distributors have additional requirements around compliance, laid out in the EU Cyber Resilience Act Article 20.
- See also
- CISA SBOM Sharing Roles and Considerations (CISA-2024)
- CRA Article 20 (CRA-Art-20)
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟨 | Download location | Yes | URL | |||
🟨 | SBOM Location | No | URL | bom.externalReferences[].bom, bom.components.externalReferences[].bom | CRA-AII(9) |
[!WARNING] FIXME – Not done
Developer
Operates within an Integrator Environment. Uses packages and components as dependencies in their own project, product or component. A Developer is in many ways identical to an Author from the upstream Author’s perspective, with the main difference being that a Developer doesn’t publish their work as Open-Source Software. A Developer that publishes their software as Open-Source Software, is called an Author.
- See also Author.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
[!WARNING] FIXME – Not done
Integrator
Used in the EU Cyber Resilience Act Annex II to denote someone who integrates a product with digital elements intended for integration into other products with digital elements.
- See Developer.
Publisher
Operates within an Integrator Environment or a Manufacturer Environment. Makes available a component or product on a market on behalf of the Integrator or Manufacturer. With regard to the EU Cyber Resilience Act, a Publisher is the same as a Distributor.
Vuln. Checker
Vulnerability checker. May operate within a Production Environment or an Integrator Environment. Responsible for security checks, including runtime, dynamic and static checks, vulnerability monitoring, etc. Communicates any issues or findings to any number of upstream roles, including the component Deployer, Developer or Author.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟦 | Unique ID, Product ID | Yes | PURL | bom.components[].purl | packages[].externalRefs.referenceCategory = “PACKAGE-MANAGER”, packages[].externalRefs.referenceType = “purl”, packages[].externalRefs.referenceLocator | CRA-AII(3), NTIA-SBOM |
[!WARNING] FIXME – Not done. FIXME – Check refs for CRA-Rec-34 and others FIXME – Consider need for an Author’s list of known/addressed vulnerabilities, to check against public vulnerability databases.
SecOps
- See checker.
Pentester
- See checker.
Scanner
- See checker.
Consumer
The software in use, in production, by a user.
User
- See Consumer.
Auditor
Verifies that all necessary metadata is available, up-to-date and made use of.
Do | Field name | Required | Data type | CycloneDX 1.6 | SPDX 2.3 | Required by |
---|---|---|---|---|---|---|
🟦 | Security contact | Yes | URL | bom.components[].externalReferences[].security-contact | CRA-AII(2) | |
🟦 | Unique ID, Product ID | Yes | PURL | bom.components[].purl | packages[].externalRefs.referenceCategory = “PACKAGE-MANAGER”, packages[].externalRefs.referenceType = “purl”, packages[].externalRefs.referenceLocator | CRA-AII(3), NTIA-SBOM |
🟦 | Purpose, Intended Use | Yes | Text | CRA-AII(4) | ||
🟦 | SBOM Location | No | URL | CRA-AII(9) | ||
🟦 | CE Declaration of Conformity | No | URL | CRA-AII(6), CRA-AV | ||
🟦 | CE Support End Date | No | URL | CRA-AII(7) | ||
🟦 | CE Instructions | No | URL | CRA-AII(8) | ||
🟦 | CE Conformity Assessment Body | No | URL | CRA-Art-47(1), CRA-AV | ||
🟦 | Download location | Yes |
Compliance
- See Auditor.
Are you… a Manufacturer, Steward or Author?
graph TB
start-here(Start here) --> involved{"Involved<br>with OSS products?<br>CRA Recital (18)"}
involved -->|No| not-relevant-for-you("This chart isn't<br>relevant for you")
involved -->|Yes| contributing{"Contributing<br>unpaid to OSS?<br>CRA Recital (18)"}
contributing -->|No| monetised{"Monetizing<br>the product?<br>CRA Recital (18)"}
contributing -->|Yes| cra-is-out-of-scope(CRA is out-of-scope)
monetised -->|Yes| cra-manufacturer("CRA is in-scope<br>You are a Manufacturer<br>CRA Recital (18), (15)")
monetised -->|No| is-legal-entity{"Legal person,<br> but not natural person?<br>CRA Recital (19)"}
is-legal-entity -->|Yes| intended-commercial-use{"Is product<br>intended for<br>commerial use?<br>CRA Recital (19)"}
is-legal-entity -->|No| cra-is-out-of-scope
intended-commercial-use -->|No| cra-is-out-of-scope
intended-commercial-use -->|Yes| product-supporter{"Providing<br>support for OSS<br>products?<br>CRA Recital (18)"}
product-supporter -->|Yes| cra-oss-steward("CRA in-scope<br>You are an Open-Source Software Steward<br>CRA Article 3 (14)")
product-supporter -->|No| cra-is-out-of-scope
%% Based on the flowchart made by Maarten Aertsen (NLNetLabs) found at
%% https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/
%% Original flowchart © Maarten Aertsen <maarten@nlnetlabs.nl>
%% License: CC0 1.0 Universal
%% Adapted to Mermaid and modified by Salve J. Nilsen <sjn@oslo.pm>
References
- (CISA-2024) CISA SBOM Sharing Roles and Considerations, published 2024-03-28.
- (CRA-AII) Cyber Resilience Act, Annex II Information and Instructions to the User, Dated 2024-03-12
- (CRA-AV) Cyber Resilience Act, Annex V EU Declaration of Conformity, Dated 2024-03-12
- (CRA-AVII) Cyber Resilience Act, Annex VII Contents of the Technical Documentation, Dated 2024-03-12
- (CRA-Art-3) Cyber Resilience Act, Article 3 Definitions, Dated 2024-03-12
- (CRA-Art-20) Cyber Resilience Act, Article 20 Obligations of distributors, Dated 2024-03-12
- (CRA-Art-47) Cyber Resilience Act, Article 47 Operational obligations of notified bodies, Dated 2024-03-12
- (CRA-Rec-15) Cyber Resilience Act, Recital 15 Economic operators, Dated 2024-03-12
- (CRA-Rec-18) Cyber Resilience Act, Recital 18 Open Source Software Contributors, Dated 2024-03-12
- (CRA-Rec-19) Cyber Resilience Act, Recital 19 Open Source Software Stewards, Dated 2024-03-12
- (DE-TR) German Technical Requirement TR-03183 Cyber Resilience Requirements for Manufacturers and Products (part 2), Version 1.1, published 2023-11-28.
- (NTIA-2021) SBOM Tool Classification Taxonomy, published 2021-03-30.
-
(NTIA-SBOM) NTIA Minimum Elements for a Software Bill of Materials (SBOM), Published 2021-07-12
- (CPANSec-2024) CPAN Security Group commentary by Author.
Commentary and FIXME points (FIXME: remove when done)
- Open Source in CRA… Author -> Provider -> Supplier -> Steward -> Manufacturer -> Distributor -> Importer
- Open Source in CRA (simplified)… Hobbyist -> Author -> Author w/Steward -> Manufacturer
- Add graph/description on build steps, to illustrate how different SBOM files may be found, sourced, generated, assembled, installed and shared for later verification or analysis.
- Clearer distinction between “Author”, “SBOM Author”, “Developer”, and “Integrator”. Should “Author” strictly be about SBOM production, and an Open Source Developer be called a “Developer”? In that case, someone who doesn’t publish as Open Source, would have to be called “Integrator”. Is that OK?
- Possible inclusion of “Config Ecosystems” or “Data Ecosystems” to take into account vulnerabilities/malware found in plugins, AI models or other shared data.
- Enumerate what distinguishes the different environments
- Language: Not built, not deployed, Is source code, No execution environment
- Distro/package: Built, Deployed, Is object, No execution environment
- Model/plugin: Built, Not deployed, Is data, No execution environment (FIXME: unsure)
- Image/container: Built, Deployed, Is object, Has execution environment
- Enumerate the different dependencies
- Stages; Author/develop, configure, build, test, install/deploy, packaging, containerization, post-deploy (plugin/dynamic), runtime.
- States; resolved, required/unresolved, embedded
- Types; component, patch, system resource, environment, ecosystem, service
- Descriptions; cross-ecosystem vs. in-ecosystem, up-river vs. down-river (within language ecosystem), upstream vs. downstream (outside language ecosystem), reverse, assumed/implied vs. stated/explicit
- Clearer distinction between Builder, Deployer, Packager, Containerizer
- Add example of a chain of edits to an SBOM document, as it is passed down the supply-chain
License and use of this document
- Version: 0.5.1
- License: CC-BY-SA-4.0
- Copyright: © Salve J. Nilsen sjn@oslo.pm, Some rights reserved.
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)
- Stian Kristoffersen
- Josh Bressers