diff --git a/CBOM/en/0x01-Frontispiece.md b/CBOM/en/0x01-Frontispiece.md index 304b55f..aaacad1 100644 --- a/CBOM/en/0x01-Frontispiece.md +++ b/CBOM/en/0x01-Frontispiece.md @@ -28,9 +28,9 @@ Version 1.0.0, xx February 2024 \emptyparagraph -| Version | Changes | Updated On | Updated By | -|---------|-----------------|------------|------------------------------| -| 0.0.0 | Initial Release | 2024-xx-xx | CycloneDX Core Working Group | +| Version | Changes | Updated On | Updated By | +|---------------|-----------------|------------|-------------------------------------------------| +| First Edition | Initial Release | 2024-xx-xx | CycloneDX Feature Working Group on Cryptography |
\newpage diff --git a/CBOM/en/0x30-Anatomy-of-a-CBOM.md b/CBOM/en/0x30-Anatomy-of-a-CBOM.md new file mode 100644 index 0000000..73df292 --- /dev/null +++ b/CBOM/en/0x30-Anatomy-of-a-CBOM.md @@ -0,0 +1,159 @@ +# Anatomy of a CBOM +The Cryptography Bill of Materials (CBOM) presents a structured approach to inventory management of cryptographic assets, +leveraging the CycloneDX component model to represent a diverse array of cryptographic assets comprehensively. +CBOM is implemented within the CycloneDX object model, which facilitates the standardized representation of +cryptographic assets, including algorithms, keys, protocols, and certificates. The CycloneDX component model provides a +flexible and extensible framework that accommodates the complexity and diversity of cryptographic infrastructure. + +## Structure and Cryptographic Asset Types + +![CBOM Component Architecture](./images/CBOM-Component-Architecture.svg) + +
+\emptyparagraph +
+ +CycloneDX can represent the following types of cryptographic assets: + + +| Type | Description | +| ---- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| algorithm | Mathematical function commonly used for data encryption, authentication, and digital signatures. | +| certificate | An electronic document that is used to provide the identity or validate a public key. | +| protocol | A set of rules and guidelines that govern the behavior and communication with each other. | +| private-key | The confidential key of a key pair used in asymmetric cryptography. | +| public-key | The non-confidential key of a key pair used in asymmetric cryptography. | +| secret-key | A key used to encrypt and decrypt messages in symmetric cryptography. | +| key | A piece of information, usually a string of characters, which, when processed through a cryptographic algorithm, can encode or decode cryptographic data. | +| ciphertext | The result of encryption performed on plaintext using an algorithm (or cipher). | +| signature | A cryptographic value that is calculated from the data and a key known only by the signer. | +| digest | The output of the hash function. | +| initialization-vector | A fixed-size random or pseudo-random value used as an input parameter for cryptographic algorithms. | +| nonce | A random or pseudo-random number that can only be used once in a cryptographic communication. | +| seed | The input to a pseudorandom number generator. Different seeds generate different pseudorandom sequences. | +| 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. | +| shared-secret | A piece of data, known only to the parties involved, in a secure communication. | +| 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. | +| additional-data | ???? TODO ???? | +| password | A secret word, phrase, or sequence of characters used during authentication or authorization. | +| credential | Establishes the identity of a party to communication, usually in the form of cryptographic keys or passwords. | +| token | An object encapsulating a security identity. | +| other | Another type of cryptographic asset. | +| unknown | The type of cryptographic asset is not known. | + +
+\newpage +
+ +## Key Management +[NIST Special Publication 800-57]((https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)) outlines key management guidelines, +including various key states and their purposes. The key states defined in SP 800-57 include: + +1. **Pre-activation**: Keys in this state are generated but not yet placed into active use. They are securely stored until needed, awaiting activation for cryptographic operations. +2. **Active**: Keys in the active state are currently in use for cryptographic operations such as encryption, decryption, or digital signatures. They play a fundamental role in securing data and communications within the system. +3. **Suspended**: Keys in the suspended state are temporarily inactive, typically due to security concerns or operational issues. While suspended, they are not utilized for cryptographic operations but can be reinstated if deemed appropriate. +4. **Deactivated**: Keys in the deactivated state are intentionally rendered inactive, often as part of routine maintenance or security protocols. Once deactivated, they are no longer used for cryptographic operations but may be retained for archival or auditing purposes. +5. **Compromised**: Keys in the compromised state are deemed untrustworthy due to known or suspected security breaches. Immediate action is required to revoke and replace compromised keys to prevent unauthorized access and safeguard the integrity of cryptographic operations. +6. **Destroyed**: Keys in the destroyed state are permanently eradicated from the system, typically to prevent any potential misuse or unauthorized access. Destruction ensures that the keys are irrecoverable and cannot be compromised, thus enhancing overall security. + +These key states play a critical role in the lifecycle management of cryptographic keys, ensuring that keys are properly managed, secured, and monitored throughout their operational lifespan, thereby maintaining the integrity and confidentiality of sensitive data and systems. + +CycloneDX fully supports key states as detailed in the example below: + +```json +"cryptoProperties": { + "assetType": "related-crypto-material", + "relatedCryptoMaterialProperties": { + "type": "private-key", + "state": "compromised", + ... + } +} +``` + +
+\newpage +
+ +## Intersection of Key Management States and Lifecycle Phases +As outlined in the [CycloneDX Authoritative Guide to SBOM](https://cyclonedx.org/guides/), CycloneDX supports lifecycles +that encompass those in the Software Development Life Cycle (SDLC) and those commonly used in Software Asset Management +(SAM). CycloneDX lifecycle phases can be used together with the key management states defined by NIST to help in +identifying and preventing risks associated with compromised keys and operational anomalies. + +CycloneDX defines the following phases: + +| **Phase** | **Description** | +|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Design | BOM produced early in the development lifecycle containing an inventory of components and services that are proposed or planned to be used. The inventory may need to be procured, retrieved, or resourced prior to use. | +| Pre-build | BOM consisting of information obtained prior to a build process and may contain source files, development artifacts, and manifests. The inventory may need to be resolved and retrieved prior to use. | +| Build | BOM consisting of information obtained during a build process where component inventory is available for use. The precise versions of resolved components are usually available at this time as well as the provenance of where the components were retrieved from. | +| Post-build | BOM consisting of information obtained after a build process has completed and the resulting components(s) are available for further analysis. Built components may exist as the result of a CI/CD process, may have been installed or deployed to a system or device, and may need to be retrieved or extracted from the system or device. | +| Operations | BOM produced that represents inventory that is running and operational. This may include staging or production environments and will generally encompass multiple SBOMs describing the applications and operating system, along with HBOMs describing the hardware that makes up the system. Operations Bill of Materials (OBOM) can provide a full-stack inventory of runtime environments, configurations, and additional dependencies. | +| Discovery | BOM consisting of information observed through network discovery providing point-in-time enumeration of embedded, on-premise, and cloud-native services such as server applications, connected devices, microservices, and serverless functions. | +| Decommission | BOM containing inventory that will be or has been retired from operations. | + +
+\emptyparagraph +
+ +Key management states, as defined in NIST SP 800-57, offer a structured framework for managing cryptographic keys +throughout their lifecycle. These states—such as pre-activation, active, suspended, deactivated, compromised, and +destroyed—align closely with the lifecycle phases defined in CycloneDX. By integrating key management states with +CycloneDX lifecycle phases, organizations gain a comprehensive understanding of the security posture of their +cryptographic assets and can identify potential risks more effectively. + +
+\newpage +
+ +### Manage Keys From Inception +In the CycloneDX lifecycle, the "Design" and "Pre-build" phases corresponds to the pre-activation state in key +management. During development, cryptographic keys are generated but not yet put into active use. By linking +pre-activation with these phases, organizations can ensure that cryptographic keys are securely managed from their +inception, minimizing the risk of unauthorized access or compromise before deployment. + +### Anomaly Detection +As software progresses to the "Build" and "Post-build" phases in CycloneDX, cryptographic keys transition into the +active state, where they are utilized for encryption, decryption, or digital signatures. Integration with key +management states allows organizations to monitor the active keys' security status and detect anomalies that may +indicate compromise or unauthorized usage, thereby mitigating potential risks during the software development lifecycle. + +During the "Operations" phase in CycloneDX, cryptographic keys may undergo transitions such as suspension or deactivation +if security concerns arise. For example, if a vulnerability is discovered in a cryptographic algorithm, keys associated +with that algorithm may be suspended or deactivated to prevent exploitation. By correlating these transitions with the +CycloneDX lifecycle, organizations can promptly respond to security incidents and mitigate associated risks, ensuring +the integrity and confidentiality of cryptographic operations across deployment environments. + +Furthermore, the compromised and destroyed states in key management align with the "Decommission" phase in CycloneDX. +When cryptographic keys reach the end of their operational lifespan, they are revoked, destroyed, or securely +decommissioned to prevent unauthorized access. CycloneDX facilitates the documentation of these actions, providing a +comprehensive audit trail of key management activities and ensuring regulatory compliance. + +Any deviances from expected lifecycle mappings to key management states should be investigated. + +
+\emptyparagraph +
+ +![Lifecycles](../../images/Lifecycles.svg) + +### Prevention of Compromised Keys During Build or Deployment +The compromised key management state, plays a crucial role in preventing software supply chain attacks when integrated +into the "Build" lifecycle phase in CycloneDX. During the build phase, cryptographic keys are utilized to sign software +artifacts, ensuring their authenticity and integrity. By leveraging the "compromised" state within CycloneDX, +organizations can detect compromised keys promptly and prevent their unauthorized usage during the build process. +For instance, if a key used for code signing is compromised, CycloneDX metadata can flag the key as compromised, +triggering automated processes to revoke its access privileges and prevent its use in signing software artifacts. +This proactive approach mitigates the risk of adversaries leveraging compromised keys to inject malicious code into the +software supply chain, enhancing the security and trustworthiness of software builds distributed to software consumers. + +By leveraging key management states within the context of the CycloneDX lifecycle phases, organizations can enhance +their risk management practices, proactively identify security vulnerabilities, and maintain the integrity of +cryptographic operations throughout the software development lifecycle. This integrated approach enables organizations +to effectively safeguard sensitive data and mitigate potential risks associated with cryptographic assets. + + +
+\newpage +
diff --git a/CBOM/en/0x31-Dependencies.md b/CBOM/en/0x31-Dependencies.md deleted file mode 100644 index b834216..0000000 --- a/CBOM/en/0x31-Dependencies.md +++ /dev/null @@ -1,26 +0,0 @@ -# Dependencies -Dependencies between components in the components array are added to the dependencies array. - -The two dependency types are: - -implements: refers to crypto assets implemented, or statically available in a component. Examples are the algorithms provided by crypto libraries. A crypto asset 'implemented' by a component does not imply that it is in use. -uses: refers to crypto assets in use, or being referenced by other components. The referencing can be done by explicit function calls or by configuration at run time. Usage may change over time, so CBOMs always represent a snapshot at a given point in time. -A component can have a dependencies of both types implements and uses. A crypto asset A is considered as 'used' by component C if there is a used dependency path from C to A. - -Note: In classic SBOM, a component represents a library, application, service, etc. that is used as a dependency within the application. Since for some crypto, e.g. the relationship between a protocol and the algorithms used, this relationship is not external but internal, we decided to express this relationship differently by using specific properties to reference assets rather than using the classical dependency implementation. - - -![Dependencies](./images/dependencies.svg) - - -The example shows an application (nginx) that uses the libssl cryptographic library. This library implements the TLSv1.2 protocol. The relationship between the application, the library and the protocol can be expressed by using the depenedencies properties of the SBOM standard. - -Since a TLS protocol supports different cipher suites that include multiple algorithms, there should be a way to represent these relationships as part of the CBOM. Compared to adding the algorithms as "classic" dependencies to the protocol, we defined special property fields that allow referencing the deployment with additional meaning. The protocolProperties allow adding an array of algorithms to a cipher suite as part of the cipher suite array. By modeling and then referencing these algorithms, we can still have only one classical component at the SBOM level, but a subtree of crypto dependencies within the crypto asset components. - -```json -TODO -``` - -
-\newpage -
\ No newline at end of file diff --git a/CBOM/en/0x40-Anatomy-of-a-CBOM.md b/CBOM/en/0x40-Anatomy-of-a-CBOM.md deleted file mode 100644 index 511e75d..0000000 --- a/CBOM/en/0x40-Anatomy-of-a-CBOM.md +++ /dev/null @@ -1,7 +0,0 @@ -# Anatomy of a CBOM - -TODO - -
-\newpage -
diff --git a/CBOM/en/0x30-Practical-Examples.md b/CBOM/en/0x40-Practical-Examples.md similarity index 78% rename from CBOM/en/0x30-Practical-Examples.md rename to CBOM/en/0x40-Practical-Examples.md index 1b99669..099f3d7 100644 --- a/CBOM/en/0x30-Practical-Examples.md +++ b/CBOM/en/0x40-Practical-Examples.md @@ -59,8 +59,7 @@ AES-128-GCM and SHA512withRSA. An example with the QSC Signature algorithm Dilithium5 is listed below. ```json -"components": [ - { +"components": [ { "name": "Dilithium5", "type": "cryptographic-asset", "cryptoProperties": { @@ -75,12 +74,8 @@ An example with the QSC Signature algorithm Dilithium5 is listed below. }, "oid": "1.3.6.1.4.1.2.267.7.8.7" } - } -] + } ] ``` -
-\newpage -
## Key The following example demonstrates how an RSA-2048 public key can be included in a CBOM. @@ -107,45 +102,24 @@ The following example demonstrates how an RSA-2048 public key can be included in }, "oid": "1.2.840.113549.1.1.1" } - }, - { + }, { "name": "RSA-2048", "type": "cryptographic-asset", "bom-ref": "crypto/algorithm/rsa-2048@1.2.840.113549.1.1.1", - "cryptoProperties": { - "assetType": "algorithm", - "algorithmProperties": { - "parameterSetIdentifier": "2048", - "executionEnvironment": "software-plain-ram", - "implementationPlatform": "x86_64", - "cryptoFunctions": [ "encapsulate", "decapsulate" ] - }, - "oid": "1.2.840.113549.1.1.1" - } - }, - { + "cryptoProperties": { ... } + }, { "name": "AES-128-GCM", "type": "cryptographic-asset", "bom-ref": "crypto/algorithm/aes-128-gcm@2.16.840.1.101.3.4.1.6", - "cryptoProperties": { - "assetType": "algorithm", - "algorithmProperties": { - "parameterSetIdentifier": "128", - "primitive": "ae", - "mode": "gcm", - "executionEnvironment": "software-plain-ram", - "implementationPlatform": "x86_64", - "cryptoFunctions": [ "keygen", "encrypt", "decrypt" ], - "classicalSecurityLevel": 128, - "nistQuantumSecurityLevel": 1 - }, - "oid": "2.16.840.1.101.3.4.1.6" - } - } ] + "cryptoProperties": { ... } + } +] ``` +A complete example can be found at [https://cyclonedx.org/shortcut/example/key](https://cyclonedx.org/shortcut/example/key) + ## Protocol -A cryptographic protocol is added to the components array of the BOM. The example below lists an instance of the protocol TLS v1.2 with a number of TLS cipher suites. +The following example lists an instance of the TLS v1.2 protocol with a number of cipher suites. ```json "components": [ @@ -171,7 +145,7 @@ A cryptographic protocol is added to the components array of the BOM. The exampl } ], "cryptoRefArray": [ - "crypto/certificate/google.com@sha256:1e15e0fbd3ce95bde5945633ae96add551341b11e5bae7bba12e98ad84a5beb4" + "crypto/certificate/google.com@sha256:1e15...beb4" ] }, "oid": "1.3.18.0.2.32.104" @@ -180,7 +154,7 @@ A cryptographic protocol is added to the components array of the BOM. The exampl { "name": "google.com", "type": "cryptographic-asset", - "bom-ref": "crypto/certificate/google.com@sha256:1e15e0fbd3ce95bde5945633ae96add551341b11e5bae7bba12e98ad84a5beb4", + "bom-ref": "crypto/certificate/google.com@sha256:1e15...beb4", "cryptoProperties": { "assetType": "certificate", "certificateProperties": { @@ -305,6 +279,11 @@ A cryptographic protocol is added to the components array of the BOM. The exampl } ] ``` +A complete example can be found at [https://cyclonedx.org/shortcut/example/protocol](https://cyclonedx.org/shortcut/example/protocol) + +
+\newpage +
## Certificate The following example details an X.509 certificate in a CBOM. @@ -314,7 +293,7 @@ The following example details an X.509 certificate in a CBOM. { "name": "google.com", "type": "cryptographic-asset", - "bom-ref": "crypto/certificate/google.com@sha256:1e15e0fbd3ce95bde5945633ae96add551341b11e5bae7bba12e98ad84a5beb4", + "bom-ref": "crypto/certificate/google.com@sha256:1e15...beb4", "cryptoProperties": { "assetType": "certificate", "certificateProperties": { @@ -333,59 +312,24 @@ The following example details an X.509 certificate in a CBOM. "name": "SHA512withRSA", "type": "cryptographic-asset", "bom-ref": "crypto/algorithm/sha-512-rsa@1.2.840.113549.1.1.13", - "cryptoProperties": { - "assetType": "algorithm", - "algorithmProperties": { - "parameterSetIdentifier": "512", - "executionEnvironment": "software-plain-ram", - "implementationPlatform": "x86_64", - "certificationLevel": [ "none" ], - "cryptoFunctions": [ "digest" ], - "nistQuantumSecurityLevel": 0 - }, - "oid": "1.2.840.113549.1.1.13" - } + "cryptoProperties": { ... } }, { "name": "RSA-2048", "type": "cryptographic-asset", "bom-ref": "crypto/key/rsa-2048@1.2.840.113549.1.1.1", - "cryptoProperties": { - "assetType": "related-crypto-material", - "relatedCryptoMaterialProperties": { - "type": "public-key", - "id": "2e9ef09e-dfac-4526-96b4-d02f31af1b22", - "state": "active", - "size": 2048, - "algorithmRef": "crypto/algorithm/rsa-2048@1.2.840.113549.1.1.1", - "securedBy": { - "mechanism": "None" - }, - "creationDate": "2016-11-21T08:00:00Z", - "activationDate": "2016-11-21T08:20:00Z" - }, - "oid": "1.2.840.113549.1.1.1" - } + "cryptoProperties": { ... } }, { "name": "RSA-2048", "type": "cryptographic-asset", "bom-ref": "crypto/algorithm/rsa-2048@1.2.840.113549.1.1.1", - "cryptoProperties": { - "assetType": "algorithm", - "algorithmProperties": { - "parameterSetIdentifier": "2048", - "executionEnvironment": "software-plain-ram", - "implementationPlatform": "x86_64", - "certificationLevel": [ "none" ], - "cryptoFunctions": [ "encapsulate", "decapsulate" ] - }, - "oid": "1.2.840.113549.1.1.1" - } + "cryptoProperties": { ... } } ] ``` +A complete example can be found at [https://cyclonedx.org/shortcut/example/cert](https://cyclonedx.org/shortcut/example/cert)
\newpage diff --git a/CBOM/en/0x41-Dependencies.md b/CBOM/en/0x41-Dependencies.md new file mode 100644 index 0000000..1e57e6c --- /dev/null +++ b/CBOM/en/0x41-Dependencies.md @@ -0,0 +1,47 @@ +# Dependencies +CycloneDX provides the ability to describe components and their dependency on other components. This relies on a +component's `bom-ref` to associate the component with the dependency element in the graph. The only requirement for bom-ref +is that it is unique within the BOM. Package URL (PURL) is an ideal choice for bom-ref as it will be both unique and +readable. If PURL is not an option or not all components represented in the BOM contain a PURL, then UUID is recommended. +A dependency graph is typically one node deep and capable of representing both direct and transitive relationships. + +Refer to the [CycloneDX Authoritative Guide to SBOM](https://cyclonedx.org/guides/) for additional details. In the +context cryptographic dependencies, CycloneDX provides some additional capabilities. + +As of CycloneDX v1.6, there are two types of dependencies, dependsOn and provides. + +| Dependency Type | Description | +| --------------- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| dependsOn | The bom-ref identifiers of the components or services that are dependencies of this dependency object. | +| provides | The bom-ref identifiers of the components or services that define a given specification or standard, which are provided or implemented by this dependency object. For example, a cryptographic library which implements a cryptographic algorithm. A component which implements another component does not imply that the implementation is in use. | + + +The dependency type, dependsOn, is leveraged by classic SBOMs to define a complete graph of direct and transitive +dependencies. However, for cryptographic and similar assets, "provides" allows for many additional use cases. + +![Dependencies](./images/dependencies.svg) + +The example shows an application (nginx) that uses the libssl cryptographic library. This library implements the TLSv1.2 protocol. The relationship between the application, the library and the protocol can be expressed by using the depenedencies properties of the SBOM standard. + +Since a TLS protocol supports different cipher suites that include multiple algorithms, there should be a way to represent these relationships as part of the CBOM. Compared to adding the algorithms as "classic" dependencies to the protocol, we defined special property fields that allow referencing the deployment with additional meaning. The protocolProperties allow adding an array of algorithms to a cipher suite as part of the cipher suite array. By modeling and then referencing these algorithms, we can still have only one classical component at the SBOM level, but a subtree of crypto dependencies within the crypto asset components. + +The following example illustrates a simple application with a dependency on a cryptographic library, which in turn, +implements AES-128-GCM. The cryptographic library also has a dependency on another library. + +```json +"dependencies": [ + { + "ref": "acme-application", + "dependsOn": ["crypto-library"] + }, + { + "ref": "crypto-library", + "provides": ["aes128gcm"], + "dependsOn": ["some-library"] + } +] +``` + +
+\newpage +
\ No newline at end of file diff --git a/CBOM/en/images/CBOM-Component-Architecture.drawio b/CBOM/en/images/CBOM-Component-Architecture.drawio new file mode 100644 index 0000000..d83c5e7 --- /dev/null +++ b/CBOM/en/images/CBOM-Component-Architecture.drawio @@ -0,0 +1,109 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/CBOM/en/images/CBOM-Component-Architecture.svg b/CBOM/en/images/CBOM-Component-Architecture.svg new file mode 100644 index 0000000..9a4bf05 --- /dev/null +++ b/CBOM/en/images/CBOM-Component-Architecture.svg @@ -0,0 +1,994 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/CBOM/en/images/dependencies.drawio b/CBOM/en/images/dependencies.drawio index 2d77987..4438ec5 100644 --- a/CBOM/en/images/dependencies.drawio +++ b/CBOM/en/images/dependencies.drawio @@ -1,4 +1,4 @@ - + @@ -7,7 +7,7 @@ - + @@ -15,26 +15,26 @@ - + - + - + - + - + - + - - + + @@ -42,13 +42,13 @@ - + - - + + - + @@ -57,30 +57,138 @@ - + - - + + - + - + - - + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/CBOM/en/images/dependencies.svg b/CBOM/en/images/dependencies.svg index 32c0340..d14a71b 100644 --- a/CBOM/en/images/dependencies.svg +++ b/CBOM/en/images/dependencies.svg @@ -2,226 +2,77 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -313,131 +164,81 @@ - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -556,45 +357,47 @@ - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -651,29 +454,7 @@ - - - - - - - - - - - - - - - - - - - - - - - + @@ -709,89 +490,592 @@ - - - - - - - - - - - - - - - - - - - - - - - - - + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +