From 207e4e6abc30142c3d56c000b0239443795fd415 Mon Sep 17 00:00:00 2001 From: Jan Kowalleck Date: Mon, 29 Sep 2025 16:36:40 +0200 Subject: [PATCH] fix: various markdown fixes and streamlinings Signed-off-by: Jan Kowalleck --- .editorconfig | 4 + Attestations/en/0x60-Signing.md | 12 +- CBOM/en/0x60-Linking.md | 19 +- CBOM/en/0x80-Cryptography-Definitions.md | 22 +- MBOM/en/0x10-Introduction.md | 2 +- MBOM/en/0x30-Use_Case_Software_Simple.md | 234 +++++++++--------- MBOM/en/0x91-Appendix-B_References.md | 8 +- SBOM/en/0x15-Object-Model.md | 14 +- SBOM/en/0x30-Use_Cases.md | 2 +- SBOM/en/0x40-BOM_Coverage_Maturity_Quality.md | 22 +- SBOM/en/0x52-Linking.md | 19 +- SBOM/en/0x60-Evidence.md | 4 +- SBOM/en/0x80-Extensibility.md | 2 +- SBOM/en/0x91-Appendix-B_References.md | 6 +- SaaSBOM/en/0x20-Object-Model.md | 14 +- SaaSBOM/en/0x91-Appendix-B_References.md | 6 +- VDR_VEX/en/0x10-Introduction.md | 14 +- VDR_VEX/en/0x20-Object-Model.md | 6 + VDR_VEX/en/0x30-VDR-Overview.md | 3 + VDR_VEX/en/0x91-Appendix-B_References.md | 6 +- 20 files changed, 218 insertions(+), 201 deletions(-) create mode 100644 .editorconfig diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 00000000..38ce30a5 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,4 @@ + +[*.md] +trim_trailing_whitespace = false + diff --git a/Attestations/en/0x60-Signing.md b/Attestations/en/0x60-Signing.md index d3b4190a..a5006957 100644 --- a/Attestations/en/0x60-Signing.md +++ b/Attestations/en/0x60-Signing.md @@ -11,13 +11,13 @@ CycloneDX supports signing to ensure the authenticity and integrity of the attes The personas that could sign claims, evidence, standards, or attestations can be categorized into two main groups: * `Producers`: These are the entities responsible for creating and managing the SBOMs and attestations. They could include: - * `Software developers`: Developers of software components or applications are often responsible for generating claims that accurately reflect their Software Development Lifecycle (SDL). - * `Software distributors`: Distributors of software packages may create SBOMs that aggregate the SBOMs of individual components included in their packages and provide assurances for the software packages in the form of assurances. - * `Build or deployment tools`: Automated build or deployment tools can generate SBOMs and evidence for supporting the claims required by the developers as part of their workflow, ensuring that the SBOMs are up-to-date with the latest code changes and the claims are supported . - * `Software supply chain security tools`: Security tools can analyze SBOMs to identify potential vulnerabilities, compliance issues, or other relevant information and generate evidence of security testing and validation. + * `Software developers`: Developers of software components or applications are often responsible for generating claims that accurately reflect their Software Development Lifecycle (SDL). + * `Software distributors`: Distributors of software packages may create SBOMs that aggregate the SBOMs of individual components included in their packages and provide assurances for the software packages in the form of assurances. + * `Build or deployment tools`: Automated build or deployment tools can generate SBOMs and evidence for supporting the claims required by the developers as part of their workflow, ensuring that the SBOMs are up-to-date with the latest code changes and the claims are supported . + * `Software supply chain security tools`: Security tools can analyze SBOMs to identify potential vulnerabilities, compliance issues, or other relevant information and generate evidence of security testing and validation. * `Verifiers`: These are the entities responsible for validating and verifying the authenticity and integrity of SBOMs or attestations. They could include: - * `Organizations consuming software`: Organizations that use or integrate software components may require attestations that meet a certain standard. (e.g: PCI-DSS certified software) - * `Regulatory bodies or auditors`: Regulatory bodies or auditors may use the claims, evidence and attestation generated by the software producers as part of compliance audits or certification processes. + * `Organizations consuming software`: Organizations that use or integrate software components may require attestations that meet a certain standard. (e.g: PCI-DSS certified software) + * `Regulatory bodies or auditors`: Regulatory bodies or auditors may use the claims, evidence and attestation generated by the software producers as part of compliance audits or certification processes. In some cases, a single entity may act as both a producer and a verifier of SBOMs or attestations. For example, a software development company may generate SBOMs and attestations for its own products and also verify them from its suppliers. diff --git a/CBOM/en/0x60-Linking.md b/CBOM/en/0x60-Linking.md index 27fbec5c..2b299e7b 100644 --- a/CBOM/en/0x60-Linking.md +++ b/CBOM/en/0x60-Linking.md @@ -5,15 +5,14 @@ systems or other BOMs. This deep-linking capability is referred to as BOM-Link a and compliant with [RFC-8141](https://www.rfc-editor.org/rfc/rfc8141.html). **Syntax**: -```ini -urn:cdx:serialNumber/version#bom-ref +```text +"urn:cdx:" "/" [ "#" ] ``` -**Examples**: -```ini -urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1 -urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA -``` +Where: +- Elements in `""` indicate string literals +- Elements in `<>` indicate fields +- Elements in `[]` indicate optionals | Field | Description | | ------------ | --------------------------------------------------------------------------------- | @@ -21,6 +20,12 @@ urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA | version | The version of the BOM. The default version is `1`. | | bom-ref | The unique identifier of the component, service, or vulnerability within the BOM. | +**Examples**: +```text +urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1 +urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA +``` + There are many use cases that BOM-Link supports. Two common scenarios are: * Reference one BOM from another BOM * Reference a specific component or service in one BOM from another BOM diff --git a/CBOM/en/0x80-Cryptography-Definitions.md b/CBOM/en/0x80-Cryptography-Definitions.md index a6dd98f3..e24d1ed1 100644 --- a/CBOM/en/0x80-Cryptography-Definitions.md +++ b/CBOM/en/0x80-Cryptography-Definitions.md @@ -6,18 +6,20 @@ These definitions supports consistent identification, classification, and report ## Definition structure -The format for each algorithm entry is: -``` -AlgorithmFamily: Pattern[-{optionalParameter}] +**Syntax**: +```text + ( "[-{" "}]" )* ``` Where: -- `AlgorithmFamily` is the algorithm family -- `Pattern` shows how the algorithm should be referenced -- Elements in `[]` are optional parameters -- Elements in `()` indicate choices -- The `|` symbol indicates alternative choices -- Elements in `{}` indicate placeholders +- Elements in `""` indicate string literals +- Elements in `<>` indicate fields +- Elements in `()*` indicate optionals with cardinality of zero to infinity + +| Field | Description | +| ----- | ----------- | +| Pattern | shows how the algorithm should be referenced | +| PatternParameter | shows how the algorithm should be parameterized | ## Example @@ -76,7 +78,7 @@ The following example defines the P-256 NIST curve, along with its aliases secp2 "curves": [ { "name": "P-256", - "description": null, + "description": "...", "oid": "1.2.840.10045.3.1.7", "form": "Weierstrass", "aliases": [ diff --git a/MBOM/en/0x10-Introduction.md b/MBOM/en/0x10-Introduction.md index b6e9ffb3..25a939f2 100644 --- a/MBOM/en/0x10-Introduction.md +++ b/MBOM/en/0x10-Introduction.md @@ -26,7 +26,7 @@ The information of an MBOM is designed to be compatible with standards such as: A few high-level use cases for MBOM and its compatibility with other CycloneDX xBOM types include: * **Software (SBOM)** - Describe how a software component or service is built and deployed via a Continuous Integration and Continuous Delivery (CI/CD) pipeline. - * *This include capturing simple application builds using traditional `Makefiles` or more complex, multi-tier software using CI/CD platforms such as Jenkins, Tekton, CircleCI, etc.* + * *This include capturing simple application builds using traditional `Makefiles` or more complex, multi-tier software using CI/CD platforms such as Jenkins, Tekton, CircleCI, etc.* * **Hardware (HBOM)** - Describe how a hardware component or service is manufactured. * **Machine Learning (MLBOM)** - Describe the process of training, quantizing, optimizing and deploying ML models. * **Data Processing Pipelines** - Describes how data is marshalled, transformed, enhanced, curated, stored, analyzed and used. diff --git a/MBOM/en/0x30-Use_Case_Software_Simple.md b/MBOM/en/0x30-Use_Case_Software_Simple.md index 2c69abcf..9851cc68 100644 --- a/MBOM/en/0x30-Use_Case_Software_Simple.md +++ b/MBOM/en/0x30-Use_Case_Software_Simple.md @@ -8,7 +8,7 @@ This example shows how a simple `helloworld` application's build process can be The application itself is composed a single "C" source file, `helloworld.c`, which contains the following code: -``` +```c #include int main() { @@ -21,7 +21,7 @@ int main() { The application is built using the GCC compiler using the following `Makefile`: -``` +```make CC = gcc CFLAGS = -Wall @@ -38,7 +38,7 @@ clean: The application can be built by manually running the following command in a terminal/shell of a suitable operating system: -``` +```shellSession $ make build ``` @@ -69,63 +69,59 @@ The `component` objects are defined as follows: #### Source components -- `helloworld.c`: -
- ``` - { - "bom-ref": "file:///CycloneDX/MBOM-examples/simple-application-makefile/helloworld.c", - "type": "file", - "name": "helloworld.c", - "version": "1.0", - "hashes": [ - { - "alg": "SHA-256", - "content": "..." - } - ] - } - ``` +- `helloworld.c`: + ```json + { + "bom-ref": "file:///CycloneDX/MBOM-examples/simple-application-makefile/helloworld.c", + "type": "file", + "name": "helloworld.c", + "version": "1.0", + "hashes": [ + { + "alg": "SHA-256", + "content": "..." + } + ] + } + ``` #### Build components -- `Makefile` -
- ``` - { - "bom-ref": "file:///CycloneDX/MBOM-examples/simple-application-makefile/Makefile", - "type": "file", - "name": "Makefile", - "version": "1.0", - "hashes": [ - { - "alg": "SHA-256", - "content": "..." - } - ] - } - ``` - -- `gcc` - GCC compiler -
- ``` - { - "bom-ref": "file:///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gcc", - "type": "application", - "name": "gcc", - "version": "16.0.0 (clang-1600.0.26.4)" - } - ``` - -- `make` utility -
- ``` - { - "bom-ref": "file:///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/make", - "type": "application", - "name": "GNU Make", - "version": "3.81" - } - ``` +- `Makefile` + ```json + { + "bom-ref": "file:///CycloneDX/MBOM-examples/simple-application-makefile/Makefile", + "type": "file", + "name": "Makefile", + "version": "1.0", + "hashes": [ + { + "alg": "SHA-256", + "content": "..." + } + ] + } + ``` + +- `gcc` - GCC compiler + ```json + { + "bom-ref": "file:///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gcc", + "type": "application", + "name": "gcc", + "version": "16.0.0 (clang-1600.0.26.4)" + } + ``` + +- `make` utility + ```json + { + "bom-ref": "file:///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/make", + "type": "application", + "name": "GNU Make", + "version": "3.81" + } + ``` ### Event-Trigger relationship @@ -137,16 +133,16 @@ This section describes how the human action `make build` can be represented in ` In all cases, workflows are triggered by some sort of explicit, human or automated event. In this example, a person manually executed the following command in a Bash command prompt: -``` -make build +```shellSession +$ make build ``` this event could be represented as follows: -``` -timestamp: “2025-01-01T14:00:00+00:00”, -name: “make build”, -description: “Command line build” +```text +timestamp: "2025-01-01T14:00:00+00:00", +name: "make build", +description: "Command line build" ``` **Note**: *Workflows may be triggered by events dynamically received from other systems or services. In these cases, the event could include the raw event `data` itself as well as information.about the `source` system or service the event was sent by.* @@ -157,15 +153,15 @@ The trigger provides context about an event, as well as describing any additiona This could be represented as follows: -``` +```jsonc { - “timeActivated”: “2025-01-01T14:00:00+00:00”, - “bom-ref": "cdx:mbom:trigger:uuid:1a9b…", - “uid": ”uuid:1a9b…", - “type": "manual", - “name": "make trigger", - “description": "Bash, command-line build trigger” - “event”: { + "timeActivated": "2025-01-01T14:00:00+00:00", + "bom-ref": "cdx:mbom:trigger:uuid:1a9b…", + "uid": "uuid:1a9b…", + "type": "manual", + "name": "make trigger", + "description": "Bash, command-line build trigger", + "event": { // event content goes here }, ... @@ -182,7 +178,7 @@ This could be represented as follows: In this example, there is only one logical "task"; that is, the build process initiated by the `make build` command step. This task itself can be represented as: -``` +```json { "bom-ref": "cdx:mbom:task:uuid:dbb6c5c0-6958-4a18-ac67-d897dbee76b6", "uid": "uuid:dbb6c5c0-6958-4a18-ac67-d897dbee76b6", @@ -199,7 +195,7 @@ As you can see we provide the two logical `taskType` values of `clean` and `buil The single command-line, build `step` can be added to the task: -``` +```json { "bom-ref": "cdx:mbom:task:uuid:dbb6....", "uid": "uuid:dbb6...", @@ -220,7 +216,7 @@ The single command-line, build `step` can be added to the task: The `trigger` defined previously can be added to the task as follows: -``` +```json { "bom-ref": "cdx:mbom:task:uuid:dbb6....", "uid": "uuid:dbb6...", @@ -241,24 +237,24 @@ The `trigger` defined previously can be added to the task as follows: In this example, the workflow represents the single `task` execution as follows: -``` +```jsonc { - “bom-ref": "cdx:mbom:workflow:uuid:431ff656-8f90-410b-a614-c3916b842036", - “uid": ”uuid:431ff656-8f90-410b-a614-c3916b842036", - “taskTypes”: [“clean”, “build”], - “tasks”: [ + "bom-ref": "cdx:mbom:workflow:uuid:431ff656-8f90-410b-a614-c3916b842036", + "uid": "uuid:431ff656-8f90-410b-a614-c3916b842036", + "taskTypes": ["clean", "build"], + "tasks": [ // task goes here ], - “taskDependencies”: [ + "taskDependencies": [ { - “ref”: “cdx:mbom:task:uuid:dbb6…" + "ref": "cdx:mbom:task:uuid:dbb6…" } ], - “trigger”: { + "trigger": { // trigger goes here }, - “resourceReferences”: [...], - “runtimeTopology”: [...], + "resourceReferences": [...], + "runtimeTopology": [...], ... } ``` @@ -271,12 +267,12 @@ In this example, the workflow represents the single `task` execution as follows: The `formula`for building this example application, in addition to describing the single `workflow` for this example, also includes the full listing (or manifest) of resources referenced by the workflow and its task. These elements can be represented as follows: -``` +```jsonc { - components: [ + "components": [ // component content goes here ], - workflows: [ + "workflows": [ // workflow content goes here ] } @@ -284,7 +280,7 @@ The `formula`for building this example application, in addition to describing th and finally the `formula` is placed under the CycloneDX BOM's `formulation` keyname of the Software Bill of Materials (SBOM): -``` +```jsonc { "bomFormat": "CycloneDX", "specVersion": "1.6", @@ -297,7 +293,7 @@ and finally the `formula` is placed under the CycloneDX BOM's `formulation` keyn }, ... }, - "formulation: [{ + "formulation": [{ // formula content goes here } ], @@ -309,7 +305,7 @@ and finally the `formula` is placed under the CycloneDX BOM's `formulation` keyn In our example, we chose to list components used to build the application under the `formula` keyname. However, it is possible to instead list them under the top-level `components` array's keyname. -This choice was made since this allows the MBOM information to be separated into a separate document from the associated SBOM and linked via the [CycloneDX `BOM-Link` capability](https://cyclonedx.org/capabilities/bomlink/). This would be accomplished in the same manner as described for separating vulnerability information using the [CycloneDX Vulnerability Disclosure Report (VDR) capability](https://cyclonedx.org/capabilities/vdr/).* +This choice was made since this allows the MBOM information to be separated into a separate document from the associated SBOM and linked via the [CycloneDX `BOM-Link` capability](https://cyclonedx.org/capabilities/bomlink/). This would be accomplished in the same manner as described for separating vulnerability information using the [CycloneDX Vulnerability Disclosure Report (VDR) capability](https://cyclonedx.org/capabilities/vdr/). --- @@ -331,42 +327,38 @@ This section will show how to represent the runtime topology for the simple appl For this example, we can choose to represent the key platform elements used to run the `make` command. This could include the shell and the operating system used to run the build process as CycloneDX `components`. For example: -- The `Bash` shell used to run the `make` command: -
- ``` - { - "bom-ref": "file:///bin/bash", - "type": "platform", - "name": "GNU bash", - "version": "3.2.57(1)-release (arm64-apple-darwin23)" - } - ``` - -- The `OS X` operating system the Bash terminal was running on: -
- ``` - { - "bom-ref": "urn:cdx:os://macosx@14.6.1+23G93", - "type": "operating-system", - "name": "macOS", - "version": "14.6.1+23G93" - } - ``` +- The `Bash` shell used to run the `make` command: + ```json + { + "bom-ref": "file:///bin/bash", + "type": "platform", + "name": "GNU bash", + "version": "3.2.57(1)-release (arm64-apple-darwin23)" + } + ``` +- The `OS X` operating system the Bash terminal was running on: + ```json + { + "bom-ref": "urn:cdx:os://macosx@14.6.1+23G93", + "type": "operating-system", + "name": "macOS", + "version": "14.6.1+23G93" + } + ``` #### Hardware Additionally, we could describe the actual device used for the build process to an appropriate level of detail: -- `Mac OS X` machine -
- ``` - { - "bom-ref": "urn:cdx:device:sn:CBFX71DM3", - "type": "device", - "name": "Matt's MacBook Pro", - "description": "Apple M3 Max, 16 inch" - } - ``` +- `Mac OS X` machine + ```json + { + "bom-ref": "urn:cdx:device:sn:CBFX71DM3", + "type": "device", + "name": "Matt's MacBook Pro", + "description": "Apple M3 Max, 16 inch" + } + ``` ### Runtime topology relationships diff --git a/MBOM/en/0x91-Appendix-B_References.md b/MBOM/en/0x91-Appendix-B_References.md index dd191aab..b8b80774 100644 --- a/MBOM/en/0x91-Appendix-B_References.md +++ b/MBOM/en/0x91-Appendix-B_References.md @@ -2,19 +2,19 @@ The following resources may be useful to users and adopters of this standard: -* Package URL specification: [https://github.com/package-url/purl-spec/](https://github.com/package-url/purl-spec/) +* Package URL specification: * Specifically, the pURL types reference in examples: * [github](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#github) * *Example*: `pkg:github/package-url/purl-spec@244fd47e07d1004#everybody/loves/dogs` * [golang](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#golang) - * *Example*:`pkg:golang/github.com/gorilla/context@234fd47e07d1004f0aed9c#api` + * *Example*: `pkg:golang/github.com/gorilla/context@234fd47e07d1004f0aed9c#api` * [huggingface](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#huggingface) * *Example*: `pkg:huggingface/microsoft/deberta-v3-base@559062ad13d311b87b2c455e67dcd5f1c8f65111?repository_url=https://hub-ci.huggingface.co` ##### References in examples -* gcc [https://gcc.gnu.org/](https://gcc.gnu.org/) -* Tekton [https://tekton.dev/](https://tekton.dev/) +* gcc +* Tekton --- diff --git a/SBOM/en/0x15-Object-Model.md b/SBOM/en/0x15-Object-Model.md index 4a7598a5..2f5243b9 100644 --- a/SBOM/en/0x15-Object-Model.md +++ b/SBOM/en/0x15-Object-Model.md @@ -113,13 +113,13 @@ or industry-specific use cases. ## Serialization Formats CycloneDX can be represented in JSON, XML, and Protocol Buffers (protobuf) and has corresponding schemas for each. -| **Format** | **Resource** | **URL** | -|------------|---------------|--------------------------------------------------| -| JSON | Documentation | https://cyclonedx.org/docs/latest/json/ | -| JSON | Schema | https://cyclonedx.org/schema/bom-1.6.schema.json | -| XML | Documentation | https://cyclonedx.org/docs/latest/xml/ | -| XML | Schema | https://cyclonedx.org/schema/bom-1.6.xsd | -| Protobuf | Schema | https://cyclonedx.org/schema/bom-1.6.proto | +| **Format** | **Resource** | **URL** | +|------------|---------------|----------------------------------------------------| +| JSON | Documentation | | +| JSON | Schema | | +| XML | Documentation | | +| XML | Schema | | +| Protobuf | Schema | | CycloneDX relies exclusively on JSON Schema, XML Schema, and protobuf for validation. The entirety of the specification diff --git a/SBOM/en/0x30-Use_Cases.md b/SBOM/en/0x30-Use_Cases.md index c3732891..da8600ef 100644 --- a/SBOM/en/0x30-Use_Cases.md +++ b/SBOM/en/0x30-Use_Cases.md @@ -121,7 +121,7 @@ The following example illustrates component identity in CycloneDX. } ``` -CycloneDX also supports several identifiers specific to hardware devices. Refer to https://cyclonedx.org/capabilities/hbom/ +CycloneDX also supports several identifiers specific to hardware devices. Refer to for more information. Assertion of identity can also be substantiated in the form of evidence, which includes the methods and techniques used diff --git a/SBOM/en/0x40-BOM_Coverage_Maturity_Quality.md b/SBOM/en/0x40-BOM_Coverage_Maturity_Quality.md index b98cf90e..7b3b60f7 100644 --- a/SBOM/en/0x40-BOM_Coverage_Maturity_Quality.md +++ b/SBOM/en/0x40-BOM_Coverage_Maturity_Quality.md @@ -22,17 +22,17 @@ CycloneDX highly encourages organizations to exceed the NTIA minimum elements wh types of data will vary by use case but generally should include: -| **Field** | **CycloneDX Field** | **Description** | -|--------------------------|----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------| -| BOM Lifecycles | bom.metadata.lifecycles[] | The stage in which data in the BOM was captured | -| BOM Generation Tools | bom.metadata.tools[] | The tool(s) used to create the BOM | -| Component Hash | bom.components[].hashes[] | The hash values of the file or package | -| Component License | bom.components[].licenses[] | The license(s) in which the component is released under | -| Component Evidence | bom.components[].evidence[].identity.* | The evidence of identity including the methods, techniques, and confidence of how components were identified | -| Cryptographic Properties | bom.components[].cryptoProperties.* | The properties specific to cryptographic assets detailing the algorithms, keys, protocols, and other cryptographic material | -| External References | bom.components[].externalReferences[] | Locations to advisories, version control and build systems, etc | -| Services | bom.services[].* | A complete inventory of services including endpoint URLs, data classifications, etc which the product and/or individual components rely on | -| Known Unknowns | bom.compositions[].* | Assertions on the completeness of the inventory of components and services, along with the completeness of dependency relationships | +| **Field** | **CycloneDX Field** | **Description** | +|--------------------------|------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------| +| BOM Lifecycles | `bom.metadata.lifecycles[]` | The stage in which data in the BOM was captured | +| BOM Generation Tools | `bom.metadata.tools[]` | The tool(s) used to create the BOM | +| Component Hash | `bom.components[].hashes[]` | The hash values of the file or package | +| Component License | `bom.components[].licenses[]` | The license(s) in which the component is released under | +| Component Evidence | `bom.components[].evidence[].identity.*` | The evidence of identity including the methods, techniques, and confidence of how components were identified | +| Cryptographic Properties | `bom.components[].cryptoProperties.*` | The properties specific to cryptographic assets detailing the algorithms, keys, protocols, and other cryptographic material | +| External References | `bom.components[].externalReferences[]` | Locations to advisories, version control and build systems, etc | +| Services | `bom.services[].*` | A complete inventory of services including endpoint URLs, data classifications, etc which the product and/or individual components rely on | +| Known Unknowns | `bom.compositions[].*` | Assertions on the completeness of the inventory of components and services, along with the completeness of dependency relationships | ## SCVS BOM Maturity Model diff --git a/SBOM/en/0x52-Linking.md b/SBOM/en/0x52-Linking.md index ffb1794b..e5439157 100644 --- a/SBOM/en/0x52-Linking.md +++ b/SBOM/en/0x52-Linking.md @@ -5,15 +5,14 @@ other BOMs. This deep-linking capability is referred to as BOM-Link and is a and compliant with [RFC-8141](https://www.rfc-editor.org/rfc/rfc8141.html). **Syntax**: -```ini -urn:cdx:serialNumber/version#bom-ref +```text +"urn:cdx:" "/" [ "#" ] ``` -**Examples**: -```ini -urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1 -urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA -``` +Where: +- Elements in `""` indicate string literals +- Elements in `<>` indicate fields +- Elements in `[]` indicate optionals | Field | Description | | ------------ | --------------------------------------------------------------------------------- | @@ -21,6 +20,12 @@ urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA | version | The version of the BOM. The default version is `1`. | | bom-ref | The unique identifier of the component, service, or vulnerability within the BOM. | +**Examples**: +```text +urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1 +urn:cdx:f08a6ccd-4dce-4759-bd84-c626675d60a7/1#componentA +``` + There are many use cases that BOM-Link supports. Two common scenarios are: * Reference one BOM from another BOM * Reference a specific component or service in one BOM from another BOM diff --git a/SBOM/en/0x60-Evidence.md b/SBOM/en/0x60-Evidence.md index b1013445..15a53ec8 100644 --- a/SBOM/en/0x60-Evidence.md +++ b/SBOM/en/0x60-Evidence.md @@ -94,7 +94,7 @@ The following example illustrates how different methods can be combined to subst ] } ] - } + } } ] ``` @@ -117,7 +117,7 @@ component identity, and optionally specify evidence of other possible identifier "field": "cpe", "confidence": 0.4, "concludedValue": "cpe:2.3:a:acme-systems:acme-application:1.0.0:*:*:*:*:*:*:*" - } + } ] } ``` diff --git a/SBOM/en/0x80-Extensibility.md b/SBOM/en/0x80-Extensibility.md index 7790a4fc..40f014b7 100644 --- a/SBOM/en/0x80-Extensibility.md +++ b/SBOM/en/0x80-Extensibility.md @@ -48,7 +48,7 @@ prefix the property name and are defined by the organization or project that reg Namespaces are hierarchical and delimited with a `:` and may optionally start with `urn:`. Examples include: -``` +```text cdx:gomod:binary cdx:npm:package:bundled cdx:pipenv:package diff --git a/SBOM/en/0x91-Appendix-B_References.md b/SBOM/en/0x91-Appendix-B_References.md index 7bbe73df..cb037f67 100644 --- a/SBOM/en/0x91-Appendix-B_References.md +++ b/SBOM/en/0x91-Appendix-B_References.md @@ -2,9 +2,9 @@ The following resources may be useful to users and adopters of this standard: -* NTIA Multistakeholder Process on Software Component Transparency, Framing Working Group. (21 October 2021). _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition_. https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf -* NTIA. (12 July 2021). _The Minimum Elements for Software Bill of Materials_. https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf -* The White House. (12 May 2021). _Executive Order on Improving the Nation’s Cybersecurity_. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ +* NTIA Multistakeholder Process on Software Component Transparency, Framing Working Group. (21 October 2021). _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition_. +* NTIA. (12 July 2021). _The Minimum Elements for Software Bill of Materials_. +* The White House. (12 May 2021). _Executive Order on Improving the Nation’s Cybersecurity_. * [SPDX License IDs](https://spdx.dev/ids/) * [SPDX License List](https://spdx.org/licenses/) diff --git a/SaaSBOM/en/0x20-Object-Model.md b/SaaSBOM/en/0x20-Object-Model.md index df8bcd40..b22e48e7 100644 --- a/SaaSBOM/en/0x20-Object-Model.md +++ b/SaaSBOM/en/0x20-Object-Model.md @@ -98,13 +98,13 @@ or industry-specific use cases. ## Serialization Formats CycloneDX can be represented in JSON, XML, and Protocol Buffers (protobuf) and has corresponding schemas for each. -| **Format** | **Resource** | **URL** | -|------------|---------------|--------------------------------------------------| -| JSON | Documentation | https://cyclonedx.org/docs/latest/json/ | -| JSON | Schema | https://cyclonedx.org/schema/bom-1.6.schema.json | -| XML | Documentation | https://cyclonedx.org/docs/latest/xml/ | -| XML | Schema | https://cyclonedx.org/schema/bom-1.6.xsd | -| Protobuf | Schema | https://cyclonedx.org/schema/bom-1.6.proto | +| **Format** | **Resource** | **URL** | +|------------|---------------|----------------------------------------------------| +| JSON | Documentation | | +| JSON | Schema | | +| XML | Documentation | | +| XML | Schema | | +| Protobuf | Schema | | CycloneDX relies exclusively on JSON Schema, XML Schema, and protobuf for validation. The entirety of the specification diff --git a/SaaSBOM/en/0x91-Appendix-B_References.md b/SaaSBOM/en/0x91-Appendix-B_References.md index 1b10fe93..928f156a 100644 --- a/SaaSBOM/en/0x91-Appendix-B_References.md +++ b/SaaSBOM/en/0x91-Appendix-B_References.md @@ -2,9 +2,9 @@ The following resources may be useful to users and adopters of this standard: -* NTIA Multistakeholder Process on Software Component Transparency, Framing Working Group. (21 October 2021). _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition_. https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf -* NTIA. (12 July 2021). _The Minimum Elements for Software Bill of Materials_. https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf -* The White House. (12 May 2021). _Executive Order on Improving the Nation’s Cybersecurity_. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ +* NTIA Multistakeholder Process on Software Component Transparency, Framing Working Group. (21 October 2021). _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition_. +* NTIA. (12 July 2021). _The Minimum Elements for Software Bill of Materials_. +* The White House. (12 May 2021). _Executive Order on Improving the Nation’s Cybersecurity_.
\newpage diff --git a/VDR_VEX/en/0x10-Introduction.md b/VDR_VEX/en/0x10-Introduction.md index bdb709de..407c5667 100644 --- a/VDR_VEX/en/0x10-Introduction.md +++ b/VDR_VEX/en/0x10-Introduction.md @@ -23,13 +23,13 @@ achieved without sacrificing its design philosophy. Some guiding principals infl ## Serialization Formats CycloneDX can be represented in JSON, XML and Protocol Buffers (protobuf) and has corresponding schemas for each. -| **Format** | **Resource** | **URL** | -|------------|---------------|--------------------------------------------------| -| JSON | Documentation | https://cyclonedx.org/docs/latest/json/ | -| JSON | Schema | https://cyclonedx.org/schema/bom-1.4.schema.json | -| XML | Documentation | https://cyclonedx.org/docs/latest/xml/ | -| XML | Schema | https://cyclonedx.org/schema/bom-1.4.xsd | -| Protobuf | Schema | https://cyclonedx.org/schema/bom-1.4.proto | +| **Format** | **Resource** | **URL** | +|------------|---------------|----------------------------------------------------| +| JSON | Documentation | | +| JSON | Schema | | +| XML | Documentation | | +| XML | Schema | | +| Protobuf | Schema | | ### A note on validation diff --git a/VDR_VEX/en/0x20-Object-Model.md b/VDR_VEX/en/0x20-Object-Model.md index cf33b70b..912fad31 100644 --- a/VDR_VEX/en/0x20-Object-Model.md +++ b/VDR_VEX/en/0x20-Object-Model.md @@ -69,6 +69,9 @@ services may also be disclosed using CycloneDX, making it ideal for both VEX and ![Vulnerabilities](../../images/Object-Model/Vulnerabilities.svg) ## Formulation + +!TODO! + Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras et nibh justo. Fusce ornare eros at venenatis dapibus. In dignissim luctus pellentesque. Pellentesque blandit odio lorem, varius hendrerit metus elementum quis. Vestibulum eget dictum urna. Donec lacinia et ipsum non blandit. Praesent arcu risus, feugiat et arcu id, fermentum cursus elit. Fusce nec orci auctor, laoreet turpis in, tincidunt arcu. Ut faucibus nibh sit amet magna pharetra consequat. Fusce eu leo enim. Phasellus ac libero nisl. Nam congue dolor vitae metus tempor euismod. Nam viverra felis eu nulla rhoncus, at rhoncus sem gravida. In tempor libero vel turpis vehicula, non aliquam urna venenatis. Etiam tincidunt est nec bibendum commodo. ![Formulation](../../images/Object-Model/Formulation.svg) @@ -81,6 +84,9 @@ individuals or organizations. Annotations can be independently signed and verifi ![Annotations](../../images/Object-Model/Annotations.svg) ## Data + +!TODO! + Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras et nibh justo. Fusce ornare eros at venenatis dapibus. In dignissim luctus pellentesque. Pellentesque blandit odio lorem, varius hendrerit metus elementum quis. Vestibulum eget dictum urna. Donec lacinia et ipsum non blandit. Praesent arcu risus, feugiat et arcu id, fermentum cursus elit. Fusce nec orci auctor, laoreet turpis in, tincidunt arcu. Ut faucibus nibh sit amet magna pharetra consequat. Fusce eu leo enim. Phasellus ac libero nisl. Nam congue dolor vitae metus tempor euismod. Nam viverra felis eu nulla rhoncus, at rhoncus sem gravida. In tempor libero vel turpis vehicula, non aliquam urna venenatis. Etiam tincidunt est nec bibendum commodo. ![Data](../../images/Object-Model/Data.svg) diff --git a/VDR_VEX/en/0x30-VDR-Overview.md b/VDR_VEX/en/0x30-VDR-Overview.md index 838df284..4d4fa97c 100644 --- a/VDR_VEX/en/0x30-VDR-Overview.md +++ b/VDR_VEX/en/0x30-VDR-Overview.md @@ -41,6 +41,9 @@ CycloneDX can describe previously unknown vulnerabilities against software and h up many use cases that would not otherwise be possible. These will be covered in subsequent sections. ## How CycloneDX Implements VDR + +!TODO! + Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam ipsum sapien, vehicula et turpis varius, ornare consectetur lorem. Nulla finibus tellus in feugiat efficitur. Ut lacinia ultricies diam eget dictum. Maecenas sit amet pretium urna. Curabitur finibus lobortis leo nec facilisis. Nullam et varius nunc, quis vehicula lorem. In blandit pharetra leo tincidunt placerat. Vestibulum gravida molestie velit egestas feugiat. Sed nec ultrices ipsum. Vestibulum sit amet tellus non lectus auctor iaculis.\ ![VDR+VEX-BOM-Cascade.png](images/VDR+VEX-BOM-Cascade.svg) diff --git a/VDR_VEX/en/0x91-Appendix-B_References.md b/VDR_VEX/en/0x91-Appendix-B_References.md index 1b10fe93..928f156a 100644 --- a/VDR_VEX/en/0x91-Appendix-B_References.md +++ b/VDR_VEX/en/0x91-Appendix-B_References.md @@ -2,9 +2,9 @@ The following resources may be useful to users and adopters of this standard: -* NTIA Multistakeholder Process on Software Component Transparency, Framing Working Group. (21 October 2021). _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition_. https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf -* NTIA. (12 July 2021). _The Minimum Elements for Software Bill of Materials_. https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf -* The White House. (12 May 2021). _Executive Order on Improving the Nation’s Cybersecurity_. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ +* NTIA Multistakeholder Process on Software Component Transparency, Framing Working Group. (21 October 2021). _Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Second Edition_. +* NTIA. (12 July 2021). _The Minimum Elements for Software Bill of Materials_. +* The White House. (12 May 2021). _Executive Order on Improving the Nation’s Cybersecurity_.
\newpage