Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBOMit Phase I Settlement #24

Open
yzhang71 opened this issue Jan 24, 2024 · 2 comments
Open

SBOMit Phase I Settlement #24

yzhang71 opened this issue Jan 24, 2024 · 2 comments

Comments

@yzhang71
Copy link
Contributor

SBOMit Phase I (lightweight, transparent to adopters):

The initial phase of SBOMit adoption is designed to be a streamlined process, involving minimal changes to existing SBOM generation tools used by adopters.

This phase comprises two pivotal actions:

  1. In-toto Attestation for SBOM Generation: The SBOM generation tool creates an in-toto attestation, a form of metadata that provides evidence of the SBOM generation process. This attestation, though not extensive, serves as preliminary proof that the SBOM was generated correctly. This step is crucial for establishing a foundation of trust in the SBOM's accuracy and integrity.
  2. Linking In-toto Attestations to the SBOM: The second action involves embedding all available in-toto attestations and relevant metadata directly into the SBOM. This integration ensures that the complete set of metadata describing the software supply chain is readily accessible and transparent. However, it's important to note that at this stage, the scope of the metadata is somewhat limited, primarily encompassing the SBOM tool itself.

Tooling Provider: Protobomit

"Protobomit" is a command-line tool specifically designed to augment the SBOMit initiative. Its functionalities are aligned with the objectives of SBOMit Phase I and extend beyond:

  • SBOM Generation with Attestations: Protobomit enables the creation of new SBOMs, integrated with in-toto attestations. This feature is pivotal for ensuring that the SBOMs not only list software components but also carry verifiable metadata about their generation process.
  • Provenance Verification: The tool offers capabilities to verify the provenance of SBOMs. This step is essential in authenticating the source and process of SBOM creation, thereby bolstering trust in the SBOM's reliability.
  • Adding In-toto Attestations: Protobomit facilitates the addition of in-toto attestations as external references within SBOMs. This enhancement enriches the SBOM with a layer of metadata that speaks to the integrity of the software supply chain.
  • Support for Key SBOM Formats: Recognizing the diverse ecosystem of SBOM formats, Protobomit supports both CycloneDX and SPDX formats. Protobom, the library that offers this functionality, is also an OpenSSF project. This versatility ensures wider applicability and integration with different toolchains and systems.

Optimal Placement of SBOMit Phase I Information in Different SBOM Formats

CycloneDX:

External References Field:

Pros:

  1. Clarity and Traceability: Linking in-toto attestations in "External References" provides clear traceability. For example, a component's build process can be directly linked to its attestation, making verification straightforward.
  2. Maintaining SBOM Readability: Keeping attestations as external references helps maintain the readability and simplicity of the SBOM itself. The SBOM won’t be cluttered with extensive attestation data.
  3. Flexibility: This method offers flexibility in managing attestations. Users can update or modify attestations without altering the SBOM.

Cons:

  1. Dependency on External Resources: Relying on external links means the SBOM’s completeness is contingent on the availability of these external resources. If a link breaks, the attestation is lost.
  2. Additional Verification Steps: Users must take an extra step to verify attestations, as they are not directly embedded in the SBOM. This might complicate the verification process.
  3. Security Risks: External links could be more susceptible to tampering or redirection, posing potential security risks.
  4. Access Issues: The external attestations may not be reachable. If an SBOM relies on URLs for important verification data, users in an air-gapped environment can't access this information.
  5. Integrity and Security: In secure environments, fetching data from external sources can be a security risk. The inability to access external references due to security policies could render parts of the SBOM less useful.

Custom Properties Field:

Pros:

  1. Embedded Information: Attestations are directly embedded in the SBOM, ensuring all relevant data is contained within a single document. This is beneficial in secure or air-gapped environments where external access is limited.
  2. Security and Integrity: Direct inclusion enhances the security and integrity of the SBOM by reducing reliance on external sources, which can be crucial in sensitive environments.

Cons:

  1. SBOM Size: Embedding in-toto attestations can significantly increase the size of the SBOM, potentially making it more cumbersome to handle or process.
  2. Complexity: Managing and parsing the SBOM becomes more complex with additional embedded data, which may require more sophisticated tooling or processing capabilities.
  3. Update Challenges: Updating embedded attestations can be more challenging, requiring modifications to the entire SBOM rather than just changing an external reference.

In Summary:

The SBOMit committee members have unanimously agreed in meeting to store in-toto attestations in the "Custom Properties" field of CycloneDX offers several advantages, particularly in contexts where security, integrity, and direct access to data are paramount. Embedding attestations directly within the SBOM ensures that all relevant data is self-contained, crucial in secure or air-gapped environments. This method enhances the overall security and integrity of the SBOM by reducing dependency on external sources. While embedding attestations increases the SBOM's size and may add complexity to its management, the benefits of having a comprehensive, self-contained, and secure record of attestations outweigh these concerns. Opting not to use the "External References" field is primarily due to challenges in dependency on external resources, security risks, and access issues in restricted environments.

SPDX:

External References Field:

Pros:

  1. Clarity and Traceability: Linking in-toto attestations in "External References" provides clear traceability. For example, a component's build process can be directly linked to its attestation, making verification straightforward.
  2. Maintaining SBOM Readability: Keeping attestations as external references helps maintain the readability and simplicity of the SBOM itself. The SBOM won’t be cluttered with extensive attestation data.
  3. Flexibility: This method offers flexibility in managing attestations. Users can update or modify attestations without altering the SBOM.

Cons:

  1. Dependency on External Resources: Relying on external links means the SBOM’s completeness is contingent on the availability of these external resources. If a link breaks, the attestation is lost.
  2. Additional Verification Steps: Users must take an extra step to verify attestations, as they are not directly embedded in the SBOM. This might complicate the verification process.
  3. Security Risks: External links could be more susceptible to tampering or redirection, posing potential security risks.
  4. Access Issues: The external attestations may not be reachable. If an SBOM relies on URLs for important verification data, users in an air-gapped environment can't access this information.
  5. Integrity and Security: In secure environments, fetching data from external sources can be a security risk. The inability to access external references due to security policies could render parts of the SBOM less useful.

Annotation Field:

Pros:

  1. Direct Association: Embedding allows each attestation to be directly associated with its relevant component, enhancing clarity.
  2. Security Verification: Provides immediate, built-in verification details within the SBOM, crucial for security audits.

Cons:

  1. Space Constraints: The "Annotation" field might be too restrictive for detailed attestations, limiting the amount of information that can be embedded.
  2. Complexity for User: For those using the SBOM, extracting and utilizing embedded attestation data from annotations might require additional parsing capabilities.

In Summary:

The SBOMit committee members have unanimously agreed in meeting to store in-toto attestations in the "Annotation" field of SPDX offers distinct advantages. This method allows for direct association of attestations with relevant software components. Embedding attestations in the SBOM provides immediate, built-in verification details, crucial for security audits. Concerns about space constraints and added complexity for users are outweighed by the benefits of having a tightly integrated SBOM. Opting not to use "External References" is due to the reliance on external resources and associated security risks, especially in restricted environments.

@stevespringett
Copy link

With CycloneDX, there is a third option, which also uses external references.

In CDX, external references are only external to the object they describe, not necessarily the BOM. Therefore, in CDX, external references are also how relationships are formed. Every external reference type in CDX is also a relationship type. This is contrary to SPDX where they are different things. In CDX, they are one in the same.

Example code (haven't validated this):

{
  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "application",
      "name": "My component",
      "externalReferences": [
        {
          "type": "attestation",
          "url": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1#my-in-toto-attestation"
        }
      ]
    },
    {
      "bom-ref": "my-in-toto-attestation"
      "type": "data",
      "name": "Attestation data"
      "data": [
        {
          "type": "dataset",
          "contents": {
            "attachment": {
              "contentType": "application/vnd.in-toto+json",
              "encoding": "base64",
              "content": "eyAiJGNvbW1lbnQiOiAiaW4tdG90byBhdHRlc2F0aW9uIGRhdGEgZ29lcyBoZXJlIiB9"
            }
          }
        }
      ]
    },
  ]
}

Refer to:

@idunbarh
Copy link
Collaborator

Good feedback @stevespringett :-) What you outline definitely something we discussed, but decided to defer to "Phase 2" of SBOMit, when there maybe a comparable capability in SPDX too.

While using CycloneDX properties and SPDX annotations is not ideal, its something we could execute on today when we also work with the SPDX community to incorporate changes into SPDX 3.0.

As we talk about the future of SBOMit for "Phase 2", we should also talk about using the new attestation capabilities in CycloneDX 1.6. This might be an opportunity to have the in-toto attestations used by SBOMit stored as evidence in CDX 1.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants