SBOM für Python-Projekte: pip, Poetry und uv nach dem CRA

Der Cyber Resilience Act verlangt von jedem Hersteller eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene des Produkts erfasst (Anhang I Teil II Nummer 1). Python macht das leicht, wenn das Projekt eine echte Lock-Datei nutzt, und schwer, wenn nicht. Außerdem verbirgt es eine zweite Ebene, die Lock-Dateien nie zeigen: die C-Bibliotheken, die in die installierten Wheels kompiliert sind.

Zur Verordnung selbst siehe SBOM für den Cyber Resilience Act.

Von einer Lock-Datei ausgehen

Eine SBOM muss sagen, welche Version jeder Komponente das Produkt enthält. Eine requirements.txt mit requests>=2.31 sagt, was Sie akzeptieren, nicht was Sie ausliefern. Pinnen Sie alles, einschließlich transitiver Abhängigkeiten:

Werkzeug	Lock-Datei	Direkte Abhängigkeiten stehen in
uv	`uv.lock`	`pyproject.toml`
Poetry	`poetry.lock`	`pyproject.toml`
Pipenv	`Pipfile.lock`	`Pipfile`
pip-tools	`requirements.txt` aus `pip-compile`	den Kommentaren `# via`

Eine von Hand oder mit pip freeze geschriebene requirements.txt pinnt zwar Versionen, kann aber Ihre direkten Abhängigkeiten nicht vom Rest unterscheiden. Der CRA verlangt mindestens die Abhängigkeiten der obersten Ebene, also müssen Sie wissen, welche das sind. pip-compile schreibt unter jede Zeile einen Kommentar # via, und die anderen oben genannten Werkzeuge halten es fest.

Die SBOM erzeugen

uv schreibt CycloneDX direkt aus seiner Lock-Datei (seit Version 0.9.11, als Vorschaufunktion):

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

Für Poetry, Pipenv, Requirements-Dateien oder eine installierte Umgebung deckt cyclonedx-py aus dem CycloneDX-Projekt jeden Fall ab:

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

Es schreibt standardmäßig JSON in CycloneDX 1.6 (--sv wählt eine andere Version). Die Form environment beschreibt, was installiert ist, und gibt damit das genaueste Bild eines gebauten Images oder einer virtuellen Umgebung, aber nur, wenn diese Umgebung die ist, die Sie ausliefern.

Was die Lock-Datei nicht zeigt

C- und Rust-Code in Wheels. Viele beliebte Pakete liefern kompilierte Wheels mit nativen Bibliotheken aus: cryptography linkt OpenSSL statisch, Pillow bündelt libjpeg und libpng, NumPy bündelt einen OpenBLAS-Build. Wenn OpenSSL eine Schwachstelle veröffentlicht, sagt cryptography==44.0.0 in Ihrer Lock-Datei einem Scanner nicht, dass OpenSSL darin steckt. Der Standard PEP 770, 2025 angenommen, gibt diesen Bibliotheken einen Platz: Ein Wheel kann seine eigene SBOM in .dist-info/sboms/ mitbringen, und auditwheel (ab Version 6.5) und maturin fügen sie jetzt automatisch hinzu, für die gemeinsam genutzten Bibliotheken, die sie ins Wheel kopieren; statisch aus dem Quellcode gelinkte Bibliotheken, wie OpenSSL in cryptography, können weiterhin fehlen. Werkzeuge, die installierte Umgebungen lesen, beginnen sie zu erfassen. Solange Ihres das nicht tut, listen Sie die nativen Komponenten Ihrer größten Abhängigkeiten von Hand auf, oder prüfen Sie, welche Releases dieser Pakete Schwachstellen in den eingebetteten Bibliotheken beheben.

Der Interpreter. Wenn Sie Python selbst verteilen, in einem Container-Image, einem Installer oder einem PyInstaller- oder Nuitka-Bundle, ist die CPython-Version eine Komponente Ihres Produkts und hat eigene Sicherheitshinweise. Sie gehört in die SBOM.

Extras und Marker. uv.lock und poetry.lock lösen für jede Plattform und jedes Extra auf. Eine Abhängigkeit mit dem Marker sys_platform == "win32" ist nicht in Ihrem Linux-Build. Exportieren Sie mit den Extras und Gruppen, die Sie tatsächlich ausliefern, und bedenken Sie, dass eine SBOM aus der Lock-Datei etwas mehr aufführen kann, als das Produkt enthält.

Stolperfallen speziell bei Python

Importnamen unterscheiden sich von Paketnamen. Sie installieren PyYAML und importieren yaml, installieren beautifulsoup4 und importieren bs4. Alles, was darüber urteilt, welche Pakete Ihr Code nutzt, muss das berücksichtigen.
Über ihren Namen geladene Pakete. Django lädt Datenbank-Backends und Apps aus Zeichenketten in settings.py, SQLAlchemy lädt Treiber aus einer URL (postgresql+psycopg://), Entry Points laden Plugins. Ein Paket, das in Ihrem Code nie importiert wird, kann trotzdem laufen.
Build-Abhängigkeiten (setuptools, hatchling, maturin) laufen, während das Wheel gebaut wird, stecken aber nicht darin. Halten Sie sie als Build-Komponenten fest, nicht in der Liste des Produkts.

Von der SBOM zu den Schwachstellen

pip-audit von der Python Packaging Authority prüft eine Requirements-Datei oder eine Umgebung gegen die PyPA-Advisory-Datenbank und OSV. Schauen Sie für den CRA zuerst auf die in freier Wildbahn ausgenutzten Schwachstellen, die die Meldeuhr starten können, und halten Sie in einer VEX-Aussage fest, warum die übrigen Ihr Produkt nicht betreffen, wenn das der Fall ist.

Wie Provetry hilft

Provetry liest uv.lock, poetry.lock, Pipfile.lock und gepinnte requirements.txt-Dateien (Zeilen mit ==) aus Ihrer CI oder aus den hochgeladenen Dateien, entnimmt die direkten Abhängigkeiten aus pyproject.toml, Pipfile oder den Kommentaren von pip-compile und sagt es, wenn es sie nicht unterscheiden kann. Es schreibt die SBOM jeder Version in CycloneDX, in den kostenpflichtigen Tarifen auch in SPDX, und überwacht jede Komponente auf neue und ausgenutzte Schwachstellen, täglich in den kostenpflichtigen Tarifen und wöchentlich im kostenlosen. Sein CI-Schritt sucht nach Belegen, dass ein verwundbares Paket nie importiert wird, und zählt Pakete, die in Einstellungen, URLs und Skripten genannt werden, als genutzt. In den Tarifen Pro und Consultant geht er für PyPI-Pakete bis zur verwundbaren Funktion hinunter. Jeder solche Befund ist ein Vorschlag mit seinem Nachweis, den Sie übernehmen oder nicht. Wenn Sie ein Container-Image ausliefern, zeigt dessen SBOM, anstelle der Lock-Dateien hochgeladen, auch den Interpreter und die nativen Bibliotheken, die ein Scanner darin sehen kann.