#sigstore — Public Fediverse posts

«Fix typo»: как в PHP закоммитили бэкдор и почему composer install — это акт доверия

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал». Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено. В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет. Разобрать цепочку поставок ПО

https://habr.com/ru/articles/1048056/

#supply_chain_security #Sigstore #Rekor #Fulcio #SLSA #Composer #Packagist #аттестация_артефактов #github_actions #php

[Перевод] Cilium и защита CI/CD: как опенсорс-проект уровня ядра Kubernetes защищает свою цепочку поставок

Cilium работает в сетевом пути уровня ядра в миллионах Kubernetes-pod'ов: от облачных провайдеров до собственных кластеров банков и телекомов. Если бы кто-то скомпрометировал сборочный пайплайн Cilium, зона поражения была бы сопоставима с инцидентом SolarWinds, но в облачно-нативной экосистеме. Поэтому подход проекта к безопасности CI/CD интересен не только мейнтейнерам других опенсорс-проектов: те же паттерны полезны любой команде, которая собирает прод-артефакты в GitHub Actions. Команда VK Cloud перевела статью с конкретными YAML-конфигами, дизайн-решениями и честным списком того, что у Cilium пока не сделано.

https://habr.com/ru/companies/vk/articles/1040540/

#vk_cloud #github_actions #supply_chain #devsecops #cilium #kubernetes #sigstore #slsa #sbom #безопасность

#SigStore / #PyPI attestations: #PGP is hard! We must invent a new signing scheme that's so much easier on users.

The tools, after I've spent hours *integrating* them into #Gentoo, and getting them working for everything before:
* Verifying google_auth-2.46.0.tar.gz ...
Provenance signed by a Google Cloud account, but no service account provided; use '--gcp-service-account'

Yeah, I'm sure that's *so much simpler* than PGP.

#security

#SigStore / #PyPI attestations: #PGP is hard! We must invent a new signing scheme that's so much easier on users.

The tools, after I've spent hours *integrating* them into #Gentoo, and getting them working for everything before:
* Verifying google_auth-2.46.0.tar.gz ...
Provenance signed by a Google Cloud account, but no service account provided; use '--gcp-service-account'

Yeah, I'm sure that's *so much simpler* than PGP.

#security

For the last couple of weeks, I've been deep diving into container supply chain security.

I built a full GitHub Actions demo pipeline:

• Vulnerability scanning
• SBOM generation
• Keyless signing + attestations
• SLSA build provenance

The highlight: zero long-lived secrets. GitHub Actions uses OIDC to obtain a short-lived certificate, signs the image (and publishes attestations), and records everything in a public transparency log. No keys to rotate or leak.

The post also covers hardened base images (distroless and Docker's new Hardened Images) and how to enforce signatures on the consumer side with Kubernetes admission policies.

Blog + companion repo to fork: https://lnkd.in/gtdNYWW8

#SupplyChainSecurity #SBOM #Sigstore #GitHubActions #DevSecOps #ZeroTrust

For the last couple of weeks, I've been deep diving into container supply chain security.

I built a full GitHub Actions demo pipeline:

• Vulnerability scanning
• SBOM generation
• Keyless signing + attestations
• SLSA build provenance

The highlight: zero long-lived secrets. GitHub Actions uses OIDC to obtain a short-lived certificate, signs the image (and publishes attestations), and records everything in a public transparency log. No keys to rotate or leak.

The post also covers hardened base images (distroless and Docker's new Hardened Images) and how to enforce signatures on the consumer side with Kubernetes admission policies.

Blog + companion repo to fork: https://lnkd.in/gtdNYWW8

#SupplyChainSecurity #SBOM #Sigstore #GitHubActions #DevSecOps #ZeroTrust

OpenSSF-funded improvements to Sigstore’s rekor-monitor are making transparency logs easier to monitor for malicious package releases and identity misuse.

Great work by @trailofbits, with support from the sigstore maintainer community including Hayden Blauzvern and @mihaimaruseac.

🔗 https://openssf.org/blog/2025/12/19/catching-malicious-package-releases-using-a-transparency-log/

#OpenSourceSecurity #sigstore #SupplyChainSecurity

OpenSSF-funded improvements to Sigstore’s rekor-monitor are making transparency logs easier to monitor for malicious package releases and identity misuse.

Great work by @trailofbits, with support from the sigstore maintainer community including Hayden Blauzvern and @mihaimaruseac.

🔗 https://openssf.org/blog/2025/12/19/catching-malicious-package-releases-using-a-transparency-log/

#OpenSourceSecurity #sigstore #SupplyChainSecurity

💡 OpenSSF Project Highlight: Sigstore - A Wax Seal of Security for the Digital Era

❓ Why this matters: the Sigstore project is building a modern, transparent trust layer for open source.

Watch this interview and learn more about #Sigstore: https://youtu.be/m5eTw4x33kU?si=JFY3C81VFjBhNIML

💡 OpenSSF Project Highlight: Sigstore - A Wax Seal of Security for the Digital Era

❓ Why this matters: the Sigstore project is building a modern, transparent trust layer for open source.

Watch this interview and learn more about #Sigstore: https://youtu.be/m5eTw4x33kU?si=JFY3C81VFjBhNIML

🎉 The new #Sigstore Rekor transparency log public dataset is now available on BigQuery!

This dataset makes it easier for researchers to analyze software signing trends & understand how artifacts are signed across the open source ecosystem.

🔗Read: https://openssf.org/blog/2025/10/15/announcing-the-sigstore-transparency-log-research-dataset/

🎉 The new #Sigstore Rekor transparency log public dataset is now available on BigQuery!

This dataset makes it easier for researchers to analyze software signing trends & understand how artifacts are signed across the open source ecosystem.

🔗Read: https://openssf.org/blog/2025/10/15/announcing-the-sigstore-transparency-log-research-dataset/

#gentoo #python #rust

I wanted to never touch #uv in my life

But...

Lo and behold, out of nowhere, #sigstore wants sigstore-models now
And sigstore-models wants uv-build
And uv-build wants uv

God damn

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.

Przygotowałem wstępnie weryfikację autentyczności plików z #PyPI dla #Gentoo.

Wiecie, ten nowy wynalazek, który chroni przed atakami podmieniającymi pliki na PyPI, i upewnia się, że macie do czynienia z oryginalnymi plikami z GitHuba. No bo, jak powszechnie wiadomo, repozytoria na GitHubie i tamtejsze systemy CD są mało prawdopodobnym celem ataków. No i absolutnie nie trzeba się martwić tym, że klucze, repozytoria i te systemy CD są w rękach Microsoftu.

https://github.com/gentoo/gentoo/pull/43549

#bezpieczeństwo #GitHub #Microsoft #Python #SigStore

Przygotowałem wstępnie weryfikację autentyczności plików z #PyPI dla #Gentoo.

Wiecie, ten nowy wynalazek, który chroni przed atakami podmieniającymi pliki na PyPI, i upewnia się, że macie do czynienia z oryginalnymi plikami z GitHuba. No bo, jak powszechnie wiadomo, repozytoria na GitHubie i tamtejsze systemy CD są mało prawdopodobnym celem ataków. No i absolutnie nie trzeba się martwić tym, że klucze, repozytoria i te systemy CD są w rękach Microsoftu.

https://github.com/gentoo/gentoo/pull/43549

#bezpieczeństwo #GitHub #Microsoft #Python #SigStore

I've drafted support for verification of #PyPI provenance for #Gentoo.

You know, the new fancy thing that protects against supply chain attacks on PyPI, and verifies that you're using genuine #GitHub artifacts. Because, you know, GitHub repositories and deployment pipelines are an unlikely attack vector. And you definitely don't need to worry about #Microsoft owning the keys, the repositories and the pipelines at all.

https://github.com/gentoo/gentoo/pull/43549

#security #Python #SigStore

I've drafted support for verification of #PyPI provenance for #Gentoo.

You know, the new fancy thing that protects against supply chain attacks on PyPI, and verifies that you're using genuine #GitHub artifacts. Because, you know, GitHub repositories and deployment pipelines are an unlikely attack vector. And you definitely don't need to worry about #Microsoft owning the keys, the repositories and the pipelines at all.

https://github.com/gentoo/gentoo/pull/43549

#security #Python #SigStore

🚨 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/

🚨 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/

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/

🚀 NEW on We ❤️ Open Source 🚀

Docker is retiring Content Trust. Nigel Douglas explains what’s changing, why Notary is deprecated, and how to prepare with Sigstore or Notation.

https://allthingsopen.org/articles/docker-content-trust-sigstore-vs-notation

#WeLoveOpenSource #Docker #Containers #Sigstore #Notation #FOSS #CloudNative

🚀 NEW on We ❤️ Open Source 🚀

Docker is retiring Content Trust. Nigel Douglas explains what’s changing, why Notary is deprecated, and how to prepare with Sigstore or Notation.

https://allthingsopen.org/articles/docker-content-trust-sigstore-vs-notation

#WeLoveOpenSource #Docker #Containers #Sigstore #Notation #FOSS #CloudNative

🔐 New Case Study: How is Google securing the future of machine learning?

By partnering with #sigstore and the Open Source Security Foundation (OpenSSF), they’ve implemented model signing that makes AI systems more trustworthy by default.

https://openssf.org/blog/2025/07/23/case-study-google-secures-machine-learning-models-with-sigstore/

🔐 New Case Study: How is Google securing the future of machine learning?

By partnering with #sigstore and the Open Source Security Foundation (OpenSSF), they’ve implemented model signing that makes AI systems more trustworthy by default.

https://openssf.org/blog/2025/07/23/case-study-google-secures-machine-learning-models-with-sigstore/

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

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

Python 3.14 beta is now available, and there is no GPG signatures per PEP 751. Please test your verification of Python artifacts using Sigstore :)

#python #gpg #sigstore #security #oss #opensource

https://peps.python.org/pep-0761/

Python 3.14 beta is now available, and there is no GPG signatures per PEP 751. Please test your verification of Python artifacts using Sigstore :)

#python #gpg #sigstore #security #oss #opensource

https://peps.python.org/pep-0761/

📣 Announcing v1.0 of the model-signing project, developed by the #OpenSSF AI/ML WG! This project enables signing + verifying ML models of any size/format using #sigstore, self-signed certs, or key pairs. Read the blog to learn more & get involved: https://openssf.org/blog/2025/04/04/launch-of-model-signing-v1-0-openssf-ai-ml-working-group-secures-the-machine-learning-supply-chain/

📣 Announcing v1.0 of the model-signing project, developed by the #OpenSSF AI/ML WG! This project enables signing + verifying ML models of any size/format using #sigstore, self-signed certs, or key pairs. Read the blog to learn more & get involved: https://openssf.org/blog/2025/04/04/launch-of-model-signing-v1-0-openssf-ai-ml-working-group-secures-the-machine-learning-supply-chain/

Jakiś czas temu zaimplementowałem w #Gentoo wsparcie #SigStore, by móc weryfikować nowe wydania CPythona. Dziś dowiedziałem się, że #PyPI również obsługuje takie "poświadczenia". Tylko jak je weryfikować?

https://blog.sigstore.dev/pypi-attestations-ga/

Ten post sugeruje, że na blogu PyPI znajdę "detale istotne dla użytkowników". No więc zajrzyjmy tam.

https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/

Tylko informacje o publikowaniu i przeglądaniu ich (a sposób wymieniony tam nie jest właściwą odpowiedzią na https://pol.social/@mgorny/114053976252968950), a nie weryfikacji. Szukamy dalej.

https://docs.pypi.org/attestations/

Tylko linki do kilku technicznych specyfikacji, nic przydatnego.

https://docs.pypi.org/attestations/consuming-attestations/

O, tu w końcu jest jakiś przykład. Sprawdźmy podlinkowany projekt.

https://pypi.org/project/pypi-attestations/

> [!WAŻNE] Ta biblioteka stanowi szczegół implementacji wewnątrz referencyjnej implementacji PEP 740. Większość użytkowników nie musi korzystać z niej bezpośrednio; więcej szczegółów w dokumentacji PyPI. [tłum. własne]

Tyle że ten link prowadzi do strony ze specyfikacjami! Jak jeszcze trochę pokopiemy, to możemy znaleźć API, które dostarcza nasze "poświadczenie":

https://docs.pypi.org/api/integrity/

No fajno, tylko co z nim zrobić? Przeskoczmy pół godziny wprzód, które zmarnowałem, próbując go użyć. Pokrótce rzecz biorąc, jedyne co pypi-attestations może zrobić jest pobranie interesującego nas pliku i danych "poświadczenia" *wprost z serwera*, i zweryfikowanie go. Więc trzeba używać dodatkowego narzędzia, które dodatkowo zawsze korzysta z Internetu.

A przynajmniej tak sądzę, bo nie brak wszędzie słów "eksperymentalne", a dokumentacja chyba już gorsza być nie może. No cóż, zgłosiłem prośbę o weryfikację w trybie offline, zobaczymy:

https://github.com/trailofbits/pypi-attestations/issues/95

#Python #bezpieczeństwo

So, a while ago I have implemented #SigStore support in #Gentoo, to be able to verify release artifacts for CPython releases. Today, I've learned that the "attestations" are supported on #PyPI now as well. But how to verify them?

https://blog.sigstore.dev/pypi-attestations-ga/

This post suggests that PyPI blog covers the "user-facing details". So let's check that.

https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/

But that just covers publishing and viewing them (and the way listed here is not the answer to https://social.treehouse.systems/@mgorny/114053976211703393), not verifying. So let's try searching further.

https://docs.pypi.org/attestations/

Okay, this just links to a bunch of specifications, nothing useful for us here.

https://docs.pypi.org/attestations/consuming-attestations/

Okay, this one finally provides a snippet. Let's take a look at the project then.

https://pypi.org/project/pypi-attestations/

> [!IMPORTANT] This library is an implementation detail within the reference implementation of PEP 740. Most users should not need to interact with it directly; see the PyPI documentation for full details.

But that just takes us back to the bunch of specifications! If we dig some more, we find the API needed to get the "provenance" file we need:

https://docs.pypi.org/api/integrity/

Well, that's cool, but what can we do about it? Well, let's skip the half an hour I've wasted trying to do anything about it. Long story short, the only thing you can do is have pypi-attestations fetch both the distribution file and the provenance data *straight from the server*, and verify it directly. So you need an extra tool, and the tool is 100% online.

Or at least I guess so, because it's all full of "experimental" and the documentation is as bad as it could get. Well, filed a bug anyway, hopefully I'll learn more:

https://github.com/trailofbits/pypi-attestations/issues/95

#Python #security

So, a while ago I have implemented #SigStore support in #Gentoo, to be able to verify release artifacts for CPython releases. Today, I've learned that the "attestations" are supported on #PyPI now as well. But how to verify them?

https://blog.sigstore.dev/pypi-attestations-ga/

This post suggests that PyPI blog covers the "user-facing details". So let's check that.

https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/

But that just covers publishing and viewing them (and the way listed here is not the answer to https://social.treehouse.systems/@mgorny/114053976211703393), not verifying. So let's try searching further.

https://docs.pypi.org/attestations/

Okay, this just links to a bunch of specifications, nothing useful for us here.

https://docs.pypi.org/attestations/consuming-attestations/

Okay, this one finally provides a snippet. Let's take a look at the project then.

https://pypi.org/project/pypi-attestations/

> [!IMPORTANT] This library is an implementation detail within the reference implementation of PEP 740. Most users should not need to interact with it directly; see the PyPI documentation for full details.

But that just takes us back to the bunch of specifications! If we dig some more, we find the API needed to get the "provenance" file we need:

https://docs.pypi.org/api/integrity/

Well, that's cool, but what can we do about it? Well, let's skip the half an hour I've wasted trying to do anything about it. Long story short, the only thing you can do is have pypi-attestations fetch both the distribution file and the provenance data *straight from the server*, and verify it directly. So you need an extra tool, and the tool is 100% online.

Or at least I guess so, because it's all full of "experimental" and the documentation is as bad as it could get. Well, filed a bug anyway, hopefully I'll learn more:

https://github.com/trailofbits/pypi-attestations/issues/95

#Python #security

Zagadka na #PyPI: jeden z poniższych projektów używa "zaufanego procesu publikacji" (czyli podpisów elektronicznych #SigStore), a drugi nie. Jesteście w stanie odgadnąć który, i w jaki sposób można to stwierdzić? I owszem, jest to widoczne od razu na pierwszej stronie, nie trzeba nigdzie głębiej wchodzić.

https://pypi.org/project/ansible-keyring/
https://pypi.org/project/sampleproject/

Proszę dawać CW na odpowiedzi, żeby nie psuć innym zabawy. A jeżeli nie potraficie odgadnąć, nie szkodzi — to jeden z najgorszych pomysłów na #interfejs, jakie widziałem.

#Gentoo #Python

A #PyPI riddle: one of the following projects is using trusted publishing (i.e. #SigStore signatures) and the other isn't. Can you tell which one does, and how can you tell? And yes, it's visible immediately on the top project page, you don't have to click anything.

https://pypi.org/project/ansible-keyring/
https://pypi.org/project/sampleproject/

Please CW your answers not to spoil. And if you can't, don't worry — this is one of the most horrible #UI ideas I've ever seen.

#Gentoo #Python #packaging

A #PyPI riddle: one of the following projects is using trusted publishing (i.e. #SigStore signatures) and the other isn't. Can you tell which one does, and how can you tell? And yes, it's visible immediately on the top project page, you don't have to click anything.

https://pypi.org/project/ansible-keyring/
https://pypi.org/project/sampleproject/

Please CW your answers not to spoil. And if you can't, don't worry — this is one of the most horrible #UI ideas I've ever seen.

#Gentoo #Python #packaging

Agreed @todd_a_jacobs.

To head off anticipated objections "but PEP 761 doesn't *mandate* using #GitHub or #Google": Technically true, but there's no open implementation #Python is willing to rely on today.

PEP 761 steps *backward* from open technology (though imperfect) to a closed platform (even more imperfect).

If #SigStore were a good idea, it should not have replaced existing open implementations until it also has reliable open implementations. If that's infeasible, why switch to it?

I’m *trying* to like #Python again, but PEP-761 requires #sigstore. #OpenPGP key management has issues, but this requires trusting #openidconnect from #Google & #Microsoft. Plus there’s a stated design goal of supporting automated signatures from private keys held by #GitHub.

Easier? Probably. Safer? Probably not. Security is about trust and the required certificate authorities haven’t earned mine over the past 20 years. As always, YMMV.

https://peps.python.org/pep-0761/

🚀 Sigstore is making waves in software security! 22 contributors, a 289% increase in commits since 2023, and 62K+ unique GitHub projects signed using Sigstore. 📥 Download the OpenSSF Annual Report to learn more: https://hubs.la/Q0318XDQ0 #Sigstore #OSS #SecurityInnovation

🔥 Microcks 1.11.0 is out! 🚀

It's packed with new features like #API consumer validation, #gRPC headers and error simulation, and advanced @AsyncAPISpec + #ApacheAvro support!

It has been built with a secured software supply chain, including #sigstore signature, SBOM, and provenance attestations everywhere!

👉 https://buff.ly/4gcXznI

#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.

90s: people create releases locally, sign them using #PGP and publish.

2024: people keep their code on #GitHub, use GitHub CI pipeline to create and sign releases, and use #SigStore with GitHub authorizing the signing. And then they gloat how secure and tamper-resistant their packages are.

#security

#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