requirements.txt: Kjerneverktøy eller skjult trussel?
Alle Python-prosjekter har det. Det uskyldige utseendet requirements.txt som ligger i roten av repositoriet ditt, filen pip install requirements.txt consumes, er en liste over avhengigheter, ja visst, men hvis du ikke er forsiktig, kan det også være en vidåpen dør for ustabile bygg, sårbare pakker og alvorlige sikkerhetsproblemer.
I kjernen, krav.txt styrer hvilke tredjepartspakker applikasjonen din henter inn. Når du kjører pip installasjon -r krav.txt, Pythons pakkebehandler installerer alle avhengigheter som er oppført. Men her er det overraskende: hvis du ikke fester eksakte versjoner, er du stoler på PyPI å alltid servere en trygg, kompatibel og umodifisert versjon, hver gang. Det er ikke slik moderne AppSec fungerer.
Uten festing kan bygg bryte sammen. Enda verre er det at applikasjonen din ubevisst inntar skadelige pakker. Åpen versjonering (Kolbe >=1.0, for eksempel) eller løse versjonsbegrensninger (django~=3.2) er grobunn for å injisere usikker kode. Dette er grunnen til at riktig administrasjon krav.txt er en sentral sikkerhetsoppgave.
Hvor pip fryser og pip install requirements.txt-fordeling
pip fryse er praktisk, men også farlig når det brukes uten å forstå hva det fanger opp. Utviklere genererer ofte krav.txt ved hjelp av krav til pip frysing.txt, og forventer at den skal låse ned miljøet deres. Men frysing validerer ikke sikkerheten eller opprinnelsen til avhengighetene; den dumper bare alt som er installert for øyeblikket, inkludert transitive og potensielt utdaterte pakker.
Tenk deg nå at en lagkamerat, eller din CI, løper i blinde pip installasjon -r krav.txtHvis den filen inneholder utdaterte, sårbare eller til og med pakker med skrivefeil i squatten, du har nettopp automatisert en sikkerhetshendelse.
Raskt eksempel:
# Developer's freeze output
pip freeze > requirements.txt
boto3==1.24.20
requests==2.27.1
⚠️ Usikkert eksempel, ikke bruk i produksjon
Legg nå dette til i CI-en din pipeline:
- name: Install dependencies
run: pip install -r requirements.txt
Du stoler på at miljøet er reproduserbart, at ingenting har endret seg i PyPI, og at hver avhengighet er fortsatt sikker. Det er en viktig antagelse når man stoler på krav til pip frysing.txt arbeidsflyt.
Ekte AppSec-trusler: Typosquatting og avhengighetsforvirring i requirements.txt
Angripere elsker økosystemer med åpen kildekode. Hvorfor? Fordi utviklere ofte er avhengige av standardinnstillinger og implisitt tillit. Slik slår de til ved hjelp av krav.txt:
- SkrivefeilLaster opp en skadelig pakke med et navn som forespørsler istedenfor forespørslerÉn karakter mindre, og bygget ditt eies.
forespørsler # ⚠️ Illustrativt eksempel, ikke en ekte pakke å installere
- AvhengighetsforvirringHvis den interne pakken din ikke er festet eller har et privat omfang, kan angripere publisere en skadelig versjon til PyPI med samme navn. Hvis CI-en din ikke validerer kilder, installerer du deres pakke i stedet for din.
Begge angrepene utnytter mangel på streng pinning og kildekontroll i krav.txtHvis din sier bare noen interne bibliotek, og du løper pip installasjonskrav.txt i CI kan den hente feil pakke fra feil sted.
Sikringskrav.txt i CI/CD Pipelines med hasher og pinning
Slik herder du krav.txt mot trusler i den virkelige verden:
- Fest nøyaktige versjoner: Bruk alltid == for hver pakke i din krav.txtIngen jokertegn, ingen områder.
- Bruk –krever-hasherDette gjør pip installasjon -r krav.txt bekrefte integriteten til hver nedlastede pakke.
Eksempel:
flask==2.2.5 \
--hash=sha256:<actual_hash_here>
⚠️ Demonstrasjonseksempel, erstatt med ekte hash i faktiske prosjekter
- Isoler byggene dineBygg alltid i rene, minimalistiske beholdere. Stol aldri blindt på basisbildet.
- Bruk en privat PyPI-indeksVert din egen proxy/cache og speil kun klarerte pakker.
Kjør avhengighetsskanningerIntegrer verktøy som pip-revisjon eller bruk SBOM-basert analyse i din pipelines.
Eksempel på GitHub Actions-kodebit:
- name: Secure install
run: pip install --require-hashes -r requirements.txt
⚠️ Lærerikt pipeline for eksempel, tilpass deg miljøet ditt
Streng håndtering av pip installasjon -r krav.txt in CI/CD er en av de enkleste måtene å redusere risikoen ved åpen kildekode.
Reproduserbare bygg: Holder dem stabile på tvers av miljøer
Hvis appen din fungerer lokalt, men mislykkes i staging eller prod, inkonsistente avhengigheter i krav.txt er den vanlige mistenkte. Selv en liten versjonsavvik forårsaker store problemer.
Bruk disse strategiene:
- pip-verktøy: Bruk pip-kompilering å generere krav.txt fra en krav.iDen løser avhengigheter med riktig festing.
- MiljømarkørerFor OS-spesifikke pakker eller Python-versjonsspesifikke avhengigheter, bruk markører som plattformsystem == 'Linux'.
- Docker-hurtigbufringI CI, mellomlagre Docker-lagene dine etter at du har installert avhengigheter fra krav.txt for å redusere variasjonen i byggeprosessen.
Eksempel med pip-verktøy:
# requirements.in
flask
# Compile
pip-compile requirements.in
⚠️ Demonstrasjonseksempel, faktisk produksjon avhenger av miljøet ditt
Utgangen er en fullstendig festet krav.txt.
Verktøy som pip fryse, når det kombineres med pip installasjon -r krav.txt under bygging, krever disiplin og ytterligere sikkerhetstiltak.
Konklusjon: Fastsett kravene dine med selvtillit
Dårlig håndtering krav.txt er ikke bare dårlig praksis; det er en aktiv sikkerhetsrisiko. Løs pinning, ubekreftede installasjoner og blind tillit til åpne registre er hvordan angripere utnytter din CI/CD pipelineDette er ikke teoretiske feil; de utnyttes daglig.
Avhengighetslåsing er mer enn bare beste praksis. Det er din første forsvarslinje mot angrep i forsyningskjeden i Python. Kombiner det med –krever-hasher, byggeisolasjon og reproduserbar verktøy som pip-verktøy, og du får en pipeline det er vanskeligere å inngå kompromisser.
Enten du bruker pip installasjonskrav.txt lokalt eller i CI, må du alltid bekrefte og overvåke hva som legges i byggene dine. Verktøy som Xygeni gi synlighet, håndheving av retningslinjer og automatiserte kontroller som låser ned Python-forsyningskjeden din fra krav til pip frysing.txt hele veien gjennom produksjonen.
