[FEATURE] RFC 3787 - Phase 1 - SBOM and Build Provenance for wasmCloud Artifacts

[ossfellow]

This issue will track the implementation of the Phase 1 solution, described in RFC #3787. For problem statement and the proposed solution, please refer to the RFC.

[ossfellow]

@brooksmtownsend, please assign to me.

[ossfellow]

Hello @rvolosatovs , @joonas, @brooksmtownsend, In late January, a friend of mine, working in cloud security, pointed out a misunderstanding on my part about Using artifact attestations and reusable workflows to achieve SLSA v1 Build Level 3. The actual requirements are:

• Attestation must be performed in the same job that builds components (binaries, images).
• To achieve level 3, the build + attestation job must be turned into a reusable workflow.

This effectively upended the solution that I had proposed for phase 1 of RFC #3787 (i.e. isolate only the attestation part into a reusable workflow). The solution also contained 2 or 3 errors, but since it's ruled out, I don't want to distract from the core problem by focusing on what they are.

wamCloud has a complicated build system, which is partly due to the complexity of the project/repository, and partly due to blending GitHub workflow features (inputs, outputs, matrix) with Cargo based builds (opaque to workflows and actions), Nix builds, and lack of assumed, or discoverable, package naming conventions for reliable parameterization (e.g. one cannot readily say what binaries build-wasmcloud-bin job will produce).

That means, it requires careful planning, coordination and work to transform the existing build pipeline into one with just a few reusable workflows, which can build binaries (host and providers), OCI images, components, etc.

So, I decided to answer what it means to update the existing build system, to create binary and OCI image build attestations, SBOMs, attestations for SBOM artifacts, and a consumable package, which includes attestation and SBOM artifacts that could be inspected and referenced in user pipelines.

The result is https://github.com/ossfellow/dugout/tree/main/.github. The output of the latest run under the Actions shows what could be expected if the changes are used in wasmcloud build pipeline. Also the Packages shows what additional OCI images will be created.

So, with such references available for examination, I'd like to discuss the customizations, additional GitHub Job steps required for attestation and SBOM generation (plus other enhancements), the advantages and disadvantages of the solution, and some of the observations I've had while creating and testing the attestation and SBOM workflow customizations:

New GitHub Actions

1. artifact-attestation - It's responsible for generating attestations for binary, OCI images, and SBOM documents. it also preserves the build attestation metadata for publishing phase.
2. sbom-generation - it's responsible for generating SBOM (SPDX JSON formatted) for binaries (OCI images will reuse them).
3. publish-sboms-and-attestations - It's responsible for creating a multi-artifact OCI image, with all the generated SBOMs and attestations, and use the preserved metadata to refer attestations and SBOMs to their respective binaries and OCI images.
4. oci-transformations - This isn't directly related to the topic of attestations and SBOM generation, but originally created to transform the Docker Distribution formatted wasmCloud images to OCI format (which was changed in the recent workflow update). It utilizes regctl to enrich images with annotations (discovered in image Labels, or supplied), and can address issue #3957, which is asking for annotations in OCI images.

Please note that there are multiple places that metadata of various artifacts (OCI images, attestation and SBOM artifacts) are printed out, which adds context to the chain events and activities. I recommend looking at the output of different jobs for better understanding of the outcomes.

Steps

wasmCloud, Wash, and Provider Binaries

• Attest the binary build
• Generate SBOM for the binary
• Attest the SBOM

wasmCloud and Wash OCI Images

• Attest the OCI image
• Attest the binary's SBOM, for its OCI image

Provider PARs and Images

• Attest the provider par
• Attest provider image
• Attest provider binary's SBOM, for the provider image

Release

• Publish attestations and SBOMs
• Create release notes for them (for demo)

Pros

• SLSA v1 Build Level 2 compliant
• Meets the needs of most users
• Provides a starting point for future improvements

Cons

• It's fragile as a result of the build pipeline complexity (see above)
• Aforementioned steps further complicate the build jobs
• Adds new actions, which increase pipeline maintenance

Observations

• regctl, which is created and maintained by the OCI spec crew, is a better tool for creation, manipulation, and management of OCI images and artifacts, in build pipelines.
• syft bafflingly proved useless in regards to wasmCloud crates; after experimenting with various tools, I ended up using 3 different tools to cover different languages. In addition, some of constructs used in non-WASM applications (e.g. requirements.txt in Python ecosystem) are not used in wasmCloud components, which renders SBOM tools blind to their dependencies.
• Due to lack of compliance to known specs, provider images could not be enriched and annotated by regctl.

With all this in mind, I'm asking for maintainers' feedback, and signal if we should postpone making changes until a future date (i.e. after moving to a reusable workflow build approach), or if I should go ahead and make changes to the existing workflows, plus any modifications needed.

Please advise.

P.S: I've added a comment to the RFC to alert users that the proposed solution doesn't meet SLSA Level 3 requirements, and should be ignored in favour of what's documented here.

[brooksmtownsend]

Last week in the community call, https://wasmcloud.com/community/2025/04/16/community-meeting/, we discussed taking the learnings from this exploration and putting them aside for now. @ossfellow please feel free to offer some more comments here!