requirements.txt: Kerntool of verborgen bedreiging?
Elk Python-project heeft het. Die onschuldig ogende requirements.txt in de root van uw repository staat het bestand pip install requirements.txt verbruikt, is een lijst met afhankelijkheden, zeker, maar als je niet oppast, kan het ook een open deur zijn voor instabiele builds, kwetsbare pakketten en ernstige beveiligingsproblemen.
In essentie, requirements.txt bepaalt welke pakketten van derden uw applicatie binnenhaalt. Wanneer u pip install -r requirements.txtPython's pakketbeheerder installeert elke vermelde afhankelijkheid. Maar hier is het addertje onder het gras: als je geen exacte versies vastzet, vertrouwen op PyPI Om altijd een veilige, compatibele en ongewijzigde versie te leveren, elke keer weer. Zo werkt moderne AppSec niet.
Zonder vastzetten kunnen builds mislukken. Erger nog, uw applicatie kan onbewust schadelijke pakketten opnemen. Open-ended versiebeheer (Fles >=1.0, bijvoorbeeld) of losse versiebeperkingen (django~=3.2) zijn een vruchtbare bodem voor het injecteren van onveilige code. Daarom is het belangrijk om requirements.txt is een kerntaak op het gebied van beveiliging.
Waar pip freeze en pip install requirements.txt Overzicht
pit bevriezen is handig, maar ook gevaarlijk wanneer het wordt gebruikt zonder te begrijpen wat het vastlegt. Ontwikkelaars genereren vaak requirements.txt gebruik pip freeze-vereisten.txt, in de verwachting dat het hun omgeving zou vergrendelen. Maar freeze valideert de beveiliging of oorsprong van de afhankelijkheden niet; het dumpt gewoon alles wat momenteel geïnstalleerd is, inclusief transitieve en mogelijk verouderde pakketten.
Stel je nu voor dat een teamgenoot, of je CI, blindelings wegrent pip install -r requirements.txtAls dat bestand verouderde, kwetsbare of zelfs typo-squatted pakketten, dan hebt u zojuist een beveiligingsincident geautomatiseerd.
Snel voorbeeld:
# Developer's freeze output pip freeze > requirements.txt boto3==1.24.20 requests==2.27.1 ⚠️ Onveilig voorbeeld, niet gebruiken in productie
Voeg dit nu toe aan uw CI pipeline:
- name: Install dependencies run: pip install -r requirements.txtU vertrouwt erop dat de omgeving reproduceerbaar is, dat er niets is veranderd in PyPI en dat elke afhankelijkheid is nog steeds veilig. Dat is een enorme aanname als je vertrouwt op pip freeze-vereisten.txt workflows.
Echte AppSec-bedreigingen: typosquatting en afhankelijkheidsverwarring in requirements.txt
Aanvallers zijn dol op open-source ecosystemen. Waarom? Omdat ontwikkelaars vaak vertrouwen op standaardinstellingen en impliciet vertrouwen. Zo slaan ze toe met behulp van requirements.txt:
- typosquatting: Een kwaadaardig pakket uploaden met een naam als verzoeken in plaats van verzoeken. Eén personage eraf en je build is van jou.
verzoeken # ⚠️ Illustratief voorbeeld, geen echt pakket om te installeren
- Afhankelijkheid verwarring: Als uw interne pakket niet is vastgezet of niet in een privébereik is geplaatst, kunnen aanvallers een schadelijke versie met dezelfde naam op PyPI publiceren. Als uw CI de bronnen niet valideert, installeert u hun pakket in plaats van het uwe.
Beide aanvallen maken misbruik van een gebrek aan strikte pinning en broncontrole in requirements.txt. Als de jouwe zegt gewoon een interne bibliotheek, en jij rent pip installatievereisten.txt in CI kan het zijn dat het verkeerde pakket van de verkeerde plaats wordt opgehaald.
Beveiliging van requirements.txt in CI/CD Pipelines met hashes en vastzetten
Zo hard je het uit requirements.txt tegen reële bedreigingen:
- Exacte versies vastpinnen: Altijd gebruiken == voor elk pakket in uw requirements.txtGeen jokers, geen bereiken.
- Gebruik –require-hashes: Dit maakt pip install -r requirements.txt de integriteit van elk gedownload pakket verifiëren.
Voorbeeld:
flask==2.2.5 \ --hash=sha256:<actual_hash_here> ⚠️ Demonstratief voorbeeld, vervang door echte hash in echte projecten
- Isoleer uw builds: Bouw altijd in schone, minimale containers. Vertrouw nooit blindelings op de basisimage.
- Gebruik een privé PyPI-index: Host uw eigen proxy/cache en spiegel alleen vertrouwde pakketten.
Afhankelijkheidsscans uitvoeren: Integreer hulpmiddelen zoals pip-audit of gebruik SBOM-gebaseerde analyse in uw pipelines.
Voorbeeld van een GitHub Actions-fragment:
- name: Secure install run: pip install --require-hashes -r requirements.txt⚠️ Educatief pipeline bijvoorbeeld aanpassen aan uw omgeving
Strikte afhandeling van pip install -r requirements.txt in CI/CD is een van de eenvoudigste manieren om het risico van open source te verminderen.
Reproduceerbare builds: ze stabiel houden in verschillende omgevingen
Als uw app lokaal werkt, maar niet werkt in de staging- of productiefase, zijn er inconsistente afhankelijkheden in requirements.txt zijn de gebruikelijke verdachten. Zelfs een kleine versie-drift veroorzaakt grote problemen.
Gebruik deze strategieën:
- pip-tools: Gebruik pip-compileren genereren requirements.txt uit een vereisten.in. Het lost afhankelijkheden op door middel van de juiste pinning.
- Omgevingsmarkers: Gebruik voor OS-specifieke pakketten of Python-versiespecifieke afhankelijkheden markeringen zoals platform_systeem == 'Linux'.
- Docker-caching: In CI cachet u uw Docker-lagen nadat u afhankelijkheden hebt geïnstalleerd van requirements.txt om de bouwvariabiliteit te verminderen.
Voorbeeld met pip-tools:
# requirements.in flask # Compile pip-compile requirements.in ⚠️ Demonstratief voorbeeld, de werkelijke output is afhankelijk van uw omgeving
De output is een volledig vastgezette requirements.txt.
Tools zoals pit bevriezen, in combinatie met pip install -r requirements.txt vereisen tijdens de bouw discipline en extra veiligheidsmaatregelen.
Conclusie: uw vereisten met vertrouwen vastleggen
Mismanagement requirements.txt is niet zomaar een slechte gewoonte; het is een actief beveiligingsrisico. Losse pinning, ongeverifieerde installaties en blind vertrouwen in open registers zijn hoe aanvallers misbruik maken van uw CI/CD pipelineDit zijn geen theoretische tekortkomingen; ze worden dagelijks uitgebuit.
Dependency pinning is meer dan een best practice. Het is je eerste verdedigingslinie tegen supply chain-aanvallen in Python. Combineer dat met –require-hashes, isolatie opbouwen en reproduceerbare gereedschappen zoals pip-tools, en je krijgt een pipeline dat is moeilijker om een compromis te sluiten.
Of je nu gebruikt pip installatievereisten.txt lokaal of in CI, controleer en controleer altijd wat er in uw builds gaat. Hulpmiddelen zoals Xygeni Zorg voor zichtbaarheid, beleidshandhaving en geautomatiseerde controles die uw Python-toeleveringsketen beveiligen tegen pip freeze-vereisten.txt tot en met de productie.
