Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate modern sbom formats when releasing etcd #18902

Open
idunbarh opened this issue Nov 16, 2024 · 7 comments
Open

Generate modern sbom formats when releasing etcd #18902

idunbarh opened this issue Nov 16, 2024 · 7 comments
Assignees
Labels
area/security area/tooling priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. type/feature

Comments

@idunbarh
Copy link

idunbarh commented Nov 16, 2024

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 jmhbnz added area/security area/tooling priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Nov 16, 2024
@jmhbnz
Copy link
Member

jmhbnz commented Nov 16, 2024

Hi @idunbarh many thanks for raising this and volunteering. For background we last touched the SBOM process for etcd in #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
Copy link
Member

jmhbnz commented Nov 16, 2024

/retitle Generate modern sbom formats when releasing etcd

@k8s-ci-robot k8s-ci-robot changed the title Software Bill of Materials (SBOMs) included in releases Generation modern sbom formats when releasing etcd Nov 16, 2024
@jmhbnz jmhbnz changed the title Generation modern sbom formats when releasing etcd Generate modern sbom formats when releasing etcd Nov 16, 2024
@ivanvc
Copy link
Member

ivanvc commented Nov 17, 2024

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

@ahrtr
Copy link
Member

ahrtr commented Nov 17, 2024

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:

@idunbarh
Copy link
Author

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
Copy link
Author

@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
Copy link
Member

ahrtr commented Nov 20, 2024

I'll use syft for this implementation.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security area/tooling priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. type/feature
Development

No branches or pull requests

4 participants