cyclonedx / specification

OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM, OBOM, MBOM, VDR, and VEX

CycloneDX Specification

OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. The specification supports:

• Software Bill of Materials (SBOM)
• Software-as-a-Service Bill of Materials (SaaSBOM)
• Hardware Bill of Materials (HBOM)
• Machine Learning Bill of Materials (ML-BOM)
• Cryptography Bill of Materials (CBOM)
• Manufacturing Bill of Materials (MBOM)
• Operations Bill of Materials (OBOM)
• Vulnerability Disclosure Reports (VDR)
• Vulnerability Exploitability eXchange (VEX)
• CycloneDX Attestations (CDXA)

Introduction

Modern software is assembled using third-party and open source components, glued together in complex and unique ways, and integrated with original code to achieve the desired functionality. An accurate inventory of all components enables organizations to identify risk, allows for greater transparency, and enables rapid impact analysis.

CycloneDX was created for this purpose.

Strategic direction and maintenance of the specification is managed by the CycloneDX Core Working Group, is backed by the OWASP Foundation, and is supported by the global information security community.

Use Cases

The CycloneDX project maintains a list of achievable use cases. Examples for each use case are provided in both XML and JSON.

Tool Center

The CycloneDX Tool Center is a community effort to establish a marketplace of free, open source, and proprietary tools and solutions that support the CycloneDX specification.

Media Types

The following media types are officially registered with IANA:

Media Type	Format	Assignment
application/vnd.cyclonedx+xml	XML	IANA
application/vnd.cyclonedx+json	JSON	IANA

Specific versions of CycloneDX can be specified by using the version parameter. For example: application/vnd.cyclonedx+xml; version=1.6.

The officially supported media type for Protocol Buffer format is application/x.vnd.cyclonedx+protobuf.

Release History

Version	Release Date
CycloneDX 1.6	09 April 2024
CycloneDX 1.5	26 June 2023
CycloneDX 1.4	12 January 2022
CycloneDX 1.3	04 May 2021
CycloneDX 1.2	26 May 2020
CycloneDX 1.1	03 March 2019
CycloneDX 1.0	26 March 2018
Initial Prototype	01 May 2017

Copyright & License

CycloneDX Specification is Copyright (c) OWASP Foundation. All Rights Reserved.

Permission to modify and redistribute is granted under the terms of the Apache License 2.0

specification's Issues

Optionally include license text in the License element

This is an enhancement proposal to the CycloneDX specification to support license text.

...
            <licenses>
                <license>
                    <name>Juanjo's made-up License</name>
                    <text>Juanjo Diaz(r) Source Code License Agreement\n\nCopyright(c) 2019 Juanjo Diaz. All rights reserved.</text>
                </license>
            </licenses>
...

There is two use cases for this:

• Non-standard licenses that have their own license text
• Standard Licenses that has placeholders (like MIT with the year and the owner, https://spdx.org/licenses/MIT.html#licenseText)

This is specially important for licenses that require it's to be include in any derivative work.

In somes cases this can be automatically obtained from the LICENSE or LICENSE.md file in the asset (specially node or python). NuGet only seem to include the license URL as NPM does (optionally) so a url field might be also a good addition to the license element.

This proposal might be somehow related to #7 which proposed generic external reference to include, among other, the URL containing the full text of the license. However, I think that this would fit better in the license element.

Assemblies of components or services fail validation in JSON

The JSON schema contains a defect that prohibits validation of nested component or service assemblies. The omission of this capability means that BOMs in JSON format that contain assemblies which SHOULD validate successfully, do not.

Add additional component types

In addition to the existing component types, the proposal is to add the following as new types:

• image (a vector or raster image)
• font
• container

One thing of possible confusion is the word 'container'. By container, this is meant to be equal to a Docker image or running container regardless of deployment (could be running in a standalone container or in a pod).

Consider using license expressions rather than a list of licenses

These are specified in SPDX and provide a clean short hand for eventually complex licensing. See for instance its emerging use in the latest Linux kernel. NB: I helped there and I am an SPDX co-founder.

RFC: Add per component and per BOM key/value pairs

There are times when adopters and implementors of CycloneDX need to specify data that falls outside of what the spec provides. Vendor specific schema extensions are one way to accomplish that, however, it also leads to vendor lock-in.

Therefore, it is desirable to support per component and per bom key/value stores.

For example:

<component type="library">
    <name>Acme Component</name>
    <version>1.0.0</version>
    <properties>
        <property name="myprop" value="myvalue"/>
    </properties>
</component>

This allows a certain degree of customization without having to use vendor-specific extensions. Support for properties inside of other objects (e.g. supplier and license) may also be desirable.

Add excluded to scope types

This is an enhancement proposal to the CycloneDX specification to add support for excluded components.

Currently, scope defines both required and optional components. This enhancement would be to support excluded components. Components may be excluded from runtime (and thus have reduce risk) due to a number of reasons, among them are test components, which are neither required for runtime or optional at runtime.

Add optional XML Signature support

This is an enhancement proposal to the CycloneDX specification to add optional support for XML Signature. Signed BOMs can provide integrity validation to ensure the BOM has not been tampered with. This proposal is to add a global <Signature> element in the bom after the list of components. The signature is optional.

Add JSON Schema to Schemastore

Add CycloneDX v1.2 and v1.3 to https://www.schemastore.org/ once v1.3 has been published.

Extension Schema: Services

Initial conversation started April 2019 but failed to get traction
https://groups.io/g/CycloneDX/message/3

This ticket is to document using external services using a schema extension.

---

Currently, CycloneDX allows users to track:

application
framework
library
operating-system
device
file

This schema extension is to provide support for documenting services.

For example:

• an application that relies on various FaaS (i.e. something deployed to AWS Lambda)
• micro-services architectures that have a dependency on each other
• the use of a freely available web service (which itself has usage restrictions (similar to license restrictions))

There are a few things about service components that interest me:

• They could document if an application (or component) crosses a trust boundary
• They could document protocols, ports, and data transfer formats used (not the formats themselves)
• They could document components which do not have local functionality, but rather are a shim to a service which provides the functionality

I don't think the creation of BOMs with service components could be automated in any way. But I do think that known services could be documented in an XML fragment and appended to the BOM when it's created without much issue.

Catch-All: All 1.1 specification commits

Add support for SWID tags

CycloneDX will need to support SWID tags in the future as the replacement for CPE.

The CPE field in CycloneDX was deprecated in v1.1 of the spec. The proposal would be to add a new field in v1.2 to support SWID tags.

I think the field would likely need to be a CNAME or base64 encoded by default as SWID tags are not a single text field rather an entire document. So we may need to support SWID similar to how license files are supported today.

add information about applied patches (inc. fixed vulnerabilities)

It could be useful to add a the list of applied patches in the pedigree section, especially to list fixed CVEs.

A patch element should provide the following information:

• type of patch: backport, etc...
• the IDs of the issues that ar fixed, ex: CVE-XXXX-XXXXX
• optionally the origin of the patch (commit, file url...)

Example of what I have in mind:

<component type="library">
    <publisher>My Company</publisher>
    <group>my_group</group>
    <name>libexample</name>
    <version>1.4.3-3</version>
    <hashes>
        <hash alg="SHA-1">ed6db76a482fde1a5298970e442c531729119e37</hash>
    </hashes>
    <pedigree>
        <ancestors>
            <component type="library">
                <publisher>Example Org</publisher>
                <group>example_group</group>
                <name>libexample</name>
                <version>1.4.3</version>
                <licenses>
                    <license>
                        <id>MIT</id>
                    </license>
                </licenses>                        
            </component>
        </ancestors>
        <patches>
            <patch type="backport">
                <fixes>
                    <fix type="security">
                        <issue-ref type="cve" >CVE-2019-9999</issue-ref>
                    </fix>
                </fixes>
            </patch>
        </patches>
    </pedigree>
</component>

Framework vs Library

Hi,

What is the difference between "framework" and "library"? I could not find the exact definition in the documentation.

Thank you.

Add support for component pedigree

This is an enhancement proposal to the CycloneDX specification to support ancestors. This would be useful for forks of projects that have modifications in which the identification of the component has changed.

The modified flag can be used if the component metadata has not changed. For example, if Apache Tomcat was modified but the group, name, version, etc remained the same. If this data has been modified, it may be impossible to perform accurate analysis with the modified data.

The proposal is to add ancestors in which a component descends from. Ancestors is a list of 0-n components, so if a component used the Maven shade plugin for example, this would aggregate one or more components into a single one. In the following example, Apache Tomcat has been modified by Acme Inc.

With ancestors, it would be possible to track the origin of each component so that accurate analysis can be performed at each level of the tree.

For example:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.1" version="1">
    <components>
        <component type="application">
            <publisher>Acme Inc</publisher>
            <group>com.acme</group>
            <name>tomcat-catalina</name>
            <version>9.0.14</version>
            <licenses>
                <license>
                    <id>Apache-2.0</id>
                </license>
            </licenses>
            <purl>pkg:maven/com.acme/[email protected]?packaging=jar</purl>
            <modified>false</modified>
            <ancestors>
                <component type="application">
                    <publisher>Apache</publisher>
                    <group>org.apache.tomcat</group>
                    <name>tomcat-catalina</name>
                    <version>9.0.14</version>
                    <licenses>
                        <license>
                            <id>Apache-2.0</id>
                        </license>
                    </licenses>
                    <purl>pkg:maven/org.apache.tomcat/[email protected]?packaging=jar</purl>
                    <modified>false</modified>
                </component>
            </ancestors>
        </component>
    </components>
</bom>

Added SPDX 3.2 Support

SPDX 3.2 has a current ETA of June 30. Add support when complete.

Support blake2 and blake3

Consider purl Package URLs for package identification

FYI, this is an emerging spec package-url/purl-spec#1
You may be interested in it and may want to consider using it here.

Rename "manufacture" to "manufacturer"?

Would it be possible to rename "manufacture" to "manufacturer" (or deprecate old and add new)?

Maybe something like:

diff --git a/schema/bom-1.3-SNAPSHOT.schema.json b/schema/bom-1.3-SNAPSHOT.schema.json
index 8787ba7..e02949e 100644
--- a/schema/bom-1.3-SNAPSHOT.schema.json
+++ b/schema/bom-1.3-SNAPSHOT.schema.json
@@ -107,8 +107,8 @@
           "description": "The component that the BOM describes.",
           "$ref": "#/definitions/component"
         },
-        "manufacture": {
-          "title": "Manufacture",
+        "manufacturer": {
+          "title": "Manufacturer",
           "description": "The organization that manufactured the component that the BOM describes.",
           "$ref": "#/definitions/organizationalEntity"
         },
diff --git a/schema/bom-1.3-SNAPSHOT.xsd b/schema/bom-1.3-SNAPSHOT.xsd
index 9119864..dfe283c 100644
--- a/schema/bom-1.3-SNAPSHOT.xsd
+++ b/schema/bom-1.3-SNAPSHOT.xsd
@@ -71,7 +71,7 @@ limitations under the License.
                     <xs:documentation>The component that the BOM describes.</xs:documentation>
                 </xs:annotation>
             </xs:element>
-            <xs:element name="manufacture" type="bom:organizationalEntity" minOccurs="0" maxOccurs="unbounded">
+            <xs:element name="manufacturer" type="bom:organizationalEntity" minOccurs="0" maxOccurs="unbounded">
                 <xs:annotation>
                     <xs:documentation>The organization that manufactured the component that the BOM describes.</xs:documentation>
                 </xs:annotation>
@@ -231,7 +231,7 @@ limitations under the License.
             <xs:element name="supplier" type="bom:organizationalEntity" minOccurs="0" maxOccurs="1">
                 <xs:annotation>
                     <xs:documentation>The organization that supplied the component. The supplier may often
-                        be the manufacture, but may also be a distributor or repackager.</xs:documentation>
+                        be the manufacturer, but may also be a distributor or repackager.</xs:documentation>
                 </xs:annotation>
             </xs:element>
             <xs:element name="author" type="xs:normalizedString" minOccurs="0" maxOccurs="1">
diff --git a/schema/ext/bom-descriptor-1.0.xsd b/schema/ext/bom-descriptor-1.0.xsd
index 013f550..cc6447b 100644
--- a/schema/ext/bom-descriptor-1.0.xsd
+++ b/schema/ext/bom-descriptor-1.0.xsd
@@ -66,7 +66,7 @@ limitations under the License.
           <xs:documentation>The component that the BOM describes.</xs:documentation>
         </xs:annotation>
       </xs:element>
-      <xs:element name="manufacture" type="bd:organizationalEntity" minOccurs="0" maxOccurs="unbounded">
+      <xs:element name="manufacturer" type="bd:organizationalEntity" minOccurs="0" maxOccurs="unbounded">
         <xs:annotation>
           <xs:documentation>The organization that manufactured the component that the BOM describes.</xs:documentation>
         </xs:annotation>

And the examples (noting 1.2 can't be changed) would then be:

diff --git a/tools/src/test/resources/valid-metadata-manufacture-1.2.json b/tools/src/test/resources/valid-metadata-manufacture-1.2.json
index fb92230..68c7aff 100644
--- a/tools/src/test/resources/valid-metadata-manufacture-1.2.json
+++ b/tools/src/test/resources/valid-metadata-manufacture-1.2.json
@@ -4,7 +4,7 @@
   "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
   "version": 1,
   "metadata": {
-    "manufacture": {
+    "manufacturer": {
       "name": "Acme, Inc.",
       "url": [
         "https://example.com"
diff --git a/tools/src/test/resources/valid-metadata-manufacture-1.2.xml b/tools/src/test/resources/valid-metadata-manufacture-1.2.xml
index b6773a5..c6313d4 100644
--- a/tools/src/test/resources/valid-metadata-manufacture-1.2.xml
+++ b/tools/src/test/resources/valid-metadata-manufacture-1.2.xml
@@ -1,14 +1,14 @@
 <?xml version="1.0"?>
 <bom serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1" xmlns="http://cyclonedx.org/schema/bom/1.2">
     <metadata>
-        <manufacture>
+        <manufacturer>
             <name>Acme, Inc.</name>
             <url>https://example.com</url>
             <contact>
                 <name>Acme Professional Services</name>
                 <email>[email protected]</email>
             </contact>
-        </manufacture>
+        </manufacturer>
     </metadata>
     <components />
 </bom>

Add SPDX 3.3 Support

https://github.com/spdx/license-list-XML/milestone/5

Generate SBoMs for Asset / Tools used

Hi Steve,
I understand Cyclone DX generates SBoMs for software packages/librries/frameworks. Does it also generate an SBoM for applications/tools installed in a machine. Ex: in my laptop I have about 20 applications installed (Node JS, Visual Studio Code, Sublime Text ...). Can I generate an SBoM for such applications (found within Program Files) ?

Promote and enhance vulnerability schema

Thanks for creating the JSON Schema variant of the vulnerability extension. This prompted me to take a run at describing some real world data using the format. Here's the full example https://gist.github.com/garethr/7dcc9d6ef4e7cc497e018dc279c00123 (bias warning, I work for Snyk, so I used Snyk in the comparison. I don't think any of the following is Snyk specific though, more about the general complexity of the domain and general usage of the output.)

Here are my observations from that experiment. Happy to discuss these here in one long thread or break out elsewhere if easier. Posting partly to discover the best way to discuss and appetite for addressing issues agreed after discussion.

1. No fields are required. This makes the life of consumers harder, should there be a minimum set of fields? (id, description?)
2. The score is always base/impact/exploitability, and always 0-10, so only compatible with CVSS
3. A vulnerability refers to a BOM ref, which I think means if multiple components have the same vulnerability then it needs to be included multiple times rather than via reference?
4. No provision for multiple vulnerability identifiers for the same vulnerability, ie. CVE-2009-5155 is also SNYK-DEBIAN9-GLIBC-338103
5. Although method on ratings can be set to "Other", there is no way of specifying what method/source the information is coming from. So you could have multiple other sources, but no way for the user to trace those back to that source based on data
6. In the case of multiple ratings with the same method, but different scores/vectors, what are the heuristics? Is this valid? Should the spec prohibit this?
7. Additional properties are allowed as per the JSON Schema. Is this purposeful? What is the expected parser behaviour for attributes outside the schema? Should there be a formal extension mechanism?
8. The description is a string. Are there are rules here, ie. SARIF has plain text and markdown properties explicitly, rather than leaving up to the producer
9. Are advisories intended to always be URLs, or can they be arbitrary strings? The schema says the latter, although all the examples are the former. This would impact someone writing a parser.

ie. Should advisories be defined as:

{
    "type": "string",
    "format": "uri",
    "pattern": "^(https?|http?)://"
}

Hopefully the above is useful feedback, rather than being seen as too much criticism. Some might be me being new to the spec and missing things.

I'd be happy to help, and to discuss further if useful.

Add file as component type

This is an enhancement proposal to the CycloneDX specification to add support for file as a type of component.

Currently a component can be one of:

• application
• library
• framework
• hardware
• operating-system

This proposal is to add file as an additional type to account for more granular use-cases.

A common use case would be to define a component (i.e library) and within the library component define child components (already possible) with the type specified as file. In doing so, it would be possible to document all files that a component contains.

Add BOM license information

Tracking implementation of RFC #40

JSON Schema for vulnerability extension?

I see the XML schema has a specific schema extension for describing vulnerability information https://github.com/CycloneDX/specification/blob/master/schema/ext/vulnerability-1.0.xsd

The main page says

The Vulnerability extension provides the ability to represent component vulnerabilities in a BOM. This extension is applicable to CycloneDX v1.1 and higher.

However the ext folder doesn't appear to have the JSON schema https://github.com/CycloneDX/specification/tree/master/schema/ext

Are there any plans to publish a JSON Schema with the vulnerability extension applied?

Expand hardware support

CycloneDX has support for components of type 'device'. However, device-specific fields have been left out of the core specification as they are better suited as a schema extension.

This ticket describes a proposed schema extension that adds proper fields for describing physical devices.

Add BOM Descriptor and Dependency Graph Schema Extensions

RFC: Add pre-defined metadata as key/value pairs

In #36, it was proposed to add an optional extension that would essentially support key/value pairs for pre-defined enums that describe various hardware attributes.

Building upon this idea, there may be some value in making this part of the core (or a general purpose extension) so that other types of use cases could benefit.

<component type="library">
    <name>Acme Component</name>
    <version>1.0.0</version>
    <metadata:build>
        <property key="COMPILER" value="javac"/>
        <property key="COMPILER_VERSION" value="1.8.0"/>
        <property key="COMPILER_VENDOR" value="OpenJDK"/>
        <property key="COMPILER_SHA1_HASH" value="47839749174891......"/>
        <property key="OTHER" name="QC_PERSON" value="Joe"/>
    </metadata:build>
    <metadata:package>
        <property key="PACKAGEMANAGER" value="Maven"/>
        <property key="PACKAGEMANAGER_VERSION" value="3.6.3"/>
    </metadata:package>
</component>

Many of these could be represented in PURL, however, per the PURL spec:

Do not abuse qualifiers: it can be tempting to use many qualifier keys but their usage should be limited to the bare minimum for proper package identification to ensure that a purl stays compact and readable in most cases.

Therefore breaking key/value pairs out into a separate node makes the most sense, and would additionally be applicable to components without a PURL.

Can cycloneDX be generated for unmanaged package dependencies?

Hello. I am a newbie. I wanted to ask that if my software project is not using any dependency manager in its development. for eg. I am creating a java REST service and i manage all my dependencies without any tool like maven or gradle. Then is it possible to have a software bill of materials of it? to generate a cyclonedx bom so that it can be used in dependency track?

Add serialNumber requirement

This is an enhancement proposal to the CycloneDX specification to add a requirement that every BOM have a serialNumber. The serialNumber will be an attribute of the <bom> element and will be expected to be RFC 4122 complaint.

Example:

<bom xmlns="http://cyclonedx.org/schema/bom/1.0" 
     serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79"
     version="1" >

Every BOM generated must have a unique serial number, even if the contents of the BOM being generated have not changed over time. The process or tool responsible for creating the BOM must create random UUID's for every BOM generated.

Add formulation support

Every component and/or pedigree should support how the component was made, not only what the component is or its dna.

For high assurance use cases, it is important to document how software is created, tested, verified, etc.

A possible method may be to support parallel and sequential pipeline and steps within a pipeline. Each step could potentially represent:

• Environment
• Compilers and compiler settings
• Test suites
• Static analysis tools
• Linters
• Fuzzers
• Dynamic analysis tools
• etc, etc, etc

SBOM Specification does not include information for which software the SBOM has been created

The SBOM specification currently defines a format for a Software Bill of Material and lists all components/dependencies of the software. What seems to be not included, is information about "the software itself", meaning information for which software the SBOM has been created.

Is there a specific reason for this or would it be possible extend the specification, so that there is a "section" which explicitly defines "the software itself"?

Thanks and best regards,
Matthias

Add support for component author

Currently, publisher is supported, but the author of a component may be different than the publisher. Add support for author

Add support for protobuf

With a focus on automation and increasing the efficiency of SBOM creation, this proposal is to add support for protobuf to v1.3. I do not envision this being adopted by the official CycloneDX implementations, rather, as a way to provide out of the box support for people building solutions around CycloneDX. The folks at ShiftLeft come to mind as they’ve already done this (using v1.2).

Improve support for defining the copyright holders

CycloneDX v1.2 and prior supports very limited use cases with regard to copyright holders. This should be improved.

Ticket created as a result of CycloneDX/cyclonedx-core-java#58

We need input as to how this should be architected. Are multiple copyright holders applicable to a component, are they only associated with a license, how does this impact pedigree, etc?

We're looking for community involvement.

RFC Inclusion of license information in SBOM metadata

I think we should include in the SBOM metadata information on whether the SBOM is re-distributable, etc.

I think this goal can be achieved by including the existing licenseType as an element in the SBOM metadata.

RFC CycloneDX IANA media type registration

Suggest we register official media types with IANA.

Use cases include API end points that can return SBOMs.

This could either be just to communicate to consumers the format provided. Or allow specifying which SBOM format is desired during the request.

Suggested media types are application/cyclonedx+xml and application/cyclonedx+json.

Although I need to re-read the relevant RFCs for any gotchas/requirements.

Investigate feasibility of supporting dependency graphs

CycloneDX currently supports any kind of component including direct, transitive, runtime, and environmental components.

Representation of components is optionally hierarchical to represent system -> subsystem -> sub-subsystem relations within complex component assemblies. This hierarchy is not a dependency tree. It's a nesting of components.

Dependency trees are not valuable as a source of truth since the stated dependencies usually vary from effective dependencies. This, and other factors lead to variations between what a dependency tree says and the reality of whats included in a final assembly. However, dependency trees are valuable in order to determine how a component was introduced.

SPIKE:
Investigate the feasibility of optionally supporting dependency graphs. The idea is simple, have a unique identifier attribute on every component element and refer to the source component in a graph.

For example:

<bom>
    <components>
        <component uid="urn:uuid:a5a0d9f2-e81d-4953-b6f1-ad56989c3e49">
            ....
        </component>
        <component uid="urn:uuid:9e2a45c9-a8c3-420c-9034-104504a33427">
            ....
        </component>
        <component uid="urn:uuid:2ad11437-20df-4dff-a211-a49dff3ef1ad">
            ....
        </component>
        <component uid="urn:uuid:153a6817-b0b5-477e-8c39-7338e02094fa">
            ....
        </component>
    </components>
    <graph>
        <dependency ref="urn:uuid:a5a0d9f2-e81d-4953-b6f1-ad56989c3e49">
            <dependency ref="urn:uuid:9e2a45c9-a8c3-420c-9034-104504a33427">
                <dependency ref="urn:uuid:2ad11437-20df-4dff-a211-a49dff3ef1ad"/>
            </dependency>
        </dependency>
        <dependency ref="urn:uuid:153a6817-b0b5-477e-8c39-7338e02094fa">
            <dependency ref="urn:uuid:2ad11437-20df-4dff-a211-a49dff3ef1ad"/>
        </dependency>
    </graph>
</bom>

Work will need to be done to investigate the feasibility of implementing this in the specification in a way that it would support both XML Schema and JSON Schema.

Create JSON Schema

JSON Schema is currently at draft-7 with draft-8 expected within the next 30-60 days. CycloneDX 1.1 should attempt to create a json schema based on the most current draft and update the schema until ratified.

CycloneDX implementations should not be made available that can produce json until json schema is ratified

Update IANA media type registrations when v1.3 is released

This is a TODO reminder for after v1.3 is released.

Is 'application' default software component classification? Possible doc update

specification/schema/bom-1.1.xsd

Lines 188 to 194 in aa6dea1

	<xs:attribute name="type" type="bom:classification" use="required">
	<xs:annotation>
	<xs:documentation>
	Specifies the type of component. Software applications, libraries, frameworks, and
	other dependencies should be classified as 'application'.
	</xs:documentation>
	</xs:annotation>

specification/schema/bom-1.1.xsd

Lines 307 to 316 in aa6dea1

	<xs:simpleType name="classification">
	<xs:restriction base="xs:string">
	<xs:enumeration value="application"/>
	<xs:enumeration value="framework"/>
	<xs:enumeration value="library"/>
	<xs:enumeration value="operating-system"/>
	<xs:enumeration value="device"/>
	<xs:enumeration value="file"/>
	</xs:restriction>
	</xs:simpleType>

I wonder if the documentation string should instead be something like

Specifies the type of component. If a software component cannot be classified as an application, file, framework, or operating system, the component should be classified as an application.

or

Specifies the type of component. For software components, classify as application if no more specific appropriate classification is available or cannot be determined for the component.

RFC: known unknowns

Some possible scenarios:

• I have component x, but I have no idea what's in it
• I have component x, I know it has y and z in it, but that isn't complete

Feel free to add more

SPDX license list revved

Whether you implement #1 (and address license expression syntax) or not, you will probably want to figure out how to track updates to the SPDX license list and associated identifiers. SPDX recently released version 3.0 of the license list, and 3.1 is in the works for the end of this month.

Support optional per-component suppliers

Add attached text type for components and BOM level metadata

RFC #46

Add bom level component properties

I think it would be good to add some component properties at the bom level.

For example, including the purl of the package that the sbom describes.

Add audit schema extension

The ability to optionally supplement the BOM with results of human analysis and opinion is required for moderate to high assurance use cases.

Examples include:

• Analysis of the accuracy of each components data as well as the accuracy of the BOM in its entirety.
• Analysis of the completeness of each components data as well as the completeness of the BOM in its entirety.
• Analysis and determination of the completeness and accuracy of each components inclusions, dependencies, provenance and pedigree. Assertions, known unknowns, etc.
• Analysis of the tools and methods used to create the BOM.

Each analysis should attribute decisions to the people, processes, or machines that made them, timestamps, and signatures, forming an audit trail.

Add external references support

This is an enhancement proposal to the CycloneDX specification to support external references.

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.1" version="1">
    <components>
        <component type="application">
            <group>org.apache.tomcat</group>
            <name>tomcat-catalina</name>
            <version>9.0.14</version>
            <licenses>
                <license>
                    <id>Apache-2.0</id>
                </license>
            </licenses>
            <purl>pkg:maven/org.apache.tomcat/[email protected]?packaging=jar</purl>
            <modified>false</modified>
            <externalReferences>
                <reference type="vcs">
                    <url>https://github.com/apache/tomcat.git</url>
                    <comment>Repo containing all Tomcat components</comment>
                </reference>
                <reference type="issue-tracker">
                    <url>https://bz.apache.org/bugzilla/</url>
                </reference>
                <reference type="website">
                    <url>http://tomcat.apache.org/</url>
                </reference>
                <reference type="spdx">
                    <url>http://location/to/spdx.rdf</url>
                </reference>
            </externalReferences>
        </component>
    </components>
</bom>

I envision several built-in types including:

• vcs (Version Control System)
• issue-tracker
• website
• advisories
• spdx
• mailing-list
• social
• chat (IRC, Slack, MS Teams, etc)
• docs
• support
• download
• license (the URL containing the full text of the license - necessary for non-standard types)
• other (a catch-all)

Some of these can be automatically obtained from a combonents NuGet or pom.xml for example and can aid in various types of manual assessment as well as future automated assessment. Future types can possibly include:

• Consumption of per-project vulnerability intelligence (via advisories)
• Project health analysis (via issue-tracker and vcs)
• Consumption of externally defined BOMs (via SPDX)

Finalize BOM Descriptor Schema Extension

Background

The BOM Descriptor extension is intended to provide additional metadata about the asset/software it describes. The schema is currently at 1.0-SNAPSHOT and sources and docs are here:

• https://github.com/CycloneDX/specification/blob/master/schema/ext/bom-descriptor-1.0.xsd
• https://cyclonedx.org/ext/bom-descriptor/ (v0.9 only)

Community Feedback Requested

[Dependency Graph] How to identify direct / indirect dependencies

With the current dependency graph specification, it seems to be not possible to exactly distinguish between direct and indirect dependencies.

Example:
Given the following dependency graph (taken from https://cyclonedx.org/ext/dependency-graph/):

    <dg:dependencies>
        <dg:dependency ref="pkg:maven/org.example.acme/[email protected]">
            <dg:dependency ref="pkg:maven/org.example.acme/[email protected]"/>
        </dg:dependency>
        <dg:dependency ref="pkg:maven/org.example.acme/[email protected]">
            <dg:dependency ref="pkg:maven/org.example.acme/[email protected]"/>
        </dg:dependency>
        <dg:dependency ref="pkg:maven/org.example.acme/[email protected]"/>
    </dg:dependencies>

Analyzing/interpreting the dependency graph, we can clearly identify the following:
Direct dependencies

• pkg:maven/org.example.acme/[email protected]
• pkg:maven/org.example.acme/[email protected]

Indirect dependencies

• pkg:maven/org.example.acme/[email protected]

But we can actually not conclude is if pkg:maven/org.example.acme/[email protected] is a direct dependecy as well

Is this a known issue or done on purpose? And if so, why?
If not, is it possible to include this into the specification to resolve this issue?

Thanks and best regards,
Matthias

RFC: attached text type for components and BOM level metadata

This could allow scenarios like embedding an SPDX SBOM in a CycloneDX SBOM. Especially for situations in which a CycloneDX SBOM has been generated from an SPDX SBOM.

There are also some differences in the SPDX and CycloneDX approaches. CycloneDX takes a facts based approach in the core spec, but SPDX supports some analysis scenarios. i.e. concluded license. This might enable adopters to take advantage of both formats?

It would also allow the inclusion of component supplier level SBOMs to be embedded within the assembled software SBOM.

And scenarios where an auditor is authoring an SBOM, and attaching the supplier provided SBOM for comparison.