[mcc0nnell]

Summary

• generate a CycloneDX 1.7 SBOM for each published source archive (.tar.gz and .tar.zst)
• validate each SBOM root against the archive filename and the existing SHA-256 sidecar
• attest build provenance for both source archives using their exact file digests
• attest each SBOM to the corresponding compressed archive
• publish the SBOMs through the existing release-asset publisher
• stop the Windows artifact workflow from silently replacing existing release assets

No library, format, or build-system behavior changes.

Why

The source-release workflow already does several good things: it creates the archives from the release tag, emits SHA-256 sidecars, and signs the compressed tarballs with the release key. What is missing is a machine-verifiable link from those exact archive bytes back to the GitHub workflow/source identity, plus a machine-readable inventory of what the published archives contain.

This change keeps the existing SHA-256 and PGP evidence and adds GitHub artifact attestations on the exact files that are subsequently uploaded.
The Windows release workflow currently uses gh release upload --clobber. A rerun can therefore replace a published ZIP under the same release asset name.

The new behavior is fail-closed:

• if no asset with that name exists, upload it;
• if an existing asset has the same recorded SHA-256, leave it unchanged;
• if the existing asset has a different digest, refuse to overwrite it;
• if GitHub has no recorded digest for the existing asset, also refuse to overwrite it.

This preserves rerunability without making published artifacts mutable.

SBOM scope

The SBOMs describe the exact compressed source archives rather than a repository checkout. Syft therefore uses the archive filename as the root component name and the archive SHA-256 as its root version.

For the current v1.5.7 release, each archive yielded 36 discovered components and no dependency relationships. This is useful release inventory and artifact identity; it is not intended to claim a complete native transitive dependency graph.

Validation

Tested with the currently published v1.5.7 source archives:

• zstd-1.5.7.tar.gz
  • SHA-256 eb33e51f49a15e023950cd7825ca74a4a2b43db8354825ac24fc1b7ee09e6fa3
  • existing release SHA-256 sidecar verified
  • CycloneDX root version matched the exact archive SHA-256
  • 36 components, 0 dependency relationships
• zstd-1.5.7.tar.zst
  • SHA-256 5b331d961d6989dc21bb03397fc7a2a4d86bc65a14adc5ffbbce050354e30fd2
  • existing release SHA-256 sidecar verified
  • CycloneDX root version matched the exact archive SHA-256
  • 36 components, 0 dependency relationships

Both generated CycloneDX 1.7 documents validate with CycloneDX sbom-utility 0.19.2.

Additional checks:

• actionlint 1.7.12: PASS
• git diff --check: PASS
• Anchore SBOM action pinned to full commit for v0.24.0
• Syft pinned to v1.52.0
• GitHub provenance and generic attestation actions pinned to full commits

[meta-cla]

Hi @mcc0nnell!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!