-
Notifications
You must be signed in to change notification settings - Fork 502
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
sign SBOMs through cosign tool right after generated it through bom tool #2286
Comments
Great idea! I just added thoughts to anchore/syft#510 for what our first iteration could look like, and I'm curious what choices folks think would make sense here in the One part that I'll highlight: After beginning the implementation in Syft, I can tell that this kind of integration of signing/attesting will get much easier once it can leverage the work described in sigstore/cosign#844 for updating the lib API. |
Cc @mattmoor and @dekkagaijin |
The initial draft of the sining KEP is proposed in kubernetes/enhancements#3061 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
@puerco, I can tackle this one if you want me to do so in bom CLI? |
1. cosign as a library Using cosign as a library would bring a bunch of transitive dependencies due to large
2. cosign as a binary On the other hand, the concern here is, calling cosign binary right after generation of SBOM, leads to a slight time window in which it could have tampered. I'm agreeing with @nadgowdas, as he said: "signing should be inherent to the SBOM generation process." I'm confused on which path should we follow here. Some help needed here to proceed on this issue so let me cc'ing @puerco. We (@developer-guy) want to get into it! Footnotes |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
Signing Release Artifacts KEP is in Beta status now. Status for beta is "Standard Kubernetes release artifacts (binaries, container images, etc.) are signed." this means that we are signing SBOM now. Here is a discussion #2618 on vanilla cosign or krel sign by @puerco about it. Building signing into krel was the final decision. It was included into #2742. Maybe @cpanato, @puerco or @saschagrunert can confirm this is done now, from what I can interpret. If I understand it it correctly it done only not by using cosign directly but by implementing it close to generation inside krel. |
/remove-lifecycle rotten |
Hey folks, Any update on this issue, we (in Cluster API + possibly it's providers) also interested in this and would be great to see it happen. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/lifecycle frozen |
What would you like to be added:
We talked about a bit of generating/signing process of SBOMs on the
sigstore
Slack channel. In this talk @SantiagoTorres and @nadgowdas made a really valuable comment:👉 https://sigstore.slack.com/archives/C01D0PA9QKF/p1632149577045600
There is a tool called Syft created by the Anchore team. They also started to work for the direct signing of SBOMs right after generating them. Thanks to @luhring
👉 anchore/syft#510
So, I'm proposing the same one for the
bom
CLI, we can use cosign as a library to sign SBOM documents right after generated them through thebom
CLI because cosign has support for storing SBOMs on OCI Registry and also signing them.cc: @Dentrax @dlorenc @erkanzileli
The text was updated successfully, but these errors were encountered: