Skip to content

Commit 9fc2585

Browse files
Content updates
1 parent 51c7c3c commit 9fc2585

6 files changed

+66
-78
lines changed

CBOM/en/0x01-Frontispiece.md

+2
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,8 @@ supply chain security field. This guide would not be possible without valuable f
1111
Working Group (IWG), the CycloneDX Core Working Group (CWG), the many CycloneDX Feature Working Groups (FWG),
1212
CycloneDX maintainers and a global network of contributors and supporters.
1313

14+
Portions of this guide were contributed by IBM under the Apache License Version 2.0.
15+
1416
## Copyright and License
1517

1618
![license](../../images/license.svg)

CBOM/en/0x02-Preface.md

-2
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,6 @@
22

33
Secure supply chains are the foundational building block of modern cyber security. Without being able to describe a system’s components in a machine-consumable way, organizations and software consumers are in the dark if they are at risk of exploitation of known defects or vulnerabilities.
44

5-
Innovation drives the evolution of Software Bill of Materials (SBOM). I was lucky enough to attend one of the meetings held between the CycloneDX and SPDX teams at a Linux Foundation conference moderated by the fine folks at CISA. The drivers for CycloneDX 1.5 include improvements in interoperability and transparency.
6-
75
Software authors, from hobbyists to software vendors, can quickly adopt CycloneDX in their tooling, producing artifacts that will help consumers understand and manage the risk of the multitude of software that most organizations rely on daily.
86

97
A few years ago, I was involved in a project to review 1700 business-critical applications in 90 days for known software vulnerabilities. If the organization had access to CycloneDX SBOMs, this would have been a trivial task, time that could have been more usefully spent on remediation rather than discovery. Sadly, most of the time was spent working out what software had old faulty components rather than addressing the very real risk of known software vulnerabilities. We were plagued with false positives from the tooling we used simply because scanning software without SBOMs is a heuristic-driven discovery process that is inefficient and wastes a great deal of time we didn’t have. SBOMs resolve these issues, reduce costs, and reduce risk to all involved.

CBOM/en/0x10-Introduction.md

+21-53
Original file line numberDiff line numberDiff line change
@@ -1,65 +1,33 @@
11
# Introduction
22

3-
CBOM:
4-
NIST:
5-
SP: https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38b-preliminary-draft.pdf
6-
Lines 536 and 952 onwards
7-
as part of NCCOE effort
8-
Apache 2.0 - attribute IBM
3+
A Cryptography Bill of Materials (CBOM) is an object model to describe cryptographic assets and their dependencies.
4+
Support for CBOM is included in CycloneDX v1.6 and higher. Discovering, managing, and reporting on cryptographic assets
5+
is necessary as the first step on the migration journey to quantum-safe systems and applications. Cryptography is
6+
typically buried deep within components that are used to compose and build systems and applications. It makes sense to
7+
minimize this effort through alignment and reuse of concepts and components used to implement the Software Supply Chain
8+
Security (SSCS).
99

10+
## CBOM Design
11+
The overall design goal of CBOM is to provide an abstraction that allows modeling and representing crypto assets in a
12+
structured object format. This comprises the following points.
1013

14+
1. Modelling cryptographic assets
15+
Cryptographic assets occur in several forms. Algorithms and protocols are most commonly implemented in specialized cryptographic libraries. They may, however, also be 'hardcoded' in software components. Certificates and related cryptographic material like keys, tokens, secrets, or passwords are other cryptographic assets to be modeled.
1116

17+
2. Capturing cryptographic asset properties
18+
Cryptographic assets have properties that uniquely define them and that make them actionable for further reasoning. For example, it makes a difference if one knows the algorithm family (e.g. AES) or the specific variant or instantiation (e.g. AES-128-GCM). This is because the security level and the algorithm primitive (authenticated encryption) are only defined by the definition of the algorithm variant. The presence of a weak cryptographic algorithm like SHA1 vs. HMAC-SHA1 also makes a difference. Therefore, the goal of CBOM is to capture relevant cryptographic asset properties.
1219

20+
3. Capturing crypto asset dependencies
21+
To understand the impact of a cryptographic asset, it is important to capture its dependencies. Cryptographic libraries 'implement' certain algorithms and protocols, but their implementation alone does not reflect their usage by applications. CBOM, therefore, differentiates between 'implements' and 'uses' dependencies. It is possible to model algorithms or protocols that use other algorithms (e.g., TLS 1.3 uses ECDH/secp256r1), libraries that implement algorithms, and applications that 'use' algorithms from a library.
1322

14-
CycloneDX Attestations is a modern standard for security compliance. CycloneDX Attestations enable organizations with a machine-readable format for communication about security standards, claims and evidence about security requirements, and attestations to the veracity and completeness of those claims. You can think of Attestations as a way to manage "compliance as code." The Attestations project began in 2023 as part of the broader CycloneDX project.
23+
4. Applicability to various software components
24+
CycloneDX supports various components such as applications, frameworks, libraries, containers, operating systems, devices, firmware, and files. CBOM extends this model and can communicate a component's dependency on cryptographic assets.
1525

16-
CycloneDX Attestations is a part of the OWASP CycloneDX project. CycloneDX is an OWASP flagship project, has a formal standardization process and governance model, and is supported by the global information security community.
26+
5. High compatibility to CycloneDX SBOM and related tooling
27+
CBOM is native to the CycloneDX standard. It integrates cryptographic assets as an additional component type in the CycloneDX schema and further extends dependencies with the ability to specify dependency usage and implementation details. CBOM data can be present in existing SBOMs or externalized into dedicated CBOMs, thus creating modularity, which may optionally have varying authentication and authorization requirements.
1728

18-
## Intended Audience
19-
CycloneDX Attestations is intended for use by:
20-
* Software development teams that want to meet security requirements and automate security evidence generation and communication
21-
* Security teams that want to ensure the security and compliance of software projects being created, and manage the compliance process with assessors.
22-
* Executives who are required to attest to their compliance with security standards.
23-
* Security assessors that want to have a standard way of processing compliance documentation and tracking compliance.
24-
* Security tool providers that build software for managing compliance processes.
25-
* Security standard creators that want to create a machine-readable version of their requirements.
26-
27-
## Problem Statement
28-
Currently, organizations use a variety of paper-based and non-standard electronic documents to communicate about security requirements, evidence, and attestation. The labor required to create, process, manage, update, and track these documents is expensive, labor-intensive, and often overwhelming. Not surprisingly, the results are generally underwhelming. There are often large gaps between what the original requirement envisioned and the argument presented by the software producer. Similarly, assessors often misinterpret requirements and focus on minutae instead of the intent of the original requirement.
29-
30-
The problem is so bad there are endless [articles](https://www.google.com/search?q=compliance+is+not+security) explaining why compliance is not the same as security. This is unfortunate. If the security requirements really represented the shared security interests of all stakeholders, then security and compliance would be aligned. Unfortunately, in most cases, at least some of the requirements make no sense to apply to the product, and many critical aspects of security are not reflected in the requirements.
31-
32-
The root cause of these issues is a fundamental communications problem. Security requirements don't often match up well with the expected threats for a particular real-world system and its defenses. Further, security requirements are often far too abstract for development organizations to clearly understand what they must do with their particular organization, processes, and technologies. The assessors that should be facilitating the interpretation of the requirements in the context of the actual system are often relegated to strict interpretation of the words in vague, high-level requirements.
33-
34-
Our challenge is to encourage standards bodies, builders, and assessors to communicate effectively. All the parties need a way to ensure that the *intent* of each requirement is applied appropriately to a particular product or system and achieved with confidence.
35-
36-
## How CycloneDX Attestations Addresses Challenge
37-
Of course, CycloneDX Attestations can't solve this problem entirely. However, by allowing all parties to communicate in a standard machine-readable format, we hope to encourage more productive interaction and far less paperwork.
38-
39-
We believe:
40-
41-
* The use of machine-readable standards in Attestations format will encourage faster and deeper understanding by all parties.
42-
* The Attestations claims and evidence approach will allow development organizations to articulate their compliance rationale quickly and clearly
43-
* The use of Attestations will enable all forms of assessors, certifiers, and accreditors to more quickly evaluate compliance and provide feedback to producers
44-
* Attestations will enable faster compliance feedback loops and less surprises and delays
45-
46-
## Intended Use Cases
47-
// TODO
48-
// * Supplier to consumer use case where the consumer requires adherence to something (e.g. SSDF)
49-
// * Internal use case where an internal policy is created from requirements defined in CDXA
50-
// * Regulatory and industry compliance requirements
51-
52-
## Tool Support
53-
54-
Over time, we expect better tools for managing all aspects of security attestation to emerge. As a producer, imagine being able to select appropriate standards for a project, eliminate duplication, articulate compliance rationales, automatically generate and include supporting evidence, manage reviews, and digitally sign attestations. From the assessor point of view, imagine being able to quickly evaluate claims and evidence, easily identify changes, point out gaps, and digitally sign approvals.
55-
56-
## Join Us
57-
58-
If you are interested in using CycloneDX Attestations or want to help us realize our vision, please join us!
59-
60-
https://www.youtube.com/@CycloneDX
61-
https://owasp.org/www-project-cyclonedx/
62-
https://cyclonedx.org/about/participate/
29+
6. Enable automatic reasoning
30+
CBOM enables tooling to reason about cryptographic assets and their dependencies automatically. This allows checking for compliance with policies that apply to cryptographic use and implementation.
6331

6432
<div style="page-break-after: always; visibility: hidden">
6533
\newpage

CBOM/en/0x20-Use-Cases.md

+35-1
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,41 @@
11
# Use Cases
22

3-
TODO
3+
## Cryptography Asset Management
4+
The Cryptography Bill of Materials (CBOM) is a comprehensive inventory of cryptographic assets, encompassing keys,
5+
certificates, tokens, and more. CBOM provides a structured framework for organizations to catalog and track their
6+
cryptographic resources, facilitating efficient management and ensuring security and compliance standards are met.
7+
By maintaining a detailed record of cryptographic assets, including their usage, expiration dates, and associated
8+
metadata, CBOM enables proactive monitoring and streamlined auditing processes. With CBOM, organizations can effectively
9+
safeguard their cryptographic infrastructure, mitigate risks associated with unauthorized access or misuse, and maintain
10+
the integrity and confidentiality of sensitive data across diverse digital environments.
411

12+
## Identifying Weak Algorithms
13+
CBOM enables organizations to conduct thorough assessments and discover weak algorithms or flawed implementations that
14+
could compromise security. Through analysis of CBOM data, including cryptographic algorithms, key management practices,
15+
and usage patterns, organizations can pinpoint areas of concern and prioritize remediation efforts. CBOM facilitates
16+
proactive identification of weaknesses and vulnerabilities, allowing organizations to enhance the resilience of their
17+
cryptographic infrastructure and mitigate the risk of exploitation, thereby bolstering overall cybersecurity posture and
18+
safeguarding sensitive data against potential threats.
19+
20+
## Post-Quantum Cryptography (PQC) Readiness
21+
CBOM is crucial in preparing applications and systems for an impending post-quantum reality, aligning with
22+
guidance from the National Security Agency (NSA) and the National Institute of Standards and Technology (NIST). As
23+
quantum computing advancements threaten the security of current cryptographic standards, CBOM provides a structured
24+
approach to inventorying cryptographic assets and evaluating their resilience against quantum threats. By cataloging
25+
cryptographic algorithms and their respective parameters, CBOM enables organizations to identify vulnerable or weak
26+
components that require mitigation or replacement with quantum-resistant alternatives recommended by NSA and NIST.
27+
Through comprehensive analysis and strategic planning facilitated by CBOM, organizations can proactively transition to
28+
post-quantum cryptographic primitives, ensuring the long-term security and integrity of their systems and applications
29+
in the face of evolving technological landscapes.
30+
31+
## Cryptographic Requirements and Certifications
32+
CBOM facilitates the assessment of whether cryptographic implementations meet the stringent criteria outlined by
33+
FIPS 140-2, FIPS 140-3, and Common Criteria. This includes ensuring the proper selection and configuration of
34+
cryptographic algorithms and protocols to align with certification requirements. CBOM enables organizations to streamline
35+
the certification process by providing clear documentation of cryptographic practices and facilitating communication
36+
between stakeholders, auditors, and certification bodies, ultimately accelerating the attainment of compliance and
37+
bolstering confidence in the security of cryptographic systems. Suppliers whose products include cryptographic assets
38+
are encouraged to communicate certifications that have been obtained.
539

640
<div style="page-break-after: always; visibility: hidden">
741
\newpage

CBOM/en/0x30-Practical-Examples.md

+8
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
# Practical Examples
2+
TODO
3+
4+
5+
6+
<div style="page-break-after: always; visibility: hidden">
7+
\newpage
8+
</div>

CBOM/en/0x30-Practicle-Examples.md

-22
This file was deleted.

0 commit comments

Comments
 (0)