All about CycloneDX 1.6
May 1, 2024
Engineering
SBOM is the foundation of software transparency and cyber resilience.
CycloneDX is one of the three SBOM specifications recommended by NTIA/CISA and one of the most popular SBOM specifications.
The OWASP Foundation released CycloneDX version 1.6 earlier this month.
In addition to several improvements, version 1.6 adds the capability to build a Cryptographic Bill of Materials (CBOM) and specify CycloneDX attestations (CDXA).
Let’s dig in.
Post-Quantum Cryptography (PQC)
As quantum computing advances, it will eventually be able to break all legacy cryptography used for digital signatures and encryption. CISA runs a Post-Quantum Cryptography (PQC) Initiative to prepare Federal agencies and private industries for that quantum leap. One of the early recommendations is to start building a cryptographic inventory of assets used.
This is where CycloneDX 1.6 comes in.
Cryptographic Bill of Materials (CBOM)
The CBOM is an expansion of SBOM that includes cryptographic properties. OWASP published an Authoritative Guide to CBOM along with the release of CycloneDX 1.6 to guide building and consuming CBOM.
IBM research in CBOM extended CycloneDX version 1.4 to include:
Component:
crypto-assetProperties:
cryptoPropertiesDependencies:
dependencyType
CycloneDX 1.6 achieves the same by:
adding a
cryptographic-assetto the supported component typesadding a
providesto itsdependenciesnode to support identifying a cryptographic value (functionality, files) provided by a componentadding
cryptoPropertiesto thecomponentsnode to capture details of the cryptographic assets
cryptoProperties plays a key role in being able to document a wide variety of cryptographic assets and associated metadata, such as:
assetType— the type of asset being described: algorithm, certificate, protocol, or related materialalgorithmProperties— If the asset type is analgorithm, this describes algorithm properties such as primitive, curve, padding, environment, and security level (classical and nistQuantum)certificateProperties— If the asset type is thecertificate, this describes certificate properties such as name, issuer, validity window, format, and signature detailsprotocolProperties— If the asset type is theprotocol, this can specify the specific type (‘tls’, ‘ipsec’), version, cipher suites in use, and ikev2 transformation typesrelatedCryptoMaterialProperties— If the asset type isrelated-crypto-material, this describes additional details such as size, format, value, creation, update, and activation dates
The Authoritative Guide to CBOM includes examples, including one for describing “AES-128-GCM”.
The CBOM addition references and thanks IBM’s research on CBOM, and therefore, any implementation should use both the specification and IBM research for background information.
CycloneDX Attestations (CDXA)
CycloneDX 1.6 adds attestation and describes this as “compliance as code.” OWASP also published an Authoritative Guide to Attestations along with the release of CycloneDX 1.6 to guide building and consumption of CDXA.
In addition, OWASP has published an Authoritative Guide to Attestations.
CDXA aims to use attestations to meet security requirements, automate evidence generation, communicate with assessors, and act as a standard for machine-readable versions of their requirements.
Compliance as Code
In the CDXA approach, standard compliance is broken down into:
Defining standard requirements
Making claims against those requirements
Capturing evidence to support those claims
Signing the attestation that lists all of the above
Attestations are a set of claims, counterclaims, and associated evidence.
In CDXA, the claims, counterclaims, evidence, and related metadata are all documented inside the SBOM and cryptographically signed by the attesting party.
To achieve that, CycloneDX 1.6 adds:
definitionsnode to specify a standard and its detailsdeclarationsnode to capture associated claims, evidence, signatures, and metadata
Definitions
The definitions node is for describing the standard in detail and supports standard versioning and levels of compliance.
CDXA comes with attestation schemas for common security standards:
NIST Secure Software Development Framework (SSDF)
PCI Secure Software Life Cycle (PCI-SLC)
Build Security in Maturity Model (BSIMM)
OWASP Application Security Verification Standard (ASVS)
OWASP Mobile Application Security Verification Standard (MASVS)
OWASP Software Component Verification Standard (SCVS)
It can also create a custom standard with attestation requirements.
SSDF requirements, for example, are broken down in the CycloneDX repository.
Declarations
The declarations node is the actual recording of claims related to SBOM content and standard requirements.
CDXA supports recording the assessor party list of signed claims, including reasoning, evidence, counterevidence, and mitigation strategies.
The OWASP Authoritative Guide to Attestations includes examples of how to attest claims.
CDXA takes a big leap toward automatic evidence generation for many requirements but will need additional tooling to capture specific details.
Example: SSDF PW2.1: “Have a qualified person (or people) who were not involved with the design.”
CycloneDX continues to progress towards improving coverage of the SBOM and interpreting and using the data more effectively.
CBOM and CDXA will greatly boost post-Quantum Cryptography risk management and the “compliance as a code” movement.