search

CycloneDX / specification

OWASP CycloneDX is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. SBOM, SaaSBOM, HBOM, AI/ML-BOM, CBOM, OBOM, MBOM, VDR, and VEX
https://cyclonedx.org/
Apache License 2.0
359 stars 56 forks source link

Feature suggestion: Adding Sigstore support to the standard #155

Open robertlagrant opened 2 years ago

robertlagrant commented 2 years ago

Sigstore exists to verify whether a deployed dependency was signed by the author. Detecting whether a detected dependency was signed by Sigstore would allow downstream tools such as DependencyTrack to expose to its users their coverage of signed dependencies.

stevespringett commented 2 years ago

CycloneDX supports industry standard enveloped signing formats including XML Signature (xmlsig) and JSON Signature Format (JSF). Any component or nested component assembly can be independently signed and verified. To my knowledge, sigstore does not support these use cases.

For components that are inventoried in the BOM, it would be possible to add support for an external reference to zero or more URLs to external signatures. I think this should be able to support Rekor transparency logs as well as Maven GPG signatures.

Can you verify that a URI to the transparency log would work?

robertlagrant commented 2 years ago

Thanks - great comments. Make sense.

Can you verify that a URI to the transparency log would work?

I am no expert, but that is my impression. I'll do some investigating and report back here.

robertlagrant commented 2 years ago

Small update, from their FAQs:

What can I sign and store?

We started off by targeting generic release artifacts like tarballs, compiled binaries and container images, but our future aim is to explore other formats like jars, and manifest signing like SBOM. We’re also looking to collaborate with package managers and ease the adoption of signing for their communities.

So it's possible the SBOM itself could be signed, as well as individual dependencies.

stevespringett commented 2 years ago

So it's possible the SBOM itself could be signed, as well as individual dependencies.

Correct. What I'm trying to find out is what part of cosign verification can be captured in the CycloneDX spec. I'm still unclear what can be technically done and what makes sense to do.

pdxjohnny commented 1 year ago

I think rekor/trillium can be made to issue receipts (similar to IETF SCITT). Perhaps the receipt or the DID/purl/content address of it is what would be what we add a property for?

znewman01 commented 1 year ago

What I'm trying to find out is what part of cosign verification can be captured in the CycloneDX spec. I'm still unclear what can be technically done and what makes sense to do.

Yeah, that's fair 😄 Backing up, Sigstore does two main things:

  1. Provides a transparency log (Rekor) for signatures. So if you have a traditional cryptographic key pair for the signer, you can submit a signature over an SBOM for inclusion in the transparency log.

    To verify inclusion in the log, you can use one of two mechanisms:

    • Immediately on submission to the log, you'll get back a countersigned receipt. This is a "promise" to include the signature in the log.
    • After the "merge" into the log completes, you can do an online lookup if you have the entry's UUID. This results in (1) a "signed tree head" (a signed log root) and (2) a "lookup proof" that the entry is in the log represented by the signed tree head.

  2. Runs a CA (Fulcio) that issues short-lived (10 minute) certificates for various signing identities (OpenID connect identities, like my Gmail account, or machine identities, like "GitHub Actions running workflow X"). Because the certificates are so short-lived, you need a timestamp on any signatures to demonstrate that they happened during the certificate validity period; Rekor inclusion proofs happen to include a timestamp as well.

So, I'd propose:

This should get you there, and doesn't seem to actually require any changes to the JSF spec. For actual work items, we might need to do the following:

  1. Nail down a method for embedding Rekor information into a JSF signature.
  2. Add JSF support to Rekor (see below).

Both of these should probably happen on the Sigstore end. If this is of interest, please let me know and I can kick that off.

CycloneDX supports industry standard enveloped signing formats including XML Signature (xmlsig) and JSON Signature Format (JSF). Any component or nested component assembly can be independently signed and verified. To my knowledge, sigstore does not support these use cases.

Rekor (Sigstore's transparency log) supports pluggable "types" for signing. So it would be pretty easy to add xmlsig or JSF: https://github.com/sigstore/rekor/tree/main/pkg/types

If that was the main blocker for adoption here, I can fire off a feature request and I bet it'd get some traction.

jordan2175 commented 11 months ago

The ITU-T SG17 has standardized the JSON Signature Scheme. It will be published as X.590 and in the final stages of the publication process. You may want to consider using that as it is an international standard.

jordan2175 commented 9 months ago

The ITU specification for digitally signing JSON data is now freely available. https://www.itu.int/rec/T-REC-X.590-202310-I/en