Open developer-guy opened 2 years ago
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 bom
tool.
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 https://github.com/kubernetes/enhancements/pull/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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
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 go.mod
file. ^1 It might eventually result in larger size of binaries. @spiffcs implemented cosign in Syft ^2 and binary size increased ~40MB. The concern here is:
Large dependency trees lead to larger built binaries (see above), larger attack surfaces, longer and more fragile builds, and (most interesting to me personally as a maintainer!) more toil for maintainers to update dependencies and sift through security alerts for those vulnerabilities. - @imjasonh
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!
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
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 https://github.com/kubernetes/release/issues/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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
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
👉 https://github.com/anchore/syft/issues/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