requirements.txt: Kerntool oder versteckte Bedrohung?
Jedes Python-Projekt hat es. Dieses unschuldig aussehende requirements.txt Die Datei befindet sich im Stammverzeichnis Ihres Repos pip install requirements.txt verbraucht, ist zwar eine Liste von Abhängigkeiten, aber wenn Sie nicht aufpassen, kann dies auch eine weit geöffnete Tür für instabile Builds, anfällige Pakete und ernsthafte Sicherheitsprobleme sein.
Im Kern, requirements.txt steuert, welche Drittanbieterpakete Ihre Anwendung einbindet. Wenn Sie pip install -r Anforderungen.txt, installiert der Paketmanager von Python jede aufgeführte Abhängigkeit. Aber hier ist der Haken: Wenn Sie keine genauen Versionen festlegen, sind Sie PyPI vertrauen um immer eine sichere, kompatible und unveränderte Version bereitzustellen. So funktioniert moderne AppSec nicht.
Ohne Fixierung können Builds beschädigt werden. Schlimmer noch: Ihre Anwendung könnte unbeabsichtigt schädliche Pakete aufnehmen. Offene Versionierung (Flasche >=1.0, zum Beispiel) oder lockere Versionsbeschränkungen (django~=3.2) sind ein fruchtbarer Boden für die Einschleusung von unsicherem Code. Deshalb ist die richtige Verwaltung requirements.txt ist eine zentrale Sicherheitsaufgabe.
Wo pip freeze und pip install requirements.txt Aufschlüsselung
Pip einfrieren ist praktisch, aber auch gefährlich, wenn es verwendet wird, ohne zu verstehen, was es erfasst. Entwickler generieren oft requirements.txt mit automatisierten Pip-Freeze-Anforderungen.txt, in der Erwartung, dass dadurch ihre Umgebung gesperrt wird. Aber „freeze“ überprüft weder die Sicherheit noch den Ursprung der Abhängigkeiten; es löscht lediglich alles, was derzeit installiert ist, einschließlich transitiver und möglicherweise veralteter Pakete.
Stellen Sie sich nun vor, ein Teamkollege oder Ihr CI rennt blind pip install -r Anforderungen.txt. Wenn diese Datei veraltete, anfällige oder sogar Typo-Squatted-Pakete, Sie haben gerade einen Sicherheitsvorfall automatisiert.
Kurzes Beispiel:
# Developer's freeze output
pip freeze > requirements.txt
boto3==1.24.20
requests==2.27.1
⚠️ Unsicheres Beispiel, nicht in der Produktion verwenden
Fügen Sie dies nun zu Ihrem CI hinzu pipeline:
- name: Install dependencies
run: pip install -r requirements.txt
Sie vertrauen darauf, dass die Umgebung reproduzierbar ist, dass sich in PyPI nichts geändert hat und dass jede Abhängigkeit ist immer noch sicher. Das ist eine große Annahme, wenn man sich auf Pip-Freeze-Anforderungen.txt zum Arbeitsablauf
Echte AppSec-Bedrohungen: Typosquatting und Abhängigkeitsverwirrung in requirements.txt
Angreifer lieben Open-Source-Ökosysteme. Warum? Weil Entwickler oft auf Standardeinstellungen und implizites Vertrauen setzen. So schlagen sie zu: requirements.txt:
- Tippfehler: Hochladen eines schädlichen Pakets mit einem Namen wie Anfragen statt Zugriffe. Ein Zeichen weniger und Ihr Build gehört Ihnen.
Anfragen # ⚠️ Illustratives Beispiel, kein echtes zu installierendes Paket
- Abhängigkeitsverwirrung: Wenn Ihr internes Paket nicht fixiert oder privat ist, können Angreifer eine schädliche Version mit demselben Namen auf PyPI veröffentlichen. Wenn Ihr CI die Quellen nicht validiert, installieren Sie deren Paket anstelle Ihres eigenen.
Beide Angriffe nutzen einen Mangel an strikter Fixierung und Quellcodeverwaltung in requirements.txt. Wenn Ihr sagt nur einige interne Bibliothekenund du rennst pip installieren Anforderungen.txt in CI kann es sein, dass das falsche Paket vom falschen Ort abgerufen wird.
Sichern von requirements.txt in CI/CD Pipelines mit Hashes und Pinning
So härten Sie requirements.txt gegen reale Bedrohungen:
- Genaue Versionen anheften: Verwenden Sie immer == für jedes Paket in Ihrem requirements.txt. Keine Platzhalter, keine Bereiche.
- Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, –require-hashes: Dies macht pip install -r Anforderungen.txt Überprüfen Sie die Integrität jedes heruntergeladenen Pakets.
Ejemplo:
flask==2.2.5 \
--hash=sha256:<actual_hash_here>
⚠️ Anschauliches Beispiel, ersetzen Sie es in tatsächlichen Projekten durch echten Hash
- Isolieren Sie Ihre Builds: Bauen Sie immer in sauberen, minimalen Containern. Vertrauen Sie niemals blind dem Basisimage.
- Verwenden Sie einen privaten PyPI-Index: Hosten Sie Ihren eigenen Proxy/Cache und spiegeln Sie nur vertrauenswürdige Pakete.
Führen Sie Abhängigkeitsscans durch: Integrieren Sie Tools wie Pip-Audit oder benutzen SBOM-basierte Analyse in Ihrem pipelines.
Beispiel für einen GitHub Actions-Ausschnitt:
- name: Secure install
run: pip install --require-hashes -r requirements.txt
⚠️ Lehrreich pipeline Beispiel: Passen Sie sich Ihrer Umgebung an
Strenger Umgang mit pip install -r Anforderungen.txt in CI/CD ist eine der einfachsten Möglichkeiten, das Open-Source-Risiko zu reduzieren.
Reproduzierbare Builds: Stabilität in allen Umgebungen gewährleisten
Wenn Ihre App lokal funktioniert, aber in der Staging- oder Produktionsphase fehlschlägt, können inkonsistente Abhängigkeiten in requirements.txt sind die üblichen Verdächtigen. Schon eine kleine Versionsabweichung verursacht große Probleme.
Verwenden Sie diese Strategien:
- Pip-Tools: Benutzen Pip-Kompilierung generieren requirements.txt von einem Anforderungen.in. Es löst Abhängigkeiten durch ordnungsgemäßes Fixieren auf.
- Umgebungsmarkierungen: Verwenden Sie für betriebssystemspezifische Pakete oder Python-versionsspezifische Abhängigkeiten Markierungen wie platform_system == 'Linux'.
- Docker-Caching: Zwischenspeichern Sie in CI Ihre Docker-Ebenen nach der Installation von Abhängigkeiten von requirements.txt um die Build-Variabilität zu reduzieren.
Beispiel mit Pip-Tools:
# requirements.in
flask
# Compile
pip-compile requirements.in
⚠️ Anschauliches Beispiel, die tatsächliche Ausgabe hängt von Ihrer Umgebung ab
Der Ausgang ist ein vollständig gepinnter requirements.txt.
Tools wie Pip einfrieren, in Kombination mit pip install -r Anforderungen.txt während des Baus erfordern Disziplin und zusätzliche Sicherheitsvorkehrungen.
Fazit: Sichere Festlegung Ihrer Anforderungen
Missmanagement requirements.txt ist nicht nur eine schlechte Praxis; es ist ein aktives Sicherheitsrisiko. Lose Pinning, ungeprüfte Installationen und blindes Vertrauen in offene Register sind, wie Angreifer Ihre CI/CD pipeline. Dies sind keine theoretischen Mängel; sie werden täglich ausgenutzt.
Dependency Pinning ist mehr als nur eine bewährte Methode. Es ist Ihre erste Verteidigungslinie gegen Supply-Chain-Angriffe in Python. Kombinieren Sie dies mit –require-hashes, Build-Isolierung und reproduzierbare Werkzeuge wie Pip-Tools, und du bekommst ein pipeline da ist es schwieriger, einen Kompromiss zu finden.
Ob Sie verwenden pip installieren Anforderungen.txt Überprüfen und überwachen Sie lokal oder in CI immer, was in Ihre Builds einfließt. Tools wie Xygeni bieten Transparenz, Richtliniendurchsetzung und automatisierte Prüfungen, die Ihre Python-Lieferkette absichern von Pip-Freeze-Anforderungen.txt während der gesamten Produktion.
