requirements.txt : outil principal ou menace cachée ?
Chaque projet Python en possède un. Ce symbole d'apparence innocente requirements.txt situé à la racine de votre dépôt, le fichier pip install requirements.txt consomme, est une liste de dépendances, bien sûr, mais si vous ne faites pas attention, cela peut aussi être une porte grande ouverte vers des builds instables, des packages vulnérables et de graves problèmes de sécurité.
En son coeur, conditions.txt contrôle les packages tiers que votre application récupère. Lorsque vous exécutez pip install -r requirements.txtLe gestionnaire de paquets Python installe toutes les dépendances listées. Mais voici le hic : si vous n'épinglez pas les versions exactes, vous risquez faire confiance à PyPI Fournir systématiquement une version sûre, compatible et non modifiée. Ce n'est pas ainsi que fonctionne l'AppSec moderne.
Sans épinglage, les builds peuvent échouer. Pire encore, votre application pourrait ingérer des paquets malveillants sans le savoir. Versionnage ouvert (Flacon >=1.0, par exemple) ou des contraintes de version lâches (django~=3.2) sont un terrain fertile pour l'injection de code non sécurisé. C'est pourquoi une gestion appropriée conditions.txt est une tâche de sécurité essentielle.
Où pip freeze et pip install requirements.txt décomposent
gel de pépin est pratique, mais aussi dangereux lorsqu'il est utilisé sans comprendre ce qu'il capture. Les développeurs génèrent souvent conditions.txt grâce à exigences de gel de pip.txt, espérant verrouiller leur environnement. Mais freeze ne valide ni la sécurité ni l'origine des dépendances ; il se contente de vider tout ce qui est actuellement installé, y compris les paquets transitifs et potentiellement obsolètes.
Imaginez maintenant qu'un coéquipier, ou votre CI, court à l'aveuglette pip install -r requirements.txt. Si ce fichier contient des fichiers obsolètes, vulnérables ou même paquets typo-squattés, vous venez d'automatiser un incident de sécurité.
Exemple rapide :
⚠️ Exemple non sécurisé, ne pas utiliser en production
Ajoutez maintenant ceci à votre CI pipeline:
Vous faites confiance au fait que l'environnement est reproductible, que rien n'a changé dans PyPI et que chaque dépendance est toujours sécurisé. C'est une hypothèse importante lorsqu'on s'appuie sur exigences de gel de pip.txt workflows.
Menaces réelles pour la sécurité des applications : typosquattage et confusion des dépendances dans requirements.txt
Les attaquants adorent les écosystèmes open source. Pourquoi ? Parce que les développeurs s'appuient souvent sur des valeurs par défaut et une confiance implicite. Voici comment ils attaquent en utilisant conditions.txt:
- Typosquattage:Téléchargement d'un package malveillant avec un nom tel que demandes au lieu de demandesUn personnage retiré et votre build est possédé.
demandes # ⚠️ Exemple illustratif, il ne s'agit pas d'un vrai package à installer
- Confusion des dépendancesSi votre package interne n'est pas épinglé ou privé, des attaquants peuvent publier une version malveillante sur PyPI portant le même nom. Si votre CI ne valide pas les sources, vous installerez son package à la place du vôtre.
Les deux attaques exploitent un manque de stricte épinglage et de contrôle des sources dans conditions.txt. Si le vôtre dit juste une-bibliothèque-interne, et tu cours exigences d'installation de pip.txt dans CI, il peut récupérer le mauvais package au mauvais endroit.
Sécurisation du fichier requirements.txt dans CI/CD Pipelines avec hachages et épinglage
Voici comment durcir conditions.txt contre les menaces du monde réel :
- Épingler les versions exactes: Utilisez toujours == pour chaque colis dans votre conditions.txt. Pas de caractères génériques, pas de plages.
- Utilisez le –require-hachages: Cela fait pip install -r requirements.txt vérifier l'intégrité de chaque package téléchargé.
Exemple :
⚠️ Exemple de démonstration, à remplacer par un hachage réel dans des projets réels
- Isolez vos builds: Construisez toujours dans des conteneurs épurés et minimalistes. Ne vous fiez jamais aveuglément à l'image de base.
- Utiliser un index PyPI privé: Hébergez votre propre proxy/cache et mettez en miroir uniquement les packages de confiance.
Exécuter des analyses de dépendances: Intégrer des outils comme audit pip ou de l'utilisation SBOM-analyse basée sur votre pipelines.
Exemple d'extrait d'actions GitHub :
⚠️ Éducatif pipeline exemple, adaptez-vous à votre environnement
Manipulation stricte de pip install -r requirements.txt in CI/CD est l’un des moyens les plus simples de réduire les risques liés à l’open source.
Builds reproductibles : les maintenir stables dans tous les environnements
Si votre application fonctionne localement mais échoue en phase de préparation ou de production, des dépendances incohérentes dans conditions.txt sont les suspects habituels. Même une petite dérive de version peut causer de gros problèmes.
Utilisez ces stratégies :
- pip-outils: Utilisation pip-compile générer conditions.txt d'un exigences.dansIl résout les dépendances avec un épinglage approprié.
- Marqueurs d'environnement: Pour les packages spécifiques au système d'exploitation ou les dépendances spécifiques à la version Python, utilisez des marqueurs tels que système_plateforme == 'Linux'.
- Mise en cache Docker: Dans CI, mettez en cache vos couches Docker après avoir installé les dépendances à partir de conditions.txt pour réduire la variabilité de construction.
Exemple avec pip-tools :
⚠️ Exemple démonstratif, le résultat réel dépend de votre environnement
La sortie est entièrement brochée conditions.txt.
Des outils comme gel de pépin, lorsqu'il est combiné avec pip install -r requirements.txt pendant les constructions, exigez de la discipline et des mesures de protection supplémentaires.
Conclusion : Verrouillez vos exigences en toute confiance
Mauvaise gestion conditions.txt Ce n'est pas seulement une mauvaise pratique ; c'est un risque de sécurité actif. Les attaquants exploitent vos données en utilisant des épingles mal fixées, des installations non vérifiées et une confiance aveugle dans les registres ouverts. CI/CD pipelineIl ne s’agit pas de défauts théoriques ; ils sont exploités quotidiennement.
L'épinglage des dépendances est plus qu'une bonne pratique. C'est votre première ligne de défense contre les attaques de la chaîne d'approvisionnement en Python. Combinez cela avec –require-hachages, construire une isolation et des outils reproductibles comme pip-outils, et vous obtenez un pipeline c'est plus difficile de faire des compromis.
Que vous utilisiez exigences d'installation de pip.txt localement ou en CI, vérifiez et surveillez toujours le contenu de vos builds. Des outils comme Xygéni fournir une visibilité, une application des politiques et des contrôles automatisés qui verrouillent votre chaîne d'approvisionnement Python exigences de gel de pip.txt tout au long de la production.
