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 CyloneDX 1.6 to guide building and consuming CBOM.
IBM research in CBOM extended CycloneDX version 1.4 to include:
- Component:
crypto-asset - Properties:
cryptoProperties - Dependencies:
dependencyType
CycloneDX 1.6 achieves the same by
- adding a
cryptographic-assetto the supported component types - adding a
providesto itsdependenciesnode to support identifying a cryptographic value (functionality, files) provided by a component - adding
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 material algorithmProperties— If the asset type is analgorithm, this describes algorithm properties such as primitive, curve, padding, environment, and security level (classical and nistQuantum) associated with the algorithm.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 be used to specify the specific type (‘tls’, ‘ipsec’), version, cipher suites in use, and ikev2 transformation types.relatedCryptoMaterialProperties— If the asset type isrelated-crypto-material, this describes additional details such as the asset's size, format, value, creation, update, and activation-specific dates.
The Authoritative Guide to CBOM includes some examples, including the following one for describing “AES-128-GCM”
"components": [
{
"type": "cryptographic-asset",
"name": "AES-128-GCM",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "ae",
"parameterSetIdentifier": "128",
"mode": "gcm",
"executionEnvironment": "software-plain-ram",
"implementationPlatform": "x86_64",
"certificationLevel": [ "none" ],
"cryptoFunctions": [ "keygen", "encrypt", "decrypt", "tag" ],
"classicalSecurityLevel": 128,
"nistQuantumSecurityLevel": 1
},
"oid": "2.16.840.1.101.3.4.1.6"
}
}
The CBOM addition references and thanks to 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 CyloneDX 1.6 to guide the 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 details anddeclarationsnode to capture associated claims, evidence, signatures, and metadata.
Definitions
The definitions is a node for describing the standard in detail and supports standard versioning and level of compliance to capture long-running standards with maturity levels.
CDXA comes baked 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).
However, CDXA can create a custom standard with attestation requirements.
For example, SSDF requirements are broken down as
"definitions": {
"standards": [
{
"bom-ref": "ssdf-1.1",
"name": "Secure Software Development Framework (SSDF) Version 1.1",
"description": "NIST Special Publication 800-218",
"version": "1.1",
"owner": "National Institute of Standards and Technology",
"requirements": [
{
"bom-ref": "ssdf-1.1-PO",
"identifier": "PO",
"text": "Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.",
"externalReferences": [
{
"type": "documentation",
"url": "https://csrc.nist.gov/csrc/media/Publications/sp/800-218/final/documents/NIST.SP.800-218.SSDF-table.xlsx#Groups!A1"
}
]
},
{
"bom-ref": "ssdf-1.1-PO.1",
"identifier": "PO.1",
"text": "Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of effort can be minimized because the requirements information can be collected once and shared. This includes requirements from internal sources (e.g., the organization’s policies, business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).",
"parent": "ssdf-1.1-PO",
"externalReferences": [
{
"type": "documentation",
"url": "https://csrc.nist.gov/csrc/media/Publications/sp/800-218/final/documents/NIST.SP.800-218.SSDF-table.xlsx#SSDF!A2"
}
]
},
.....
Declarations
The declarations node is an 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.
OWASP Authoritative Guide to Attestations includes some examples of how to attest claims:
"claims": [
{
"bom-ref": "claim-1",
"target": "acme-inc",
"predicate": "Developers have taken the HackMe Secure Coding for Java training course and received a passing
grade on the final test.",
"mitigationStrategies": [ "mitigationStrategy-1" ],
"reasoning": "The provided evidence shows that 70% of developers have been trained this year.",
"evidence": [ "evidence-1" ],
"counterEvidence": [ "counterEvidence-1" ],
"signature": {
"algorithm": "ES256",
"certificatePath": [ "MIIB...", "MIID..." ],
"value": "tqIT..."
}
}
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.
