CX-0158-1 Car SBOM for ICTS Connected Vehicles v1.0.0
ABSTRACT
This standard defines rules for compliance with the U.S. ruling "Securing the Information and Communications Technology and Services Supply Chain: Connected Vehicles" (ICTS) issued by the Bureau of Industry and Security, Department of Commerce. It formally specifies the to be used data format and defines conformance profiles by building on the CX-0158 Car SBOM standard.
FOR WHOM IS THE STANDARD DESIGNED
This standard is designed for all participants in the automotive supply chain who need to declare software components used in connected vehicles to demonstrate compliance with the ICTS final rule. This includes OEMs, Tier-1 and Tier-N suppliersSupplier In the context of OSim, the producer of goods., as well as tooling and platform providers that support the creation, exchange, and consumption of SBOMs.
1 INTRODUCTION
The U.S. final rule "Securing the Information and Communications Technology and Services Supply Chain: Connected Vehicles" (15 CFR Part 791) came into effect on March 17, 2025. It imposes restrictions on the import and sale of connected vehicles and related components that incorporate information and communications technology or services from certain foreign adversaries. Compliance with this regulation requires detailed knowledge of the software components integrated into connected vehicles across the entire supply chain.
This standard leverages the Catena-X dataspace to enable a standardized, sovereign, and interoperable exchange of SBOMs. It builds on a baseline SBOM specification shared across multiple Catena-X SBOM use cases and extends it with ICTS-specific requirements.
1.1 AUDIENCE & SCOPE
This section is non-normative
This document is targeting subsets of the following roles:
- Data Provider / Consumer
- Business Application Provider
- Enablement Service Provider
This standard applies to participants and their solutions that:
- create, provide, or consume SBOMs describing software components used in connected vehicles,
- need to demonstrate compliance with the ICTS final rule through the Catena-X network, or
- develop or operate tooling that supports SBOM creation, validation, exchange, or consumption in the context of connected vehicles.
This standard is relevant when software components are part of connected vehicle systems subject to the ICTS regulation. It is not intended to replace or duplicate general-purpose SBOM standards but rather to provide Catena-X-specific guidance and profiles for the ICTS use case.
1.2 CONTEXT AND ARCHITECTURE FIT
This section is non-normative
The ICTS final rule requires that participants in the connected vehicle supply chain can identify and declare the origins of software components used in their products. A Software Bill of Materials (SBOM) is the established mechanism for achieving this transparency. Within Catena-X, the SBOM exchange is built on top of the existing dataspace infrastructure, including sovereign data exchange (CX-0018), digital twins (CX-0002), industry core standards (CX-0126, CX-0127) and the enablement standard Car SBOM (CX-0158).
This standard defines a layered approach:
- Baseline: A common SBOM foundation shared across all Catena-X use cases that require software transparency. (CX-0158)
- ICTS Extension: Additional requirements specific to the ICTS use case, including legal and business requirements derived from the final rule, extended metadata, and specific conformance criteria. (This standard)
Dependencies are organized such that the baseline is always fulfilled first, and use-case-specific extensions build on top of it (adding additional, or enforcing existing requirements more strictly).
1.3 CONFORMANCE AND PROOF OF CONFORMITY
This section is normative
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
All participants and their solutions will need to prove, that they are conform with the Catena-X standards. To validate that the standards are applied correctly, Catena-X employs Conformity Assessment Bodies (CABs).
Since this document describes a set of standards to be fulfilled, all participants mentioned MUST fulfill all mentioned standards and the respective conformity assessment criteria in addition to the specific criteria mentioned in this document.
To prove conformity with this standard, participants MUST:
- Demonstrate that SBOMs are created according to CX-0158.
- Validate SBOMs against the formal language model (JSON-Schema) provided in CX-0158.
- Provide evidence that SBOM integrity and authenticity mechanisms are implemented according in CX-0158.
- Demonstrate that SBOMs additionally conform to the ICTS requirements defined in this standard ( see Section 2).
1.4 TERMINOLOGY
This section is non-normative
The following terms are especially relevant for the understanding of this standard:
ICTS (Information and Communications Technology and Services) As defined by the U.S. Department of Commerce, Bureau of Industry and Security, in 15 CFR Part 791, referring to hardware, software, and services used for information or data processing, storage, retrieval, and communication.
Connected Vehicle As defined in the ICTS final rule, a vehicle that integrates onboard networked hardware with automotive software systems to enable connectivity with external networks, infrastructure, or other vehicles.
SPDX Document An SPDX element (/Core/SpdxDocument) that serves as the root container for a collection of SPDX elements and their relationships.
Profile A defined subset of SPDX requirements specifying which elements, properties, and relationships are mandatory, optional, or prohibited for a given conformance level.
Baseline Profile The minimum set of SBOM requirements shared across all Catena-X SBOM use cases, comprising Core, Lite, Software, and Build profiles.
ICTS Profile Extension Additional SBOM requirements beyond the baseline, specific to the ICTS Connected Vehicles use case.
2 MAIN CONTENT
This section is normative
2.1 USE CASE CONTEXT AND BUSINESS REQUIREMENTS
2.1.1 Baseline
The Catena-X Car SBOM baseline (CX-0158 Car SBOM) defines the common SBOM content that is shared across all use cases requiring software transparency (e.g., ICTS compliance, cybersecurity, license management). The baseline ensures a consistent foundation so that SBOMs created for one use case can be reused and extended for others without duplication of effort. It also regulates how SBOMS are created and shared across the entire supply chain, ensuring interoperability and data quality.
All participants creating or exchanging SBOMs within Catena-X MUST conform to the baseline requirements before applying any use-case-specific extension. Use-case specific extensions only add to the baseline standard, or enforce existing requirements more strictly, but they do not contradict or replace any baseline definitions and requirements.
A SBOM that conforms to the ICTS profile MUST therefore, by definition, also conform to the baseline profile.
2.1.2 ICTS Use Case: Legal and Business Requirements
The ICTS final rule establishes specific requirements that go beyond a general-purpose SBOM. In particular, it requires the identification of software components originating from, or having a nexus to, foreign adversary countries as defined in the rule.
In addition to the baseline, SBOMs intended for ICTS compliance MUST include:
- SupplierSupplier In the context of OSim, the producer of goods. identification information sufficient to determine the country of origin of each software component.
- External identifiers (e.g., CPE, PURL) for software packages where available, to enable cross-referencing with vulnerability databases and supply chain risk assessments.
- Licensing information for each declared software component.
- Build information, when available, to establish provenance and traceability of compiled artifacts.
2.2 LINKS TO CENTRAL RESOURCES AND MODULARITY OF SBOMs
When dealing with modular SBOMs, the following rules apply:
- Each module MUST be a self-contained, valid SPDX document according to CX-0158.
- Cross-document references MUST NOT use the /Core/ExternalRef mechanism. Instead, they MUST use the mechanism described in CX-0158 for creating one coherent SBOM.
- The top-level SBOM MUST declare all direct dependencies via /Core/Relationship with the appropriate /Core/RelationshipType.
2.3 ICTS EXTENSION PROFILE
This standard defines a layered conformance model. Each profile builds upon the previous one.
The ICTS profile extends the Software profile (at minimum) with requirements specific to the ICTS Connected Vehicles regulation. In addition to the Software profile, an SBOM conforming to the ICTS profile MUST include:
- /Core/Agent identifying each supplierSupplier In the context of OSim, the producer of goods. in the software supply chain, with sufficient information to determine the country of origin.
- /Core/ExternalIdentifier for each /Software/Package, containing at least one of CPE or PURL.
- /SimpleLicensing/LicenseExpression for every declared component (not just where available).
An SBOM conforming to the ICTS profile SHOULD additionally include:
- /Build/Build information for all compiled artifacts.
- /Core/Hash values using SHA3-256 or stronger for all artifacts.
2.4 SPDX LANGUAGE ELEMENTS
This section is normative
The following elements are in scope for this standard.
2.4.1 Main Structural Elements
| Property | Profile | Requirement |
|---|---|---|
| /Core/SpdxDocument | Core | REQUIRED |
| /Software/Sbom | Software | REQUIRED |
| /Software/SoftwareArtifact | Software | REQUIRED |
| /Software/Package | Software | REQUIRED |
| /Software/File | Software | RECOMMENDED |
| /Software/Snippet | Software | RECOMMENDED |
| /Build/Build | Build | RECOMMENDED |
/Core/SpdxDocument
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see /Core/spdxId. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, /Core/creationInfo. |
| profileConformance | /Core/ProfileIdentifierType | REQUIRED | The profile that is implemented and followed by the document. Conformance with multiple profiles is possible, the core profile is always fulfilled. The compliance applies to the scope of the element collection and can be overridden by nested collections. |
| element | /Core/Element | REQUIRED | MUST have at least one /Core/Sbom object (required by SPDX Lite Profile). Note: In fact this SHOULD list all elements that are in the scope of the document. |
| rootElement | /Core/Element | REQUIRED | SHOULD be objects of type /Core/Sbom (required by SPDX Lite Profile). Note: In fact this SHOULD be the entry-point to the SBOM-tree. |
| comment | xsd:string | RECOMMENDED | RECOMMENDED comment. Explanatory comment to context of the document. |
| dataLicense | /SimpleLicensing/LicenseExpression | RECOMMENDED | The license expression for this document (the SPDX and metadata, not the artifact that is described). |
| name | xsd:string | RECOMMENDED | The canonical name of the document. This SHOULD correspond with the filename. |
| namespaceMap | /Core/NamespaceMap | RECOMMENDED | See upstream. |
| verifiedUsing | /Core/Hash | RECOMMENDED | The integrity method that can be used to confirm the integrity of this element. |
| description | xsd:string | OPTIONAL | Optional description. |
| Extension | |||
| extension: core.profileConformance | ENUM | REQUIRED | compliance.icts.esdf, compliance.icts.cx |
| extension: compliance.icts.version | xsd:string | REQUIRED | |
| extension: compliance.icts.assessmentUri | xsd:uri | OPTIONAL | The link to the compliance repository entry that contains the compliance information describing the artifact. |
| extension: compliance.icts.isCompliant | xsd:boolean | REQUIRED | Based on the covered-artifact information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.containsCoveredArtifact | xsd:boolean | RECOMMENDED | Covered artifact assessment status based on the architectural assessment. Attention, this represents the real status of the artifact, depending on the usage in the tree this can be decided. |
| extension: compliance.icts.reasoning | ENUM | RECOMMENDED | MUST be one of the following: opensource, legacy, not-covered, empty, direct-submission, covered, undefined |
| extension: compliance.icts.signature | xsd:string | RECOMMENDED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | RECOMMENDED | Reference about the verification method that sets isCompliant to true. |
| extension: compliance.icts.mail | xsd:string | RECOMMENDED | The unique mail that is assigned to the person (specific for ICTS context). |
/Software/Sbom
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see /Core/spdxId. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, /Core/creationInfo. |
| name | xsd:string | REQUIRED | The name of the SBOM, this SHOULD be identical with the canonical name used for storing the file in the SBOM management system. |
| profileConformance | /Core/ProfileIdentifierType | REQUIRED | The SBOM MUST be at minimum conformant with the "lite" and "compliance.icts" (TBC) profiles. If the document complies with other profiles this SHOULD be stated, too. |
| sbomType | /Software/SbomType | REQUIRED | Analyzed: 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. The usage of this type is allowed if analytical post-processing has been done, e.g. CVE-scans. However, annotations may be done in multiple iterations and this can only be a hint that at least one analysis was executed. build: 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. The usage of this type is allowed if the SBOM was created in the build-process. deployed: 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. The usage of this type is allowed if the SBOM reflects the deployment state on the system. This implies that system/target specific configurations are reflected as well as the presence of components in the target. If the SBOM is a super-set of all or multiple potential deployments this MUST NOT be used. design: SBOM of intended, planned software project or product with included components (some of which may not yet exist) for a new software artifact. The usage of this type is allowed for architectural SBOMs that reflect not the actual but the desired state of a system, e.g. a SBOM that was purely build on the specification and can be used for V/V of an actual SBOM. runtime: 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. The usage of this type is allowed if the SBOM is reflecting the actual runtime state, that means it MUST also reflect e.g. properties that are only present after the execution, e.g. apps that are installed after the deployment of an operating system or libraries that are dynamically loaded (e.g. based on user behavior). Other use cases are plug-ins, hooks etc. source: SBOM created directly from the development environment, source files, and included dependencies used to build an product artifact. The usage of this type is allowed if the SBOM was created purely based on the static analysis of the source and package management systems. Recommendation for ICTS use-case: build, after system assembly e.g. deployed (if feasible!). |
| element | /Core/Element | REQUIRED | See upstream. |
| rootElement | /Core/Element | REQUIRED | See upstream. |
| verifiedUsing | /Core/IntegrityMethod | RECOMMENDED | Signature of the SBOM that is qualified to verify the integrity of the SBOM (requiring trusted build). This is not to be confused with the signature of the produced output artifacts, this is the sign-off information of the process itself. |
| comment | xsd:string | OPTIONAL | Optional comment. |
| description | xsd:string | OPTIONAL | Optional description. |
| Extension | |||
| extension: core.profileConformance | ENUM | REQUIRED | compliance.icts.esdf, compliance.icts.cx |
| extension: compliance.icts.version | xsd:string | REQUIRED | |
| extension: compliance.icts.assessmentUri | xsd:uri | RECOMMENDED | The link to the compliance repository entry that contains the compliance information describing the artifact. |
| extension: compliance.icts.isCompliant | xsd:boolean | REQUIRED | Based on the covered-artifact information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.containsCoveredArtifact | xsd:boolean | RECOMMENDED | Covered artifact assessment status based on the architectural assessment. Attention, this represents the real status of the artifact, depending on the usage in the tree this can be decided. |
| extension: compliance.icts.reasoning | ENUM | RECOMMENDED | MUST be one of the following: opensource, legacy, not-covered, empty, direct-submission, covered, undefined |
| extension: compliance.icts.signature | xsd:string | RECOMMENDED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | RECOMMENDED | Reference about the verification method that set isCompliant to true. |
| extension: compliance.icts.mail | xsd:string | RECOMMENDED | The unique mail that is assigned to the person (specific for ICTS context). |
/Software/SoftwareArtifact
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: compliance.icts.version | ENUM | REQUIRED | 2025-00592, the version of the law the properties are referring to. |
| extension: compliance.icts.assessmentUri | xsd:uri | RECOMMENDED | The link to the compliance repository entry that contains the compliance information describing the artifact. |
| extension: compliance.icts.isCompliant | xsd:boolean | REQUIRED | Based on the covered-artifact information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.isCoveredArtifact | xsd:boolean | RECOMMENDED | Covered artifact assessment status based on the architectural assessment. Attention, this represents the real status of the artifact, depending on the usage in the tree this can be decided. |
| extension: compliance.icts.reasoning | ENUM | RECOMMENDED | MUST be one of the following: opensource, legacy, not-covered, empty, direct-submission, covered, undefined |
| extension: compliance.icts.signature | xsd:string | RECOMMENDED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | RECOMMENDED | Reference about the verification method that set isCompliant to true. |
| extension: compliance.icts.mail | xsd:string | RECOMMENDED | The unique mail that is assigned to the person (specific for ICTS context). |
/Software/Package
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see /Core/spdxId. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, /Core/creationInfo. |
| name | xsd:string | REQUIRED | The name of the package, this SHOULD be identical with the canonical name used for storing the file in the binary management system or the upstream name of the package. |
| builtTime | /Core/DateTime | REQUIRED | The time of the original build. If this is an external dependency and no original build time is available (e.g. not SBOM) the time of the integration SHOULD be used. Hint: this can be used to identify legacy components. |
| copyrightText | xsd:string | REQUIRED | The copyright text of the package. |
| originatedBy | /Core/Agent | REQUIRED | The agents that created the component. Usually this will be an organization. Multiple items are allowed. If no extended build information is available additionally a SoftwareAgent could be considered. This SHOULD not reflect the logistics aspects but the origin and creation aspect. If it is e.g. modified OSS the agent that is responsible for the modification SHOULD be used. Note: We work on a central registry approach to avoid scattered information, e.g. each supplierSupplier In the context of OSim, the producer of goods. SHOULD have a uniform entry. |
| packageVersion | xsd:string | REQUIRED | The version of the package. |
| primaryPurpose | /Software/SoftwarePurpose | REQUIRED | Application: The Element is a software application. archive: The Element is an archived collection of one or more files (.tar, .zip, etc.). bom: The Element is a bill of materialsBill of Material A Bill of Material (BoM) represents the structure of a product: a list of raw materials, sub-assemblies and sub-components needed to manufacture the end product. In Catena-X Traceability more than one BoM is considered, since the BoM can change during the lifecycle (different BoMs for different lifecycles).. configuration: The Element is configuration data. container: The Element is a container image which can be used by a container runtime application. data: The Element is data. device: The Element refers to a chipset, processor, or electronic board. deviceDriver: The Element represents software that controls hardware devices. diskImage: The Element refers to a disk image that can be written to a disk, booted in a VM, etc. A disk image typically contains most or all of the components necessary to boot, such as bootloaders, kernels, firmware, userspace, etc. documentation: The Element is documentation. evidence: The Element is the evidence that a specification or requirement has been fulfilled. executable: The Element is an Artifact that can be run on a computer. file: The Element is a single file which can be independently distributed (configuration file, statically linked binary, Kubernetes deployment, etc.). filesystemImage: The Element is a file system image that can be written to a disk (or virtual) partition. firmware: The Element provides low level control over a device's hardware. framework: The Element is a software framework. install: The Element is used to install software on disk. library: The Element is a software library. manifest: The Element is a software manifest. model: The Element is a machine learning or artificial intelligence model. module: The Element is a module of a piece of software. operatingSystem: The Element is an operating system. other: The Element doesn't fit into any of the other categories. patch: The Element contains a set of changes to update, fix, or improve another Element. platform: The Element represents a runtime environment. requirement: The Element provides a requirement needed as input for another Element. source: The Element is a single or a collection of source files. specification: The Element is a plan, guideline or strategy how to create, perform or analyze an application. test: The Element is a test used to verify functionality on an software element. Further reading: /Software/SoftwarePurpose |
| suppliedBy | /Core/Agent | REQUIRED | The supplierSupplier In the context of OSim, the producer of goods. agents of the package. This usually will be a SoftwareAgent, ideally the internal binary management system our internal VCS system. Other sources could be upstream registries or supplierSupplier In the context of OSim, the producer of goods. binary management systems. This is not to be used for the authorship but for the logistics aspect. |
| verifiedUsing | /Core/IntegrityMethod | RECOMMENDED | Signature of the package that is qualified to verify the integrity of the package (requiring trusted build or download from a trusted source that is providing the digest/signature of the package). |
| description | xsd:string | RECOMMENDED | Description that is explaining and summarizing the content of the package. |
| attributionText | xsd:string | RECOMMENDED | Holds the attribution texts of the package. This can be multiple texts and selection may also depend on the used/effective license. |
| downloadLocation | xsd:anyURI | RECOMMENDED | ATTENTION: if not present packageUrl MUST be set. |
| homePage | xsd:anyURI | RECOMMENDED | The homepage of the project or registry. |
| packageUrl | xsd:anyURI | RECOMMENDED | ATTENTION: if not present downloadLocation MUST be set. |
| releaseTime | /Core/DateTime | RECOMMENDED | The time the package was released. ATTENTION: for internal top-level package descriptions this SHOULD be set with the release of the component. |
| supportLevel | /Core/SupportType | RECOMMENDED | The support level of the package. ATTENTION: for internal top-level packages this MUST be set, external libs that have limited support (e.g. testing, experimental usage) MUST declare this, too. deployed: in addition to being supported by the supplierSupplier In the context of OSim, the producer of goods., the software is known to have been deployed and is in use. For a software as a service provider, this implies the software is now available as a service. development: the artifact is in active development and is not considered ready for formal support from the supplierSupplier In the context of OSim, the producer of goods.. endOfSupport: there is a defined end of support for the artifact from the supplierSupplier In the context of OSim, the producer of goods.. This may also be referred to as end of life. There is a validUntilDate that can be used to signal when support ends for the artifact. limitedSupport: the artifact has been released, and there is limited support available from the supplierSupplier In the context of OSim, the producer of goods.. There is a validUntilDate that can provide additional information about the duration of support. noAssertion: no assertion about the type of support is made. This is considered the default if no other support type is used. noSupport: there is no support for the artifact from the supplierSupplier In the context of OSim, the producer of goods., consumer assumes any support obligations. support: the artifact has been released, and is supported from the supplierSupplier In the context of OSim, the producer of goods.. There is a validUntilDate that can provide additional information about the duration of support. |
| validUntilTime | /Core/DateTime | RECOMMENDED | Specification of the re-assessment date. This SHOULD help to keep components fresh according to project's update policies. Details to be clarified. |
| comment | xsd:string | OPTIONAL | Optional comment. |
| sourceInfo | xsd:string | OPTIONAL | Optional information about the origin of a package of special annotations. Note: it may be preferred to have standardized ICTS fields for that if required. |
| externalIdentifier | /Core/ExternalIdentifier | RECOMMENDED | See upstream. |
| - CPE23 (mandatory per component) | CPE 2.3 | RECOMMENDED | |
| - cve (for vulnerabilities) | CVE Identifier | RECOMMENDED | |
| externalRef | /Core/ExternalRef | RECOMMENDED | See upstream. |
| - securityAdvisory | VEX | RECOMMENDED | |
| - vulnerabilityExploitability Assesment | OpenVex | RECOMMENDED | |
| - securityFix | VEX | RECOMMENDED | |
| - securityPolicy | VEX | RECOMMENDED | |
| - securityThreatModel | VEX | RECOMMENDED | |
| constraint: downloadLocation or packageUrl | logical constraint | REQUIRED | |
| constraint: for every /Software/Package object MUST exist exactly one /Core/Relationship object of type hasConcludedLicense having that element as its from property and an /SimpleLicensing/AnyLicenseInfo as its to property. | /Core/Relationship [type="hasConcludedLicense"] | REQUIRED | |
| constraint: for every /Software/Package object MUST exist exactly one /Core /Relationship object of type hasDeclaredLicense having that element as its from property and /SimpleLicensing/AnyLicenseInfo object as its to property. | /Core/Relationship [type="hasDeclaredLicense"] | REQUIRED |
/Software/File
| Property | Type | Requirement | Description |
|---|---|---|---|
| Specification at work. Property-set similar to package. |
/Software/Snippet
| Property | Type | Requirement | Description |
|---|---|---|---|
| Specification at work. Property-set similar to package. |
/Build/Build
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see type definition. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, see type definition. |
| name | xsd:string | REQUIRED | The name of the build, this SHOULD identify the build-job. |
| buildEndTime | /Core/DateTime | REQUIRED | The time the build job has finished. |
| buildId | xsd:string | REQUIRED | The unique id of the build execution. |
| buildStartTime | /Core/DateTime | REQUIRED | The time the build job has started. |
| buildType | xsd:anyURI | REQUIRED | The unique identifier of the toolchain and CI that was used to execute the build. |
| configSourceDigest | /Core/Hash | REQUIRED | Signature of the build configuration that was used. |
| configSourceEntrypoint | xsd:string | REQUIRED | The entry point for starting the job execution within the given configuration. See upstream documentation for details. |
| configSourceUri | xsd:anyURI | REQUIRED | Link to the CI configuration files. |
| environment | /Core/DictionaryEntry | REQUIRED | The environment parameters of the build. This is specific to the CI environment that build was executed in: modeled as environment parameter or /Core/Agent Cloud Provider, e.g. Amazon Web Services, Inc Cloud Region, e.g. eu-west-1 |
| parameter | /Core/DictionaryEntry | REQUIRED | The input parameters for the build. This is specific to the build-invocation. |
| verifiedUsing | IntegrityMethod | RECOMMENDED | Signature of the build job that is qualified to verify the integrity of the build (trusted build). This is not to be confused with the signature of the produced output artifacts, this is the sign-off information of the process itself. |
| comment | xsd:string | OPTIONAL | Optional comment. |
| description | xsd:string | OPTIONAL | Optional description. |
| Extension | |||
| extension: compliance.icts.version | xsd:string | REQUIRED | |
| extension: compliance.icts.assessmentUri | xsd:uri | RECOMMENDED | The link to the compliance repository entry that contains the compliance information describing the artifact. |
| extension: compliance.icts.isCompliant | xsd:boolean | REQUIRED | Based on the covered-artifact information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.producesCoveredArtifacts | xsd:boolean | RECOMMENDED | States if the build produces covered artifacts (manufacture step). |
| extension: compliance.icts.reasoning | ENUM | RECOMMENDED | MUST be one of the following: opensource, legacy, not-covered, empty, direct-submission, covered, undefined |
| extension: compliance.icts.signature | xsd:string | RECOMMENDED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | RECOMMENDED | Reference about the verification method that set isCompliant to true. |
| extension: compliance.icts.mail | xsd:string | RECOMMENDED | The unique mail that is assigned to the person (specific for ICTS context). |
2.4.2 Main Shared Elements
| Property | Type | Requirement |
|---|---|---|
| /Core/Agent | Superclass | REQUIRED |
| ├──/Core/Person | Subclass | |
| ├──/Core/Organization | Subclass | |
| ├──/Core/SoftwareAgent | Subclass | |
| /Core/Tool | Class | REQUIRED |
/Core/Agent
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see type definition |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, see type definition |
| name | xsd:string | REQUIRED | Depending on sub-class convention |
| comment | xsd:string | OPTIONAL | Free text comment, for semantic information extension fields SHOULD be preferred. |
| description | xsd:string | OPTIONAL | Free text description, for semantic information extension fields SHOULD be preferred. |
| summary | xsd:string | OPTIONAL | Free text summary, for semantic information extension fields SHOULD be preferred. |
| Extension | |||
| extension: compliance.icts.version | xsd:string | REQUIRED | |
| extension: compliance.icts.isCompliant | xsd:boolean | REQUIRED | Based on the covered-entity information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.isCoveredEntity | xsd:boolean | REQUIRED | An aggregated assessment information if an entity is to be considered to be a "covered Person" according to the US regulation ICTS. Software-agents are technical identities and SHOULD be threaded either as proxy of a natural person or as synonym for an organization. Be aware that the covered status of the software MUST not be represented in software-agents, but in their related tools entry. |
| extension: compliance.icts.countryOfOrigin | xsd:string | REQUIRED | The code representation of a country or an area of special sovereignty. By default it is a valid 2 character country code as defined by the ISO standard 3166-1 alpha-2 - Codes for representation of countries https://www.iso.org/iso-3166-country-codes.html. |
| extension: compliance.icts.nationality | xsd:string | REQUIRED | The code representation of a country or an area of special sovereignty. By default it is a valid 2 character country code as defined by the ISO standard 3166-1 alpha-2 - Codes for representation of countries https://www.iso.org/iso-3166-country-codes.html. This applies to natural persons. |
| extension: compliance.icts.jurisdiction | xsd:string | REQUIRED | The code representation of a country or an area of special sovereignty. By default it is a valid 2 character country code as defined by the ISO standard 3166-1 alpha-2 - Codes for representation of countries https://www.iso.org/iso-3166-country-codes.html. This applies to organizations. |
| extension: compliance.icts.underForeignDirection | xsd:boolean | REQUIRED | Defined if the entity is under foreign direction according to the ICTS regulation, e.g. a majority of the company is owned by a covered entity. |
| extension: compliance.icts.legalAddress | xsd:string | REQUIRED | The code representation of a country or an area of special sovereignty. By default it is a valid 2 character country code as defined by the ISO standard 3166-1 alpha-2 - Codes for representation of countries https://www.iso.org/iso-3166-country-codes.html. This applies to organizations. |
| extension: compliance.icts.signature | xsd:string | REQUIRED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | REQUIRED | Reference about the verification method that set isCompliant to true. |
| extension: compliance.icts.mail | xsd:string | REQUIRED | The unique mail that is assigned to the person (specific for ICTS context). |
/Core/Person
Extends: /Core/Agent
| Property | Type | Requirement | Description |
|---|---|---|---|
| Property-set similar to parent. | The legal name of the person as stated in the passport, <first-name> <surname> (depending on country this may have a different order) |
/Core/Organization
Extends: /Core/Agent
| Property | Type | Requirement | Description |
|---|---|---|---|
| Property-set similar to parent. | The canonical name of the organization that is used for the legal entity. No trademarks or abbreviations. |
/Core/SoftwareAgent
Extends: /Core/Agent
| Property | Type | Requirement | Description |
|---|---|---|---|
| Property-set similar to parent. | The canonical name of the software-agent. This SHOULD be as specific as possible, e.g. AWS-DATACENTER-EU-WEST or a technical identity with a clearly defined scope and responsibility. For technical identities the name SHOULD match the primary key. It SHOULD be the unchangeable unique mail-address assigned to the user account. |
/Core/Tool
Extends: /Core/Element | Related to: /Core/Agent
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see type definition |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, see type definition |
| name | xsd:string | REQUIRED | The canonical name of the tool. This SHOULD represent the name that is used by the vendor - if applicable in combination with an internal name, e.g. "CodeCraft GitHub" |
| comment | xsd:string | OPTIONAL | Free text comment, for semantic information extension fields SHOULD be preferred. |
| description | xsd:string | OPTIONAL | Free text description, for semantic information extension fields SHOULD be preferred. |
| summary | xsd:string | OPTIONAL | Free text summary, for semantic information extension fields SHOULD be preferred. |
| Extension | |||
| extension: core.version | xsd:string | REQUIRED | The version of the tool. This schema is defined by the vendor or creator of the tool. For cloud services the deployment ID SHOULD be used. |
| extension: compliance.icts.version | xsd:string | REQUIRED | |
| extension: compliance.icts.isCompliant | xsd:boolean | REQUIRED | Based on the covered-entity information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.signature | xsd:string | RECOMMENDED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | RECOMMENDED | Reference about the verification method that set isCompliant to true. |
| extension: compliance.icts.mail | xsd:string | RECOMMENDED | The unique mail that is assigned to the person (specific for ICTS context). |
2.4.3 Supporting Elements
| Property | Type | Requirement | Description |
|---|---|---|---|
| /Core/Relationship | REQUIRED | ||
| type="contains": /Core/Organization /Core/Organization | |||
| type="contains": /Core/Organization /Core/Person | |||
| type="contains": /Core/Package /Core/Package | |||
| type="contains": /Core/Package /Core/File | |||
| type="contains": /Core/File /Core/Snippet | |||
| type="dependsOn":/Build/Build /Build/Build | |||
| type="hasDeclaredLicense": /Core/Element /Simplelicensing/LicenseExpression | |||
| type="hasHost": /Build/Build /Core/SoftwareAgent | |||
| type="hasInput": /Build/Build /Software/Packagetype="hasInput": /Build/Build /Software/File | |||
| type="hasOutput": /Build/Build /Software/Package | |||
| type="hasOutput": /Build/Build /Software/File | |||
| type="invokedBy": /Build/Build /Core/Agent | |||
| type="modifiedBy": /Software/SoftwareArtifact /Core/Person | |||
| type="publishedBy": /Core/Tool /Core/Agent | |||
| type="publishedBy": /Core/SoftwareAgent /Core/Agent | |||
| type="useTool": /Build/Build /Core/Tool | |||
| type="useTool": /Core/SpdxDocument/Core/Tool | |||
| /Core/RelationshipType | ENUM | REQUIRED | |
| /Core/ProfileIdentifierType | ENUM | REQUIRED | |
| /Core/MediaType | ENUM | REQUIRED | |
| /Core/ExternalRef | REQUIRED | ||
| /Core/ExternalRefType | ENUM | REQUIRED | A reference to a version control system related to a software artifact. |
| /Core/Hash | REQUIRED | ||
| /Core/HashAlgorithm | ENUM | REQUIRED | |
| /Core/CreationInfo | REQUIRED | ||
| /Software/SoftwarePurpose | ENUM | REQUIRED | |
| /SimpleLicensing/LicenseExpression | REQUIRED | ||
| /SimpleLicensing/SimpleLicensingText | REQUIRED | ||
| /Security/Vulnerability | OPTIONAL | ||
| /Security/VexAffectedVulnAssessmentRelationship | OPTIONAL | ||
| /Security/VexFixedVulnAssessmentRelationship | OPTIONAL | ||
| /Security/VexNotAffectedVulnAssessmentRelationship | OPTIONAL |
/Core/Relationship
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see /Core/spdxId. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, see /Core/creationInfo. |
| relationshipType | /Core/RelationshipType | REQUIRED | Type of the relationship |
| from | /Core/Element | REQUIRED | Source element, see relationship-types for detailed semantics |
| to | /Core/Element | REQUIRED | Source element, see relationship-types for detailed semantics |
| verifiedUsing | /Core/IntegrityMethod | RECOMMENDED | Signature of the relation. Depending on the relation type. Semantic depending on the relation type. |
| completeness | /Core/RelationshipCompleteness | RECOMMENDED | Definition if the relationship is complete and covering all potential relations or if only a sub-set is covered. |
| name | xsd:string | RECOMMENDED | Depending on type's convention |
| endTime | /Core/DateTime | RECOMMENDED | The time when the relation becomes invalid. Semantic depending on the relation type. |
| startTime | /Core/DateTime | RECOMMENDED | The time when the relation becomes valid. Semantic depending on the relation type. |
| comment | xsd:string | OPTIONAL | Optional comment. |
| description | xsd:string | OPTIONAL | Optional description. |
type="contains": /Core/Organization /Core/Organization
| Property | Type | Requirement | Description |
|---|---|---|---|
| No dedicated requirements. |
type="contains": /Core/Organization /Core/Person
| Property | Type | Requirement | Description |
|---|---|---|---|
| startTime | /Core/DateTime | RECOMMENDED | |
| endTime | /Core/DateTime | RECOMMENDED |
type="hasHost": /Build/Build /Core/SoftwareAgent
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: core.agent.usageType | ENUM | RECOMMENDED |
type="hasInput": /Build/Build /Software/Packagetype="hasInput": /Build/Build /Software/File
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: compliance.icts.isCoveredArtifact | xsd:boolean | RECOMMENDED | Covered artifact assessment status based on the architectural assessment. Attention, this represents the real status of the artifact, depending on the usage in the tree this can be decided. |
type="hasOutput": /Build/Build /Software/File
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: compliance.icts.isCoveredArtifact | xsd:boolean | RECOMMENDED | Covered artifact assessment status based on the architectural assessment. Attention, this represents the real status of the artifact, depending on the usage in the tree this can be decided. |
type="modifiedBy": /Software/SoftwareArtifact /Core/Person
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: software.commit.message | xsd:string | REQUIRED | |
| extension: software.commit.hash | xsd:string | REQUIRED | |
| extension: software.commit.time | xsd:string | REQUIRED | |
| extension: software.commit.file | xsd:string | REQUIRED | |
| extension: software.commit.signature | xsd:string | REQUIRED | |
| extension: compliance.icts.version | xsd:string | REQUIRED | 2025-00592, the version of the law the properties are referring to. |
| extension: compliance.icts.isCompliant | xsd:boolean | RECOMMENDED | Based on the covered-artifact information this is the summary for the overall compliance evaluation. Usually this SHOULD be the same value. In rare cases this may differ, e.g. if there are additional reasons that would make a non-covered person incompliant or the other way round. E.g. a person is temporarily in a covered country or was gained an explicit approval. |
| extension: compliance.icts.signature | xsd:string | RECOMMENDED | Signature of the icts compliance approving entity. |
| extension: compliance.icts.signedOffBy | xsd:string | RECOMMENDED | Reference about the verification method that sets isCompliant to true. |
| extension: compliance.icts.reasoning | ENUM | RECOMMENDED | MUST be one of the following: opensource, legacy, not-covered, empty, direct-submission, covered, undefined |
type="useTool": /Build/Build /Core/Tool
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: core.tool.usageType | ENUM | RECOMMENDED |
type="useTool": /Core/SpdxDocument/Core/Tool
| Property | Type | Requirement | Description |
|---|---|---|---|
| Extension | |||
| extension: core.tool.usageType | ENUM | RECOMMENDED |
/Core/ExternalRef
| Property | Type | Requirement | Description |
|---|---|---|---|
| externalRefType | /Core/ExternalRefType | REQUIRED | The type of the external source. |
| locator | xsd:string | REQUIRED | Various links to external sources. They MUST have all the same type. |
| contentType | /Core/MediaType | RECOMMENDED | The media type of the content. |
| comment | xsd:string | OPTIONAL | Optional comment. |
/Core/Hash
| Property | Type | Requirement | Description |
|---|---|---|---|
| algorithm | /Core/HashAlgorithm | REQUIRED | The hash algorithm that is used to create the hash value. |
| hashValue | xsd:string | REQUIRED | The hash value. This value MUST be generated by using the specified algorithm above. Please stick to standard implementations and standard encodings. |
| comment | xsd:string | RECOMMENDED | Optional comment. |
/Core/CreationInfo
| Property | Type | Requirement | Description |
|---|---|---|---|
| created | /Core/DateTime | REQUIRED | The creation time of the object. |
| createdBy | /Core/Agent | REQUIRED | The agents that triggered the creation of the entry. This SHOULD usually be a /Core/SoftwareAgent. E.g. the CI. In some cases this could also be a person or organization, e.g. if something was build locally or provided externally. |
| createdUsing | /Core/Tool | REQUIRED | The tool that was used to create the entry. This SHOULD usually be the SBOM generator. |
| specVersion | /Core/SemVer | REQUIRED | The version of the SPDX specification. |
| comment | xsd:string | OPTIONAL | Optional comment. |
/SimpleLicensing/LicenseExpression
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see /Core/spdxId. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, /Core/creationInfo. |
| licenseExpression | xsd:string | REQUIRED | A string in the license expression format. B. SPDX license expressions - SPDX Specification 3.0.1 requirements MUST be respected. |
| licenseListVersion | /Core/SemVer | RECOMMENDED | The semantic version of the license list version. SPDX License List | Software Package Data Exchange (SPDX). |
| comment | xsd:string | OPTIONAL | Optional comment. |
| description | xsd:string | OPTIONAL | Optional description. |
| name | xsd:string | OPTIONAL | The canonical name of the license. |
/SimpleLicensing/SimpleLicensingText
| Property | Type | Requirement | Description |
|---|---|---|---|
| spdxId | xsd:anyURI | REQUIRED | Unique Identifier, see /Core/spdxId. |
| creationInfo | /Core/CreationInfo | REQUIRED | Creation Information, /Core/creationInfo. |
| licenseText | xsd:string | REQUIRED | A licenseText contains the plain text of the License or Addition, without templating or other similar markup. |
| comment | xsd:string | RECOMMENDED | Optional comment. |
| description | xsd:string | OPTIONAL | Optional description. |
2.5 OPEN QUESTIONS AND KNOWN LIMITATIONS
This section is non-normative
The following topics are identified as open questions or known limitations that will be addressed in future revisions of this standard:
- Example of an ICTS compliant SBOM
- Closer coupling with the baseline standard and moving some of the introduced properties there (among others, an SBOM core, shared by use-cases).
3 REFERENCES
3.1 NORMATIVE REFERENCES
- CX-0158 Car SBOM v1.0.0 (and all references of CX-0158, recursively)
3.2 NON-NORMATIVE REFERENCES
This section is non-normative
- SPDX License List: https://spdx.org/licenses/
- Package URL (PURL) Specification: https://github.com/package-url/purl-spec
- 15 CFR Part 791 - Securing the Information and Communications Technology and Services Supply Chain: https://www.federalregister.gov/documents/2024/12/06/2024-28335/securing-the-information-and-communications-technology-and-services-supply-chain
- ISO standard 3166-1 alpha-2 - Codes for representation of countries: https://www.iso.org/iso-3166-country-codes.html
- All references of CX-0158, recursively
ANNEXES
FIGURES
This section is non-normative
TABLES
This section is non-normative
Legal
Copyright © 2026 Catena-X Automotive Network e.V. All rights reserved. For more information, please visit here.