Implement RFC0038: Support for CycloneDX and Syft SBoM in Paketo

[ryanmoran]

RFC

Summary

Buildpacks which directly provide a dependency or buildpacks which install application dependencies will support the generation of SBoM in the format of CycloneDX and Syft. Per CNB RFC#95, the SBoM documents will live at <layer>.bom.<ext>.json, launch.bom.<ext>.json and build.bom.<ext>.json where <ext> will be cdx (CycloneDX) or syft (Syft).

Language Family Adoption

• .NET Core: Implement Paketo RFC 0038: CycloneDX + Syft SBOM dotnet-core#628
• Go: Implement Paketo RFC 0038: CycloneDX + Syft SBOM go#524
• Java
• Node.js: Implement Paketo RFC 0038: CycloneDX + Syft SBOM nodejs#496
• PHP: Implement Paketo RFC 0038: CycloneDX + Syft SBOM php#517
• Python: Implement Paketo RFC 0038: CycloneDX + Syft SBOM python#399
• Ruby: Implement Paketo RFC 0038: CycloneDX + Syft SBOM ruby#759
• Web Servers: Implement RFC0038: SBOM web-servers#45

[fg-j]

As discussed in Paketo slack, we've found that SBOMs are not always reproducible documents. This means that buildpack builds sometimes don't produce reproducible images, if one or more SBOMs have been included in the built image.

• The CycloneDX SBOM generated by Syft contains a metadata.timestamp entry, which is inherently not reproducible. It is an OPTIONAL part of the CycloneDX spec.
• The CycloneDX SBOM generated by Syft also contains a serialNumber, which should be unique "even if the contents of the BOM being generated have not changed over time. The process or tool responsible for creating the BOM should create random UUID's for every BOM generated." The serialNumber is an OPTIONAL part of the CycloneDX spec.

• the SPDX SBOM generated by Syft contains a documentNamespace field, which "shall be unique for the SPDX document including the specific version of the SPDX document." It is REQUIRED in the SPDX spec.
• the SPDX SBOM generated by Syft contains a created field, which is a timestamp used to "[i]dentify when the SPDX document was originally created". It is a REQUIRED part of the SPDX spec.

The upshot of this is that attaching SBOMs is negatively impacting build reproducibility. One mitigation is to exclude the optional irreproducible fields from the CycloneDX SBOM. But since irreproducible fields are required in the SPDX spec, we'll need to remove SPDX support or find some other crafty way to get around the SPDX documents' irreproducibility.

[fg-j]

Next steps:

• Write an RFC about omitting optional non-reproducible CycloneDX fields Amend RFC 0038: Make CycloneDX SBOMs reproducible #220
• Write an RFC about whether to support SPDX in a reproducible way, and how
• Start a conversation with syft about the importance of SBOM reproducibility

[fg-j]

Filed anchore/syft#1100

tl;dr Their response seems to be that SBOM reproducibility is a core characteristic they try to stick by for their JSON schema. However, since they're pre 1.0 on the schema, they caveat that this could change. It seems like reproducibility has been on their radar for a while, though.

[06kellyjac]

I raised the issue of non reproducible fields in CycloneDX but they wanted to keep them as required...

OWASP/Software-Component-Verification-Standard#31

So you'll probably need to fill it with dummy data e.g. 1970-01-01 or "semi-accurate" (as-in not the timestamp they want but a relevant enough/still useful timestamp) values using reproducible data like using SOURCE_DATE_EPOCH

[fg-j]

Thanks for that context, @06kellyjac. I'm a bit confused, since CycloneDX currently marks those non-reproducible fields as optional – but is an OWASP project.

Given that OWASP seems to be of two minds on this, do you think it'd be wiser to a) fill in reproducible data for those CycloneDX fields or b) remove them for now since they're currently optional?

[06kellyjac]

Well it's not even the bureaucracy of the OWASP org that lead to this misalignment. The document was lead by the same person who is the lead/chair on the CycloneDX spec & has developed most of the cyclonedx org's tools and code 😅

https://github.com/OWASP/Software-Component-Verification-Standard/blob/master/OWASP_SCVS-1.0-en.pdf
https://github.com/CycloneDX/cyclonedx-core-java/graphs/contributors
https://cyclonedx.org/about/working-groups/

If they're optional in the spec then I guess we can drop them. Then either the doc will reflect the spec and nothing changes, or the spec will reflect the doc and we'll have to fill it with dummy data as mentioned above

edit: I first thought maybe they're optional because they might be for a higher level of SVCS but it's required for SVCS lvl 1 too

[fg-j]

#220 Has been approved and merged, meaning there's a path forward for reproducible CycloneDX SBOMs. See paketo-buildpacks/packit#367

[ForestEckhardt]

@ryanmoran Is finishing Rust necessary seeing as it is still a Community buildpack?

[ryanmoran]

I don't think so. I can remove it from the list, but I want to leave this issue open until we implement the amendments to this RFC around reproducibility.

[ForestEckhardt]

Is there any reason we should not close?