#sigstore — Public Fediverse posts

I can imagine how mandatory code #signing could be a remedy here. For example, using #Sigstore, that requires authenticating by an identity provider (e.g. GitHub), makes such attacks much harder as the attacker must compromising both #NPM accounts and GitHub.

🚨 The AI wave is here, and with it comes a new cybersecurity battleground.

Discover how open source tools like #Sigstore, and #SLSA-based frameworks can help close these gaps and build more resilient AI systems.

Read the blog and learn how to get involved: https://openssf.org/blog/2025/08/12/securing-ai-the-next-cybersecurity-battleground/

New to OpenSSF or thinking about getting involved? We've got you. 💡

This blog by Ejiro and Sal introduces all our working groups, tools, and projects like #sigstore, #SLSA, and #OpenSSFScorecard.

Start here 👉 https://openssf.org/blog/2025/08/08/from-beginner-to-builder-understanding-openssf-community-and-working-groups/

1/2
Today I was playing with Minisign and Cosign to evaluate whether it’s worth signing some of my OSS software with something other than PGP.

Here’s my verdict: Minisign is promising… Much easier to use than PGP. That simplicity, of course, comes at the cost of giving up a few features.

#OSS #SoftwareSigning #ArtifactSigning #PGP #Minisign #Cosign #Sigstore

I don't suppose that trusting #sigstore to run a centralized CA and transparency logs just to issue short-lived certs for me to generate signatures is much more secure than #PGP signing using my own keys. I'm just increasing the attack surface...

The whole Googlesque philosophy of "trust us; don't be evil" is contrary to my take on information security.

But I'm also open to anyone convincing me otherwise.

#cosign #rekor #flucio

#SigStore rzekomo: ma wiele klientów i jest łatwe w użyciu.

Rzeczywistość:

#Cosign domyślnie używa (starego?) formatu podpisu, którego najwyraźnej klient Pythonowy w ogóle nie obsługuje. Trzeba podawać `--new-bundle-format`, żeby dostać podpisy zgodne z innymi klientami.

Przy weryfikacji też trzeba podawać `--new-format`. W przeciwnym wypadku, otrzymamy zupełnie niejasny komunikat:

Error: bundle does not contain cert for verification, please provide public key

No i oczywiście znaleźć jakiekolwiek informacje jest kosmicznie trudno. Odkryłem, jak to się robi tylko dlatego, że kojarzyłem, że kiedyś na forum Pythona był na ten temat wątek, i ktoś rzucił przykładem, jak weryfikować wydania CPythona za pomocą tego wynalazku.

#SigStore claim: it has multiple clients and it's easy to use.

Reality:

#Cosign defaults to using a bundle format that doesn't seem to be supported by SigStore-python at all. You have to explicitly pass `--new-bundle-format` to create compatible signatures.

You also have to explicitly pass `--new-format` when verifying. Otherwise, Cosign will give you a completely confusing message:

Error: bundle does not contain cert for verification, please provide public key

And of course it's quite hard to find any information on this. I've realized it only because I recalled a SigStore-related thread on discuss.python.org, and a single example of using Cosign to verify CPython signatures was given there.

#Sigstore creator, #Chainguard CEO, #OpenSSF TAC member and Season 1 guest Dan Lorenc returns to the #ITOps Query podcast to discuss the year in #opensource and #cybersecurity. Topics range from #softwaresupplychain management, hardening #containerimages and #SBOMs in limbo to #openproduct companies and business models, including his own company's shift in focus this year. Plus: a look ahead to #SecOps and #AI in 2025. #yearinreview #2024yearinreview

https://www.podbean.com/ew/pb-ivy26-1778bf6

We have Sigstore `cosign` tool in Debian's NEW queue! Please help test #sigstore #cosign https://lists.debian.org/debian-go/2024/12/msg00005.html

Yeah, but then you'd run your own closed instance that wouldn’t be trusted by others and you’re back to square one of identifying which key is trusted. The system works best if everyone trusts Google, Microsoft and Github. I guess you can run your own instance in a closed corporate setting (like a custom CA) but it wouldn’t give any benefits for the wider ecosystem.

That’s how I see it, happy to be corrected by someone more intimately associated with sigstore.

Wondering whether users of #cosign (by #sigstore) and #slsa (slsa-verifier) would have opinions on how to best make use of these verification tools when downloading binaries for use in container images?

I started a StackOverflow discussion here with more details, since I'm new to playing around with these toolchains:

https://stackoverflow.com/beta/discussions/78962951/when-using-tools-like-slsa-verifier-and-cosign-how-do-you-verify-the-verifiers

Signed container images with buildah, podman and cosign via GitHub Actions: https://tim.siosm.fr/blog/2023/12/20/signed-container-images/

Explaining how I signed the Toolbx and Distrobox container images (https://github.com/toolbx-images/images) and the ones in my personal namespace on Quay.io (https://github.com/travier/quay-containerfiles) using cosign.

#GitHub #cosign #sigstore #podman

Securing CICD pipelines with StackRox and Sigstore https://www.opensourcerers.org/2023/10/09/securing-cicd-pipelines-with-stackrox-and-sigstore/
#cosign #sigstore #tekton #Kubernetes #cicd

📌 Dopo il coffee break, sale sul palco Giovanni Galloro, Customer Engineer @ Google

Nell suo talk ci mostrerà esempi pratici di come proteggere la supply chain con #Tekton and #Sigstore

#devsecopsday23 #DevSecOps #DevOps #Cybersecurity #security