Add support for attestations

[stevespringett]

Myself and others in the OWASP community have been thinking about the need for a general purpose attestation format. Many of us have searched for existing format, without much success. Several industry-specific formats, many human readable formats, both no general purpose machine readable formats seem to exist. Having a standardized attestation format is crucial to scale many of the U.S. and world government efforts around SBOM and secure development and operational practices. Fortunately for us, someone in our very own community has started work on this very thing. It's simple, flexible, and prescriptive, just like CycloneDX is.

This ticket is an enhancement request to add BoA (Bill of Attestations) support to the core spec.

CycloneDX v1.5 has already added support for an attestation external reference, so externalizing BoA from the SBOM would already be possible with v1.5. So it should fit in nicely.

[stevespringett]

cc @planetlevel

[johnandersen777]

Related: in-toto/attestation#165

We're exploring alignment across in-toto, DIDs, and Verifiable Credentials as well. Would be great if verification of in-toto and CycloneDX style attestations could be consumed by the Verifiable Credentials ecosystem as well.

Curious to see the POC mentioned :)

Ping @marcelamelara

• References
  • https://github.com/transmute-industries/verifiable-data

[planetlevel]

What are next steps here? OMB-22-18, PCI, OWASP ASVS, CSF, and many other standards/frameworks could be represented in this manner, including custom assurance cases. Can we convene a working group to make sure we have all the use cases identified?

[stevespringett]

A dedicated workgroup for CycloneDX Attestations has been initiated and added to the OWASP Software Supply Chain calendar.

The invite for the Attestations WG is here:
https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N2U1YW40bW02amhmbjA4ODlxdWU3bHJrNTRfMjAyMzA0MDRUMTkwMDAwWiBjXzg4NGRlY2RlNWExNTI5MDJiYjUxYTYyZjg5NTUwZDBmMzc0ODQ4NDUzNGYwOGM2Mzc5MmYyZTY1NGYyYTdlYmNAZw&tmsrc=c_884decde5a152902bb51a62f89550d0f3748484534f08c63792f2e654f2a7ebc%40group.calendar.google.com&scp=ALL

Additionally, a dedicated Slack channel was created as well.

[idunbarh]

Awesome to see! Some of the in-toto maintainers are starting a new project called SBOMit with the intent of tracking attestations for components to support cyclonedx/spdx sboms. It would be worthwhile to comparing notes.

@mnm678 @JustinCappos

[colek42]

Have you seen the in-toto Attestation Framework project? https://github.com/in-toto/attestation

This project currently has maintainers from Google, VMWare, Intel, TestifySec, and Kusari. Would it make sense to combine efforts? Figuring out how to include or reference in-toto attestation from a cycloneDX document would be my goal from the collaboration.

I'll add your meeting to my calendar.

[adityasaky]

I definitely think the in-toto attestations maintainers have incorporated what's described here. We also support cyclonedx documents already as a type of attestation and include semantics for attestations to point out to other ones and so on. cc in-toto/attestation-maintainers (@TomHennen @marcelamelara @pxp928 @joshuagl @mikhailswift)

Would it make sense to combine efforts? Figuring out how to include or reference in-toto attestation from a cycloneDX document would be my goal from the collaboration.

+1!

[marcelamelara]

I've been following along silently so far. I'd like to understand the requirements here and see how in-toto attestations might support/interoperate this. I don't think I can attend the meeting unfortunately, but am available to discuss offline.

[pxp928]

I've been following along silently so far. I'd like to understand the requirements here and see how in-toto attestations might support/interoperate this. I don't think I can attend the meeting unfortunately, but am available to discuss offline.

I can attend the meeting. I am curious to hear the motivations and use cases around this and how we can help.

[stevespringett]

@colek42 regarding referencing in-Toto attestations, I completely agree that CDX should be able to reference them if available. In fact, CDX v1.5 has nearly doubled the types of external references (relationships) it supports, and one of the new types is attestation which could refer to externalized CDX attestations or in-toto attestations, or both.

Most of the new reference types are #189

In general, I see CDX and in-Toto attestations complimenting each other quite well. They both try to solve different things and together could be a powerful combo.

Would love to get your feedback on viability of this approach.

[JustinCappos]

At a glance, this is a near perfect match for what we're trying to do in the SBOMit project, by building on in-toto attestations. To avoid unnecessary NIH-based competition, would it make sense to have someone from your group meet with SBOMit maintainers to discuss the use cases and goals?

This way both sides can either walk away with a better understanding of what makes their efforts unique or we can figure out how to combine efforts to avoid needless duplication...

[stevespringett]

@JustinCappos the readme for SBOMit doesn't state the project goals and the term SBOM in the spec is severely limiting. I really dont know what the project is attempting to do. But our aim has nothing to do with SBOM but since CDX isn't an SBOM standard, rather a BOM standard, it makes sense to support bill of attestation use cases. Does SBOMit have clearly articulated goals?

[JustinCappos]

@JustinCappos the readme for SBOMit doesn't state the project goals and the term SBOM in the spec is severely limiting. I really dont know what the project is attempting to do. But our aim has nothing to do with SBOM but since CDX isn't an SBOM standard, rather a BOM standard, it makes sense to support bill of attestation use cases. Does SBOMit have clearly articulated goals?

We're in the process of moving everything over from a Google Doc we've been collectively working on to the github repos, etc. So, we have them and they will transition over relatively soon.

From what you're saying about BOM vs SBOM, then it seems more likely that in-toto attestation framework more closely meets your needs (as other have stated).

I am curious to understand more about how BOM vs SBOM really changes things for your use cases.

[stevespringett]

The working groups have made a ton of progress over the past few months. The idea is to create a dedicated schema specific to attestations. It will all fall under the CycloneDX umbrella, but will initially not be part of the CycloneDX BOM standard. The goal is to have an independent CycloneDX Attestation standard with support in existing CycloneDX tooling to support it. We may incorporate the attestation standard into the BOM standard in a future release. TBD.

Therefore, moving this out from v1.5 and into its own milestone.

[stevespringett]

The attestation implementation in #348 has been approved by TC54. Thank you everyone for your contributions.