Skip to content

Commit 0d768e1

Browse files
stevespringettstevespringett
committed
Content update
1 parent 755c1ff commit 0d768e1

File tree

3 files changed

+45
-45
lines changed

3 files changed

+45
-45
lines changed

‎CBOM/en/0x30-Anatomy-of-a-CBOM.md

+35-35
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,8 @@
11
# Anatomy of a CBOM
22
The Cryptography Bill of Materials (CBOM) presents a structured approach to inventory management of cryptographic assets,
3-
leveraging the CycloneDX component model to represent a diverse array of cryptographic assets comprehensively.
4-
CBOM is implemented within the CycloneDX object model, which facilitates the standardized representation of
5-
cryptographic assets, including algorithms, keys, protocols, and certificates. The CycloneDX component model provides a
3+
leveraging the CycloneDX component model to comprehensively represent a diverse array of cryptographic assets.
4+
CBOM is implemented within the CycloneDX object model, facilitating the standardized representation of
5+
cryptographic assets, including algorithms, keys, protocols, and certificates. The CycloneDX object model provides a
66
flexible and extensible framework that accommodates the complexity and diversity of cryptographic infrastructure.
77

88
## Structure and Cryptographic Asset Types
@@ -16,30 +16,30 @@ flexible and extensible framework that accommodates the complexity and diversity
1616
CycloneDX can represent the following types of cryptographic assets:
1717

1818

19-
| Type | Description |
20-
| ---- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
21-
| algorithm | Cryptographic function commonly used for data encryption, authentication, and digital signatures or other primitives. |
22-
| certificate | An electronic document that is used to provide the identity or validate a public key. |
23-
| protocol | A set of rules and guidelines that govern the behavior and communication with each other. |
24-
| private-key | The confidential key of a key pair used in asymmetric cryptography. |
25-
| public-key | The non-confidential key of a key pair used in asymmetric cryptography. |
26-
| secret-key | A key used to encrypt and decrypt messages in symmetric cryptography. |
27-
| key | A piece of information, usually an octet string, which, when processed through a cryptographic algorithm, process cryptographic data. |
28-
| ciphertext | The result of encryption performed on plaintext using an algorithm (or cipher). |
29-
| signature | A cryptographic value that is calculated from the data and a key known only by the signer. |
30-
| digest | The output of the hash function. |
31-
| initialization-vector | A fixed-size random or pseudo-random value used as an input parameter for cryptographic algorithms. |
32-
| nonce | A random or pseudo-random number that can only be used once in a cryptographic communication. |
33-
| seed | The input to a pseudorandom number generator. Different seeds generate different pseudorandom sequences. |
34-
| salt | A non-secret value used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker. |
35-
| shared-secret | A piece of data, known only to the parties involved, in a secure communication. |
19+
| Type | Description |
20+
| ---- |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
21+
| algorithm | Cryptographic function commonly used for data encryption, authentication, and digital signatures or other primitives. |
22+
| certificate | An electronic document that provides the identity or validates a public key. |
23+
| protocol | A set of rules and guidelines that govern the behavior and communication with each other. |
24+
| private-key | The confidential key of a key pair used in asymmetric cryptography. |
25+
| public-key | The non-confidential key of a key pair used in asymmetric cryptography. |
26+
| secret-key | A key used to encrypt and decrypt messages in symmetric cryptography. |
27+
| key | A piece of information, usually an octet string, which, when processed through a cryptographic algorithm, processes cryptographic data. |
28+
| ciphertext | The result of encryption performed on plaintext using an algorithm (or cipher). |
29+
| signature | A cryptographic value that is calculated from the data and a key known only by the signer. |
30+
| digest | The output of the hash function. |
31+
| initialization-vector | A fixed-size random or pseudo-random value used as an input parameter for cryptographic algorithms. |
32+
| nonce | A random or pseudo-random number that can only be used once in a cryptographic communication. |
33+
| seed | The input to a pseudo-random number generator. Different seeds generate different pseudo-random sequences. |
34+
| salt | A value used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker. |
35+
| shared-secret | A piece of data known only to the parties involved, in a secure communication. |
3636
| tag | A message authentication code (MAC), sometimes known as an authentication tag, is a short piece of information used for authenticating and integrity-checking a message. |
37-
| additional-data | An unspecified collection of data with relevance to cryptographic activity. |
38-
| password | A secret word, phrase, or sequence of characters used during authentication or authorization. |
39-
| credential | Establishes the identity of a party to communication, usually in the form of cryptographic keys or passwords. |
40-
| token | An object encapsulating a security identity. |
41-
| other | Another type of cryptographic asset. |
42-
| unknown | The type of cryptographic asset is not known. |
37+
| additional-data | An unspecified collection of data with relevance to cryptographic activity. |
38+
| password | A secret word, phrase, or sequence of characters used during authentication or authorization. |
39+
| credential | Establishes the identity of a party to communication, usually in the form of cryptographic keys or passwords. |
40+
| token | An object encapsulating a security identity. |
41+
| other | Another type of cryptographic asset. |
42+
| unknown | The type of cryptographic asset is not known. |
4343

4444
<div style="page-break-after: always; visibility: hidden">
4545
\newpage
@@ -78,8 +78,8 @@ CycloneDX fully supports key states as detailed in the example below:
7878
## Intersection of Key Management States and Lifecycle Phases
7979
As outlined in the [CycloneDX Authoritative Guide to SBOM](https://cyclonedx.org/guides/), CycloneDX supports lifecycles
8080
that encompass those in the Software Development Life Cycle (SDLC) and those commonly used in Software Asset Management
81-
(SAM). CycloneDX lifecycle phases can be used together with the key management states defined by NIST to help in
82-
identifying and preventing risks associated with compromised keys and operational anomalies.
81+
(SAM). CycloneDX lifecycle phases can be used together with the key management states defined by NIST to help identify
82+
and prevent risks associated with compromised keys and operational anomalies.
8383

8484
CycloneDX defines the following phases:
8585

@@ -108,7 +108,7 @@ cryptographic assets and can identify potential risks more effectively.
108108
</div>
109109

110110
### Manage Keys From Inception
111-
In the CycloneDX lifecycle, the "Design" and "Pre-build" phases corresponds to the pre-activation state in key
111+
In the CycloneDX lifecycle, the "Design" and "Pre-build" phases correspond to the pre-activation state in key
112112
management. During development, cryptographic keys are generated but not yet put into active use. By linking
113113
pre-activation with these phases, organizations can ensure that cryptographic keys are securely managed from their
114114
inception, minimizing the risk of unauthorized access or compromise before deployment.
@@ -139,19 +139,19 @@ Any deviances from expected lifecycle mappings to key management states should b
139139
![Lifecycles](../../images/Lifecycles.svg)
140140

141141
### Prevention of Compromised Keys During Build or Deployment
142-
The compromised key management state, plays a crucial role in preventing software supply chain attacks when integrated
142+
The compromised key management state is crucial in preventing software supply chain attacks when integrated
143143
into the "Build" lifecycle phase in CycloneDX. During the build phase, cryptographic keys are utilized to sign software
144144
artifacts, ensuring their authenticity and integrity. By leveraging the "compromised" state within CycloneDX,
145-
organizations can detect compromised keys promptly and prevent their unauthorized usage during the build process.
145+
organizations can detect compromised keys promptly and prevent unauthorized usage during the build process.
146146
For instance, if a key used for code signing is compromised, CycloneDX metadata can flag the key as compromised,
147147
triggering automated processes to revoke its access privileges and prevent its use in signing software artifacts.
148148
This proactive approach mitigates the risk of adversaries leveraging compromised keys to inject malicious code into the
149149
software supply chain, enhancing the security and trustworthiness of software builds distributed to software consumers.
150150

151-
By leveraging key management states within the context of the CycloneDX lifecycle phases, organizations can enhance
152-
their risk management practices, proactively identify security vulnerabilities, and maintain the integrity of
153-
cryptographic operations throughout the software development lifecycle. This integrated approach enables organizations
154-
to effectively safeguard sensitive data and mitigate potential risks associated with cryptographic assets.
151+
By leveraging key management states within the CycloneDX lifecycle phases, organizations can enhance their risk
152+
management practices, proactively identify security vulnerabilities, and maintain the integrity of cryptographic
153+
operations throughout the software development lifecycle. This integrated approach enables organizations to safeguard
154+
sensitive data and mitigate potential risks associated with cryptographic assets.
155155

156156

157157
<div style="page-break-after: always; visibility: hidden">

‎CBOM/en/0x40-Practical-Examples.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -3,12 +3,12 @@ Examples of assets typically cataloged within a CBOM include algorithms, keys, p
33
associated metadata crucial for effective management and security. Algorithms refer to the mathematical functions
44
utilized for encryption, hashing, and digital signatures, while keys encompass cryptographic keys used for encryption,
55
decryption, and authentication. Protocols delineate the rules and procedures governing secure communication between
6-
entities and certificates authenticate the identities of entities within a cryptographic system. Associated CBOM metadata
6+
entities, and certificates authenticate the identities of entities within a cryptographic system. Associated CBOM metadata
77
includes details such as algorithm versions, key lengths, protocol configurations, and certificate attributes, providing
88
comprehensive insights necessary for the management and security of cryptographic assets.
99

1010
## Algorithm
11-
A cryptographic algorithm is added in the components array of the BOM. The examples below lists the algorithm
11+
A cryptographic algorithm is added in the components array of the BOM. The examples below list the algorithm
1212
AES-128-GCM and SHA512withRSA.
1313

1414
```json

0 commit comments

Comments
 (0)