SBOM pour les projets Python : pip, Poetry et uv pour le CRA

Le Cyber Resilience Act demande à chaque fabricant de tenir une nomenclature des logiciels « dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits » (annexe I, partie II, point 1). Python rend la chose facile quand le projet a un vrai fichier de verrouillage, et difficile quand il n’en a pas. Il cache aussi une seconde couche qu’aucun fichier de verrouillage ne montre : les bibliothèques C compilées dans les wheels que vous installez.

Pour le règlement lui-même, voir Le SBOM pour le Cyber Resilience Act.

Partir d’un fichier de verrouillage

Un SBOM doit dire quelle version de chaque composant le produit contient. Un requirements.txt avec requests>=2.31 dit ce que vous acceptez, pas ce que vous livrez. Fixez tout, dépendances transitives comprises :

Outil	Fichier de verrouillage	Dépendances directes enregistrées dans
uv	`uv.lock`	`pyproject.toml`
Poetry	`poetry.lock`	`pyproject.toml`
Pipenv	`Pipfile.lock`	`Pipfile`
pip-tools	`requirements.txt` produit par `pip-compile`	les commentaires `# via`

Un requirements.txt simple, écrit à la main ou par pip freeze, fixe les versions mais ne distingue pas vos dépendances directes des autres. Or le CRA demande « au moins les dépendances de niveau supérieur » : il faut donc savoir lesquelles ce sont. pip-compile écrit un commentaire # via sous chaque ligne, et les autres outils ci-dessus l’enregistrent.

Produire le SBOM

uv écrit du CycloneDX directement à partir de son fichier de verrouillage (depuis la version 0.9.11, en fonction expérimentale) :

uv export --format cyclonedx1.5 --no-dev --output-file sbom.cdx.json

Pour Poetry, Pipenv, les fichiers de dépendances ou un environnement installé, l’outil cyclonedx-py du projet CycloneDX couvre chaque cas :

cyclonedx-py poetry --no-dev -o sbom.cdx.json
cyclonedx-py pipenv -o sbom.cdx.json
cyclonedx-py requirements requirements.txt -o sbom.cdx.json
cyclonedx-py environment .venv -o sbom.cdx.json

Il écrit du JSON en CycloneDX 1.6 par défaut (--sv choisit une autre version). La forme environment décrit ce qui est installé : c’est le reflet le plus fidèle d’une image de conteneur ou d’un environnement virtuel, à condition que ce soit bien celui que vous livrez.

Ce que le fichier de verrouillage ne montre pas

Le code C et Rust des wheels. Beaucoup de paquets courants livrent des wheels compilées qui embarquent des bibliothèques natives : cryptography lie OpenSSL statiquement, Pillow embarque libjpeg et libpng, NumPy embarque une version d’OpenBLAS. Quand OpenSSL publie une vulnérabilité, la ligne cryptography==44.0.0 de votre fichier de verrouillage ne dit pas au scanner qu’OpenSSL est dedans. La norme PEP 770, acceptée en 2025, donne une place à ces bibliothèques : une wheel peut porter son propre SBOM dans .dist-info/sboms/, et auditwheel (depuis la version 6.5) et maturin en ajoutent un automatiquement, pour les bibliothèques partagées qu’ils copient dans la wheel ; les bibliothèques liées statiquement à partir des sources, comme OpenSSL dans cryptography, peuvent encore manquer. Les outils qui lisent les environnements installés commencent à les prendre en compte. En attendant que le vôtre le fasse, listez à la main les composants natifs de vos plus grosses dépendances, ou vérifiez quelles versions de ces paquets corrigent les failles des bibliothèques qu’ils embarquent.

L’interpréteur. Si vous distribuez Python lui-même, dans une image de conteneur, un installeur ou un exécutable PyInstaller ou Nuitka, la version de CPython est un composant de votre produit, avec ses propres avis de sécurité. Elle a sa place dans le SBOM.

Les extras et les marqueurs. uv.lock et poetry.lock résolvent pour toutes les plateformes et tous les extras. Une dépendance marquée sys_platform == "win32" n’est pas dans votre build Linux. Exportez avec les extras et les groupes que vous livrez vraiment, et gardez en tête qu’un SBOM tiré du fichier de verrouillage peut lister un peu plus que ce que contient le produit.

Les pièges propres à Python

Le nom d’import diffère du nom du paquet. On installe PyYAML et on importe yaml, on installe beautifulsoup4 et on importe bs4. Tout ce qui cherche quels paquets votre code utilise doit en tenir compte.
Les paquets chargés par leur nom. Django charge les moteurs de base de données et les applications à partir de chaînes de settings.py, SQLAlchemy charge les pilotes à partir d’une URL (postgresql+psycopg://), les points d’entrée chargent des extensions. Un paquet jamais importé dans votre code peut quand même s’exécuter.
Les dépendances de build (setuptools, hatchling, maturin) s’exécutent pendant la construction de la wheel mais n’y sont pas. Gardez-les comme composants de build, pas dans la liste du produit.

Du SBOM aux vulnérabilités

pip-audit, de la Python Packaging Authority, compare un fichier de dépendances ou un environnement à la base d’avis de PyPA et à OSV. Pour le CRA, regardez d’abord les vulnérabilités exploitées, qui peuvent déclencher le délai de signalement, et consignez dans une déclaration VEX pourquoi les autres ne touchent pas votre produit, quand c’est le cas.

Ce que fait Provetry

Provetry lit uv.lock, poetry.lock, Pipfile.lock et les requirements.txt aux versions fixées (lignes ==), depuis votre CI ou dans les fichiers que vous envoyez, prend les dépendances directes dans pyproject.toml, Pipfile ou les commentaires de pip-compile, et le dit quand il ne peut pas trancher. Il établit le SBOM de chaque version en CycloneDX, et en SPDX avec les offres payantes, et surveille chaque jour avec les offres payantes et chaque semaine avec l’offre gratuite chaque composant pour les vulnérabilités nouvelles et exploitées. Son étape de CI cherche la preuve qu’un paquet vulnérable n’est jamais importé, en comptant comme utilisés les paquets nommés dans les réglages, les URL et les scripts. Avec les offres Pro et Consultant, il descend jusqu’à la fonction vulnérable pour les paquets PyPI. Chaque résultat est une suggestion accompagnée de sa preuve, que vous acceptez ou non. Si vous livrez une image de conteneur, son SBOM, envoyé à la place des fichiers de verrouillage, montre aussi l’interpréteur et les bibliothèques natives qu’un scanner y voit.