Generate modern sbom formats when releasing etcd

[idunbarh]

What would you like to be added?

I'd like to contribute SBOM generation to the release process of this project in both cyclonedx and spdx formats.

I'm part of https://github.com/CISA-SBOM-Community/SBOM-Generation thats building reference implementations for "good" SBOM generation and we thought etcd would be a great candidate.

Why is this needed?

SBOMs are becoming a common part of software releases because they provide insight into what dependencies are used in a project. This allows better vulnerability management.

[jmhbnz]

Hi @idunbarh many thanks for raising this and volunteering. For background we last touched the SBOM process for etcd in https://github.com/etcd-io/etcd/issues/15747 and the process essentially relies on a very antiquated approach to generate the json file https://github.com/etcd-io/etcd/blob/main/bill-of-materials.json.

Adopting new cyclonedx and spdx format support is definitely something I would support. We would need to still retain the old json format sbom process in the stable release branches until the next minor release at least in order to not break any existing processes but I am very keen to forge ahead implementing this in main initially.

cc @ivanvc, @ahrtr, @serathius for any further thoughts on this.

/assign @idunbarh

[jmhbnz]

/retitle Generate modern sbom formats when releasing etcd

[ivanvc]

I think this is a great idea. I spoke with @puerco (sig release) regarding this at KubeCon.

[ahrtr]

Thanks for raising this discussion. The json format of SPDX seems a better choice to me. The only minor concern is that SBOM-Generation is implemented with Python. It means that we have to get python installed in contributors' dev environment to update SBOM.

Alternatives:

• https://github.com/anchore/syft
• generate a tool based on https://github.com/spdx/tools-golang

[idunbarh]

I think this is a great idea. I spoke with @puerco (sig release) regarding this at KubeCon.

@puerco is an awesome reference (and an awesome person too :-D ). We talk regularly around SBOM items. I'll tag him an any PRs.

[idunbarh]

@ahrtr I'll create both SPDX and CycloneDX since its best to let users choose what works best for them. Its simple to do both.

The SBOM-Generation has several different reference implementations that include kubectl with trivy. I'll use syft for this implementation.

[ahrtr]

I'll use syft for this implementation.

Do you mean https://github.com/anchore/syft? If yes, then looks good to me.

[jmhbnz]

Discussed during sig-etcd triage meeting. Checking in, @idunbarh are you still keen to work on this?

[idunbarh]

@jmhbnz Yep! I talked with @puerco about this last week. I'll go ahead and contribute SBOM generation, and then if/when etcd moves to the future improved kubernetes release process a different process can be used.

I'll work on this this weekend.

[jmhbnz]

Discussed during sig-etcd triage meeting, opening this up for other contributors given the time passed and adding help wanted.

[vivekpatani]

@jmhbnz can be assigned to me.

[jmhbnz]

Discussed during sig-etcd triage meeting - Hey @vivekpatani gentle ping are you still working on this one?

[vivekpatani]

@jmhbnz sorry, took a long break, will try to get to it this, week. Sorry about that.

[vivekpatani]

Recommendation

I'm with @idunbarh on this for using Anchore Syft - Go-based, supports both SPDX and CycloneDX, no Python dependency

Plan

Phase 1: Add modern SBOM generation alongside existing

• Create new script scripts/generate-modern-sbom.sh
• Generate both SPDX and CycloneDX formats
• Keep existing bill-of-materials.json process intact

Phase 2: Integrate into release process

• Modify scripts/release.sh to include SBOM generation after build step
• Upload SBOM files to gs://etcd alongside other artifacts
• Include SBOM files in GitHub releases

Phase 3: Testing integration

• Add SBOM validation to scripts/test.sh
• Ensure SBOM files are generated correctly and contain expected dependencies

Projected File Structure

├── bill-of-materials.json          # Keep existing (legacy)
├── bill-of-materials.override.json # Keep existing
├── sbom.spdx.json                 # New SPDX format
├── sbom.cyclonedx.json            # New CycloneDX format
└── scripts/
    ├── generate-modern-sbom.sh    # New script
    └── updatebom.sh               # Keep existing

Script

#!/usr/bin/env bash

set -euo pipefail

VERSION=${1:-"dev"}
OUTPUT_DIR=${2:-"."}

# Install syft if not present
if ! command -v syft >/dev/null; then
    echo "Installing syft..."
    curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
fi

# Generate SPDX format
syft packages . -o spdx-json="${OUTPUT_DIR}/sbom.spdx.json"

# Generate CycloneDX format  
syft packages . -o cyclonedx-json="${OUTPUT_DIR}/sbom.cyclonedx.json"

echo "SBOM files generated successfully"

Feedback would be appreciated: @jmhbnz @ahrtr @ivanvc

[ivanvc]

Running both side to side sounds like a good migration plan. I would suggest putting a POC PR, so we can see this in action. Thanks, @vivekpatani :)

[idunbarh]

@vivekpatani Just a couple of suggestions.

CycloneDX standard recommends using blah.cdx.json instead of blah.cyclonedx.json.

Take a look at tools like sbomasm to edit information like supplier, copyright, and other metadata thats not populated by syft. We have some example github workflows we put together for the OpenSSF community here.

Sorry I dropped the ball on the issue, and @vivekpatani thanks for jumping in! I'm got some more time to help with this. @vivekpatani let me know if you want any support.

[jmhbnz]

Sound like a great plan @vivekpatani - thanks for getting this back underway. Please ping me in the review for the phase one script pr 🙏🏻

[vivekpatani]

@jmhbnz @ivanvc @idunbarh @ahrtr could use your feedback to improve the PR: https://github.com/etcd-io/etcd/pull/20303, thank you.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[vivekpatani]

Hi team, @ivanvc does this still need work? Seems like this was referenced in a couple of more issues, I have cycles this sprint to work on this.

[ivanvc]

@vivekpatani, yes, please. I believe the PR #20303 stalled. It needs to address some comments to move forward.