Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Das öffentliche PyPI überprüft, wer ein Paket veröffentlicht hat, nicht, was das Paket leistet.
- SecureChain überprüft und überarbeitet Pakete, bevor sie in Ihre Umgebung gelangen.
- Neu erstellte Artefakte weisen neue Hash-Werte auf, daher müssen die festgesteckten Anforderungsdateien neu generiert werden.
- Nach der Installation werden weiterhin Patches über den gesamten Abhängigkeitsbaum hinweg angewendet.
Public PyPI überprüft, ob Uploads für das Projekt authentifiziert und autorisiert sind, und veröffentlicht für jede hochgeladene Datei einen Hash. Was es jedoch nicht tut, ist, diese Dateien neu zu erstellen, um nachzuweisen, dass ihr Inhalt aus dem Quell-Repository stammt, auf das sie verweisen, oder zu prüfen, ob der Code sicher ausgeführt werden kann. Diese Lücke ist der Grund, warum Nutzer meist nach einer PyPI-Alternative suchen – nach einer Lösung, die nicht nur die Herkunft eines Pakets bewertet, sondern auch dessen Funktionalität.
In diesem Beitrag wird erläutert, wo SecureChain für Python nach der Installation Prüfungen durchführt, die Software neu kompiliert und Patches installiert – und wo diese Abdeckung endet.
Was Public PyPI überprüft und was eine PyPI-Alternative zusätzlich bietet
Wenn „pip“ aus dem öffentlichen PyPI installiert, werden nur wenige Prüfungen durchgeführt, und keine davon berücksichtigt, wie sich ein Paket verhält, sobald es in Ihrer Umgebung installiert ist.
Um eine Version zu veröffentlichen, ist ein authentifiziertes Betreuerkonto erforderlich. Jede hochgeladene Datei erhält einen veröffentlichten Hash, und pip vergleicht den Download mit dem Hash, den der Index übermittelt, wodurch eine beschädigte Übertragung erkannt wird. Dieser Hash wird jedoch zusammen mit der Datei von derselben Quelle übermittelt; er belegt somit lediglich, dass das Artefakt unversehrt angekommen ist, nicht aber, dass jemand dessen Inhalt überprüft hat. Hash-Prüfmodus ist die strengere Variante, denn mit --require-hashes Ein vom Index bereitgestellter Hash kann diese Anforderung nicht erfüllen. Das Artefakt muss mit einem Hash übereinstimmen, den Sie lokal genehmigt haben.
Betreuer, die sich für „Trusted Publishing“ entscheiden, erhalten kurzlebige OIDC-Anmeldedaten anstelle eines statischen API-Tokens, und PyPI kann digitale Bescheinigungen bereitstellen, die ein Artefakt kryptografisch an seine Veröffentlichungsidentität und – mithilfe der SLSA-Provenienz – an seinen Ursprungsort binden. Das sind nützliche Herkunftssignale, doch keines davon belegt, dass das Artefakt selbst harmlos ist. Sobald eine autorisierte Veröffentlichungsberechtigung oder ein Workflow kompromittiert wurde, lässt sich anhand der Authentifizierung allein nicht mehr feststellen, was über diesen Weg gelangt ist, und der Melde- und Quarantäneprozess von PyPI greift in der Regel erst, wenn eine bösartige Version bereits installierbar ist, anstatt Artefakte vor ihrer Veröffentlichung zu überprüfen.
Ein sicherer PyPI-Mirror, der lediglich die Quelle des Paketdownloads umleitet, weist dieselbe Lücke auf. Das ist auch kein Python-spezifisches Problem. Es handelt sich um einen blinden Fleck, den viele Tools zur Lieferkettenüberwachung nie schließen: Ein Paket wird zwar anhand eines Hash-Werts und eines CVE-Feeds überprüft, jedoch nie daraufhin, was es tatsächlich tut, wenn es ausgeführt wird.
Untersuchung vor der Entbindung, nicht danach
SecureChain analysiert den Quellcode eines Pakets, noch bevor es an einen Build-Agenten oder einen Rechner eines Entwicklers übermittelt wird, kennzeichnet verdächtiges Verhalten und blockiert alles, was die Prüfung nicht besteht. Das ist ein anderer Punkt in der Pipeline als der, an dem die meisten Tools ansetzen. Ein Scanner, der eine Abhängigkeit erst erkennt, nachdem sie aufgelöst oder installiert wurde, meldet etwas, das in der Umgebung bereits vorhanden ist. Eine Überprüfung vor der Übermittlung bedeutet, dass ein Paket, das die Prüfung nicht besteht, die Zielumgebung überhaupt nicht erreicht.
Drei Vorfälle aus dem Jahr 2026 zeigen, warum dieser Zeitpunkt entscheidend ist. LiteLLM hat im März einen Credential-Stealer verbreitet nachdem ein manipulierter Trivy-Build in der eigenen CI-Pipeline das PyPI-Token des Projekts preisgegeben hatte. Im Mai, durabletask, das „Durable Task SDK“ von Microsoft, wurde über ein API-Token angegriffen, das aus den Geheimnissen von GitHub Actions entwendet worden war. Und im Juni, Hades ist nun auf PyPI verfügbar mit 37 schädlichen Wheel-Artefakten, die von Orca als 26 Pakete und von Socket als 19 Pakete gezählt wurden. Diese Wheels verwendeten .pth Start-Hooks, die beim Start des Interpreters und nicht erst beim Import ausgelöst werden – derselbe Trick, den eine der bösartigen Versionen von LiteLLM drei Monate zuvor angewandt hatte.
Keiner der drei benötigte einen Fehler in der Anwendung, die das Paket nutzte. Jeder folgte einem autorisierten Veröffentlichungspfad, und die Authentifizierung kann bestätigen, dass ein Pfad autorisiert ist, ohne etwas darüber auszusagen, ob das über diesen Pfad bereitgestellte Artefakt unbedenklich ist. Die gleiche Kampagnenkette lässt sich bis zu Shai-Huluds Verbreitung über npm zurückverfolgen, und genau darum geht es. Dieses Muster soll durch die Überprüfung vor der Bereitstellung aufgedeckt werden, egal in welchem Ökosystem es als Nächstes auftaucht.
Aus dem Quellcode neu kompilieren – und was dabei tatsächlich überprüft wird
Die meisten Python-Pakete werden aus Distributionsartefakten installiert, die PyPI nicht eigenständig neu erstellt, um sie mit dem Quell-Repository abzugleichen, aus dem sie angeblich stammen. Ein Wheel kann einen konsistenten Hashwert aufweisen, sich einwandfrei installieren lassen und dennoch Code enthalten, der im verknüpften Repository nie vorkam, da nichts im Paketsystem ein Wheel dazu zwingt, mit seiner Quelle übereinzustimmen.
SecureChain erstellt Pakete aus verifizierten Quellen in einer kontrollierten Umgebung neu, sodass sich die installierten Komponenten auf diese Quelle zurückverfolgen lassen und nicht auf eine undurchsichtige Binärdatei aus dem Upstream. Was diese Überprüfung genau belegt, hängt von der Art des Pakets ab.
| Art des Artefakts | Enthält | Wiedergabetreue |
|---|---|---|
| Reines Python-Wheel | Quelldateien, keine Kompilierung | Es handelt sich um eine sehr ähnliche Übereinstimmung, obwohl sich die ZIP-Metadaten und Zeitstempel unterscheiden. |
| Wheel mit kompilierten Erweiterungen | Plattformspezifische Binärdateien, die aus C, C++ oder Rust erstellt wurden | Nicht byteweise vergleichbar, da derselbe Quellcode je nach Toolchain unterschiedlich kompiliert werden kann |
| Quellcode-Verteilung | Quellcode sowie Metadaten zu Paketierung und Kompilierung | Das ist der wichtigste Vergleichspunkt, obwohl das Build-Backend Code während des Builds ausführen kann |
Ein reines Python-Wheel enthält Python-Quellcode und generierte Paket-Metadaten, jedoch keine kompilierten Binärdateien. Daher ist der Vergleich einer Neuerstellung mit dem veröffentlichten Wheel größtenteils eine Aufgabe auf Dateiebene. Ein aus C-, C++- oder Rust-Erweiterungen erstelltes Wheel ist eine kompilierte Ausgabe, die an eine bestimmte Toolchain und eine bestimmte Plattform gebunden ist; ein Neu-Build erzeugt daher keine übereinstimmende, sondern eine andere Binärdatei. Das ist eine echte Einschränkung, die für einen erheblichen Teil der von Daten- oder ML-Teams installierten Komponenten gilt. Quellcode-Distributionen liegen dazwischen; sie sind im Alltag zwar weniger verbreitet, legen aber den Quellcode und die Build-Eingaben direkt offen, was bei einem Neu-Build die meisten Möglichkeiten bietet.
Die ehrliche Einschätzung für Python lautet also: Es handelt sich eher um ein abgestuftes als um ein einheitliches System. Stark bei reinem Python, strukturell nützlich für sdists, schwächer bei allem, was kompilierte Erweiterungen enthält. Die Behauptung, eine bytegenaue Rekonstruktion über das gesamte PyPI hinweg sei möglich, würde die Möglichkeiten des Neuaufbaus überbewerten, sobald kompilierte oder umgebungsabhängige Ausgaben ins Spiel kommen.
Wie sich der Wiederaufbau auf Ihre angehefteten Hashes auswirkt
Durch Hash-Pinning wird jede Abhängigkeit auf einen oder mehrere explizit genehmigte Artefakt-Hashes beschränkt.
pip-compile --generate-hashes requirements.in
pip install --require-hashes -r requirements.txtDiese Hashwerte sind an bestimmte Dateien gebunden. Da SecureChain Pakete aus dem Quellcode neu erstellt, anstatt das ursprüngliche Artefakt von PyPI erneut bereitzustellen, ergibt sich bei einem neu erstellten Paket ein anderer Hashwert als der von PyPI veröffentlichte, selbst wenn der zugrunde liegende Quellcode exakt übereinstimmt. Ein Wechsel ist daher mit einem echten Migrationsschritt verbunden, da jeder Pin, der ein von SecureChain neu erstelltes Paket abdeckt, anhand des neuen Index neu generiert werden muss.
Planen Sie dies lieber vor einem Pilotprojekt als währenddessen. Erstellen Sie zunächst die Anforderungsdateien auf Basis des neuen Index in einem einzigen Repository neu, vergewissern Sie sich, dass die Installation erfolgreich verläuft und die Anwendung sich unverändert verhält, und legen Sie dann den Umfang der Einführung anhand der Anzahl der Repositorys und Pipelines fest, die derzeit festgelegte Hashes enthalten. Die Größe dieser Liste – und nicht das Konzept des Hash-Pinning – entscheidet darüber, wie umfangreich die Migration tatsächlich ist.
Eine Index-URL, nicht zwei
Die Einrichtung von Pip bei SecureChain lässt sich auf eine einzige Einstellung reduzieren, und zwar mithilfe des Endpunkts, den SecureChain für Ihr Konto bereitstellt:
pip config set global.index-url https://<your-securechain-endpoint>/simple/Verwenden Sie index-url, nicht extra-index-url. pip hat keine Vorstellung davon, aus welchem Index ein Paket stammen soll. Wenn beide Indizes kompatible Kandidaten für denselben Paketnamen anbieten, wägt pip diese gegeneinander ab und wählt möglicherweise den öffentlichen Kandidaten mit der höheren Version aus – genau darin liegt das Risiko einer Verwechslung der Abhängigkeiten --extra-index-url erzeugt.
Überprüfen Sie, was auf einem CI-Runner tatsächlich konfiguriert ist, anstatt sich blind auf die Dokumentation zu verlassen. PIP_INDEX_URL und PIP_EXTRA_INDEX_URL In der Umgebung festlegen, stillschweigend überschreiben pip.conf, und ein von einem anderen Team übernommenes Basis-Image ist eine häufige Möglichkeit, wie sich so etwas unbemerkt einschleicht.
pip config list
pip config get global.index-urlPatches werden nach der Installation installiert, nicht nur vorab geprüft
Die Überprüfung bezieht sich auf den Zustand eines Pakets zum Zeitpunkt seiner Auslieferung. Der größte Teil des Lebenszyklus einer Abhängigkeit spielt sich erst danach ab, und die spätere Feststellung, dass etwas nicht stimmt, ist eine ganz andere Aufgabe als die Bereitstellung einer gepatchten Version der tatsächlich verwendeten Software.
Ein einziges Paket auf oberster Ebene kann über den Resolver von pip Dutzende transitiver Abhängigkeiten einbinden, von denen die meisten von keinem Teammitglied direkt überprüft wurden und von denen jede einzelne ausführbaren Code und neue Schwachstellen in die Umgebung einschleusen kann. SecureChain wendet dieselben Überprüfungs-, Screening- und Patching-Maßnahmen auf den gesamten Abhängigkeitsgraphen an, nicht nur auf das, was in requirements.txt.
Neue CVEs werden für Pakete bekannt gegeben, die sich bereits in einem Produktionsstack befinden – und zwar nach einem Zeitplan, den niemand kontrollieren kann. Es gibt zahlreiche Tools, die Sie darüber informieren. SecureChain überwacht diese Bekanntgaben und liefert Korrekturen, die auf die bereits festgelegten Versionen abgestimmt sind – genau den Teil, den die Ausgabe von „pip-audit“ und die manuelle Überprüfung von Sicherheitshinweisen auf Ihrem Schreibtisch liegen lassen.
Irgendwann stellt ein Betreuer die Veröffentlichung ein. Das öffentliche PyPI hostet die bestehenden Versionen weiterhin, aber ab diesem Zeitpunkt werden keine neuen Patches mehr bereitgestellt, ganz gleich, welche Probleme später noch auftreten sollten. Der „Endless Lifecycle Support“ von TuxCare unterstützt SecureChain in diesem Zusammenhang, indem er Korrekturen für bereits im Katalog enthaltene Pakete zurückportiert, sodass ein Team sich nicht zwischen einer ungepatchten Abhängigkeit und einer Neuprogrammierung entscheiden muss, die niemand eingeplant hatte.
SecureChain mit Ihrem eigenen Python-Stack abgleichen
Stellen Sie Ihren eigenen Abhängigkeitsbaum zusammen, ermitteln Sie, welcher Anteil davon reines Python ist und welcher aus kompilierten Erweiterungen besteht, und prüfen Sie, in wie vielen Repositorys bereits der Hash-Prüfmodus aktiv ist. Das ist das tatsächliche Ausmaß dessen, was eine Umstellung auf SecureChain für Python für Ihren Stack bedeuten würde – und keine allgemeine Schätzung.
Bei der Bewertung von SecureChain als Sicherheitswerkzeug für Python-Pakete kommt es darauf an, diese Details mit Ihrer eigenen Pipeline abzugleichen – und nicht mit einem Datenblatt. Wenn die hier genannten Lücken mit den Ergebnissen Ihrer letzten Vorfallanalyse übereinstimmen, fordern Sie ein Angebot für SecureChain für Python an und erhalten Sie eine klare Antwort zur Katalogabdeckung für Ihren Abhängigkeitsbaum.
FAQ
Was ist eine Alternative zu PyPI?
Ein Index, der Python-Pakete direkt an Entwickler und Build-Systeme bereitstellt, anstatt auf das öffentliche PyPI zurückzugreifen. Einige Optionen spiegeln Upstream-Pakete lediglich wider oder speichern sie im Cache, während andere zusätzliche Kontrollmechanismen wie eine Überprüfung und Neuerstellung hinzufügen, wodurch Lücken geschlossen werden, die bei einer reinen Spiegelung offen bleiben.
Kann „pip install“ schädlichen Code ausführen?
Ja. Bei der Installation einer Quelldistribution kann während des Kompiliervorgangs des Pakets Code aus dem durch das Paket gesteuerten Build-Backend ausgeführt werden, und ein installiertes Paket kann später beim Import oder über Startmechanismen wie beispielsweise eine ausführbare Datei Code ausführen. .pth Datei, die von den Hades-Wheels missbraucht wurde. SecureChain analysiert den Quellcode eines Pakets vor der Bereitstellung, kennzeichnet verdächtiges Verhalten und blockiert schädliche Pakete, bevor sie in eine Umgebung gelangen.
Stimmt ein neu kompiliertes Paket noch mit seiner Upstream-Quelle überein?
Das hängt von der Art des Pakets ab. Reine Python-Wheels enthalten keine kompilierten Binärdateien, sodass sich eine neu erstellte Version auf Dateiebene ziemlich direkt mit dem veröffentlichten Wheel vergleichen lässt. Wheels mit kompilierten C-, C++- oder Rust-Erweiterungen sind plattformspezifische Build-Ergebnisse, und beim Neuaufbau entsteht eine andere Binärdatei als die ursprüngliche, auch wenn der Quellcode identisch ist.
Führt der Wechsel zu SecureChain dazu, dass meine festgepinnten Hashes nicht mehr funktionieren?
Ja, jedes Paket wird neu kompiliert. SecureChain stellt neu kompilierte Pakete bereit, anstatt das ursprüngliche Artefakt von PyPI erneut bereitzustellen, sodass sich die Hashes von den von PyPI veröffentlichten unterscheiden, selbst wenn der Quellcode übereinstimmt. Die Neuerstellung der festgelegten Anforderungsdateien ist ein wesentlicher Schritt bei der Migration und kein Sonderfall.
Deckt SecureChain auch transitive Abhängigkeiten ab, nicht nur die in der Datei „requirements.txt“ aufgeführten?
Ja. Eine einzige direkte Abhängigkeit kann Dutzende von Paketen mit sich bringen, die niemand direkt überprüft hat, und diese Pakete können ausführbaren Code und Sicherheitslücken in die Umgebung einschleusen. SecureChain führt Überprüfungen, Screenings und Patches über den gesamten Abhängigkeitsgraphen hinweg durch und beschränkt sich nicht nur auf die von einem Team aufgelisteten Pakete der obersten Ebene.
Was passiert, wenn ein Python-Paket das Ende seiner Lebensdauer erreicht?
Gar nichts – und genau das ist das Problem. Das öffentliche PyPI entfernt das Paket weder noch kennzeichnet es als nicht mehr unterstützt, und alte Versionen bleiben in der Regel weiterhin zum Download verfügbar, sofern sie nicht aus einem anderen Grund zurückgezogen oder unter Quarantäne gestellt werden. Was zum Stillstand kommt, ist der Upstream, der keine Sicherheitspatches mehr für das Paket bereitstellt, sobald sich die Betreuer zurückziehen. SecureChain versorgt die im Katalog erfassten Pakete auch über diesen Zeitpunkt hinaus weiterhin mit Patches, sodass das Erreichen des Lebenszyklusendes eines Pakets nicht automatisch bedeutet, dass man weiterhin einem Sicherheitsrisiko ausgesetzt ist oder hastig nach einem Ersatz suchen muss.
