Messbarkeit und Phantom-Abhängigkeiten

Python-Pakete sind besonders betroffen vom „Phantom-Abhängigkeits“-Problem, bei dem Softwarekomponenten, die nicht in Python geschrieben sind, aus vielen Gründen in Python-Paketen enthalten sind, wie z. B. einfache Installation und Kompatibilität mit Standards

• Python bedient wissenschaftliche, Daten-, Web- und Machine-Learning-Anwendungsfälle, die kompilierte oder Nicht-Python-Sprachen wie Rust, C, C++, Fortran, JavaScript und andere verwenden.
• Das Python-Wheel-Format wird von Benutzern aufgrund der einfachen Installation bevorzugt. Während des Installationsschritts wird kein Code ausgeführt, nur das Archiv wird extrahiert.
• Das Python-Wheel-Format erfordert das Bündeln von gemeinsam genutzten kompilierten Bibliotheken ohne eine Methode zur Kodierung von Metadaten über diese Bibliotheken.
• Pakete im Zusammenhang mit Python-Packaging müssen manchmal das „Bootstrapping“-Problem lösen und enthalten daher reine Python-Projekte in ihrem Quellcode.

Diese Softwarekomponenten können nicht mit Python-Paket-Metadaten beschrieben werden und werden daher wahrscheinlich von Software-Kompositionsanalyse-Software (SCA) übersehen, was bedeutet, dass anfällige Softwarekomponenten möglicherweise nicht korrekt gemeldet werden.

Zum Beispiel enthält das Python-Paket Pillow 16 Shared-Object-Bibliotheken im Wheel, die von auditwheel als Teil des Builds gebündelt wurden. Keine dieser Shared-Object-Bibliotheken wird erkannt, wenn gängige SCA-Tools wie Syft und Grype verwendet werden. Wenn ein SBOM-Dokument enthalten ist, das alle enthaltenen Shared-Bibliotheken annotiert, können SCA-Tools die enthaltene Software zuverlässig identifizieren.

Build-Werkzeuge, Umgebung und Reproduzierbarkeit

Über die Laufzeitabhängigkeiten eines Pakets hinausgehend: SBOMs können auch die Werkzeuge und Umgebungen aufzeichnen, die zum Erstellen eines Pakets verwendet wurden. Die genauen Werkzeuge und Versionen, die zum Erstellen eines Pakets verwendet wurden, aufzuzeichnen, ist oft erforderlich, um die Reproduzierbarkeit des Builds zu gewährleisten. Die Reproduzierbarkeit des Builds ist eine Eigenschaft von Software, die verwendet werden kann, um falsch oder bösartig modifizierte Softwarekomponenten im Vergleich zu ihren Upstream-Quellen zu erkennen. Ohne eine aufgezeichnete Liste von Build-Werkzeugen und Versionen kann es für Dritte schwierig bis unmöglich werden, die Reproduzierbarkeit des Builds zu überprüfen.

Regulierungen

SBOMs sind in neueren Vorschriften zur Softwaresicherheit erforderlich, wie dem Secure Software Development Framework (SSDF) und dem Cyber Resilience Act (CRA). Aufgrund ihrer Aufnahme in diese Vorschriften wird eine hohe Nachfrage nach SBOM-Dokumenten für Open-Source-Projekte erwartet. Ein Ziel ist es, die Anforderungen an Open-Source-Projekt-Maintainer zu minimieren, indem Open-Source-Benutzern, die SBOMs benötigen, ermöglicht wird, sich selbst mit vorhandenen Werkzeugen zu versorgen.

Ein weiteres Ziel ist es, Beiträge von Benutzern zu ermöglichen, die SBOMs benötigen, um Projekte, von denen sie abhängen, mit SBOM-Informationen zu annotieren. Derzeit gibt es keinen Mechanismus, um die Ergebnisse dieser Beiträge für ein Python-Paket weiterzugeben, sodass kein Anreiz für Benutzer besteht, diese Art von Arbeit beizutragen.

Verwendung von SBOM-Standards anstelle von Core-Metadatenfeldern

Der Versuch, jedes von SBOM-Standards angebotene Feld in die Python-Paket-Kernmetadaten aufzunehmen, würde zu einer Explosion neuer Kernmetadatenfelder führen, einschließlich der Notwendigkeit, diese bei fortschreitender Weiterentwicklung der SBOM-Standards an neue Bedürfnisse in diesem Bereich anzupassen.

Stattdessen delegiert dieser Vorschlag SBOM-spezifische Metadaten an SBOM-Dokumente, die in Python-Paketen in ein benanntes Verzeichnis unter dist-info aufgenommen werden.

Dieser Standard zielt auch nicht darauf ab, Kernmetadaten durch SBOMs zu ersetzen, sondern konzentriert sich darauf, dass die SBOM-Informationen ergänzend zu den Kernmetadaten sind. Enthaltene SBOMs enthalten nur Informationen über Abhängigkeiten, die im Paketarchiv enthalten sind, oder Informationen über die Top-Level-Software im Paket, die nicht in Kernmetadaten kodiert werden kann, aber für den SBOM-Anwendungsfall relevant ist („Software-Identifikatoren“, „Zweck“, „Support-Level“ usw.).

Null oder mehr undurchsichtige SBOM-Dokumente

Anstatt höchstens ein enthaltenes SBOM-Dokument pro Python-Paket zu fordern, schlägt dieses PEP vor, dass ein oder mehrere SBOM-Dokumente in ein Python-Paket aufgenommen werden können. Dies bedeutet, dass Code, der versucht, ein Python-Paket mit SBOM-Daten zu annotieren, dies tun kann, ohne sich um die Beschädigung von Daten zu sorgen, die bereits in anderen SBOM-Dokumenten enthalten sind.

Darüber hinaus behandelt dieses PEP die Daten in SBOM-Dokumenten als undurchsichtig und verlässt sich stattdessen auf die endgültigen Endbenutzer der SBOM-Daten, um die enthaltenen SBOM-Daten zu verarbeiten. Diese Wahl erkennt an, dass SBOM-Standards ein aktiver Entwicklungsbereich sind, in dem es noch keinen (und vielleicht nie einen) einzelnen, endgültigen SBOM-Standard gibt und dass SBOM-Standards unabhängig von Python-Packaging-Standards weiterentwickelt werden können. Bereits Tools, die SBOM-Dokumente verarbeiten, unterstützen eine Vielzahl von SBOM-Standards, um diese Realität zu bewältigen.

Diese Entscheidungen bedeuten, dass dieses PEP jeden SBOM-Standard unterstützen kann und keinen gegenüber einem anderen bevorzugt, sondern die Entscheidung den erzeugenden Projekten und Werkzeugen sowie den verbrauchenden Werkzeugen überlässt.

Hinzufügen von Daten zu Python-Paketen ohne neue Metadatenversionen

Die Einführung einer neuen Metadatenversion und eines neuen Feldes erfordert, dass viele verschiedene Projekte und Teams die Metadatenversion nacheinander übernehmen, um weit verbreitete Fehler zu vermeiden. Dieser Effekt bedeutet normalerweise eine erhebliche Verzögerung, wie schnell Benutzer und Werkzeuge neue Verpackungsfunktionen nutzen können.

Beispielsweise erfordert ein einzelner Sprung der Metadatenversion Aktualisierungen von PyPI, verschiedenen pyproject.toml-Parsing- und Schemaprojekten, der packaging-Bibliothek, Wartezeiten auf Veröffentlichungen, dann müssen pip und andere Installer die Änderungen an packaging bündeln und veröffentlichen, dann können Build-Backends beginnen, die neue Metadatenversion auszugeben, wieder Wartezeiten auf Veröffentlichungen, und erst dann können Projekte beginnen, die neuen Funktionen zu nutzen. Selbst mit diesem sorgfältigen Ansatz ist nicht garantiert, dass Tools bei neuen Metadatenversionen und Feldern nicht fehlschlagen.

Um diese Verzögerung zu vermeiden, die Einbindung von SBOMs insgesamt zu vereinfachen und Build-Backends und Tools Flexibilität zu bieten, schlägt dieses PEP die Verwendung eines Unterverzeichnisses unter .dist-info vor, um sicher Daten zu einem Python-Paket hinzuzufügen und gleichzeitig die Notwendigkeit neuer Metadatenfelder und -versionen zu vermeiden. Dieser Mechanismus ermöglicht es Build-Backends und Tools, die in diesem PEP beschriebene Funktion sofort nach der Akzeptanz zu nutzen, ohne dass die Hauptarbeit durch andere Projekte, die das PEP übernehmen, blockiert wird.

Speichern von Dateien im Verzeichnis .dist-info oder .data

Es gibt zwei Top-Level-Verzeichnisse in Binärdistributionen, in denen Dateien über die Software selbst hinaus gespeichert werden können: .dist-info und .data. Diese Spezifikation hat sich für die Verwendung des .dist-info-Verzeichnisses für die Speicherung von Unterverzeichnissen und Dateien entschieden.

Erstens hat das .data-Verzeichnis keinen entsprechenden Speicherort im installierten Paket, verglichen mit .dist-info, das die Verbindung zwischen der Binärdistribution und dem installierten Paket in einer Umgebung erhält. Das .data-Verzeichnis hat stattdessen alle seine Inhalte zwischen allen installierten Paketen in einer Umgebung zusammengeführt, was zu Kollisionen zwischen ähnlich benannten Dateien führen kann.

Zweitens erfordern Unterverzeichnisse unter dem .data-Verzeichnis neue Definitionen für das Python sysconfig-Modul. Dies bedeutet, dass für die Definition zusätzlicher Verzeichnisse auf eine Änderung von Python gewartet werden muss und für die *Verwendung* des Verzeichnisses auf die Übernahme der neuen Python-Version durch die Benutzer gewartet werden muss. Unterverzeichnisse unter .dist-info haben diese Anforderungen nicht, sie können von jedem Benutzer, Build-Backend und Installer sofort nach der Registrierung eines neuen Unterverzeichnisnamens verwendet werden, unabhängig von der Python- oder Metadatenversion.

Was sind die Unterschiede zwischen PEP 770 und PEP 725?

PEP 725 („Specifying external dependencies in pyproject.toml“) ist ein anderes PEP mit einigen Ähnlichkeiten zu PEP 770, wie z. B. dem Versuch, Nicht-Python-Software innerhalb von Python-Packaging-Metadaten zu beschreiben. Dieser Abschnitt soll zeigen, wie diese beiden PEPs unterschiedliche Informationen verfolgen und unterschiedliche Anwendungsfälle bedienen.

• PEP 725 beschreibt abstrakte Abhängigkeiten, wie z. B. die Anforderung „eines C-Compilers“ als Build-Abhängigkeit (virtual:compiler/c) oder die Notwendigkeit, „die OpenSSL-Bibliothek“ zur Build-Zeit zu verknüpfen (pkg:generic/openssl). PEP 770 beschreibt konkrete Abhängigkeiten, eher vergleichbar mit Abhängigkeiten in einer „Lock-Datei“, wie z. B. ein exakter Name, eine Version, eine Architektur und ein Hash einer Softwarebibliothek, die über die AlmaLinux-Distribution vertrieben wird (pkg:rpm/almalinux/libssl3@3.2.0). In Fällen wie Build-Abhängigkeiten kann dies dazu führen, dass eine Abhängigkeit über PEP 725 angefordert und dann nach dem Build mit PEP 770 konkret in einem SBOM aufgezeichnet wird.
• PEP 725 dient der Beschreibung von externen Abhängigkeiten, die vom System bereitgestellt werden, auf dem die Software entweder gebaut oder ausgeführt wird. PEP 770 dient der Beschreibung von gebündelter Software innerhalb von Python-Paketarchiven; die SBOM-Dokumente beschreiben keine Software auf dem System.
• PEP 725 befasst sich hauptsächlich mit der Identifizierung durch eine Liste von Software-Identifikatoren. PEP 770 bietet die vollständige Funktionalität von SBOM-Standards, um verschiedene Softwareattribute wie Lizenz, Prüfsumme, Download-Ort usw. zu beschreiben.
• PEP 725 und PEP 770 haben unterschiedliche Benutzer und Anwendungsfälle. PEP 725 ist hauptsächlich für Menschen gedacht, die Abhängigkeiten manuell in pyproject.toml schreiben. Die Benutzer der Informationen sind Build-Backends und Benutzer, die Software aus dem Quellcode erstellen möchten. PEP 770 ist hauptsächlich für Tools gedacht, die SBOM-Dokumente generieren können, die in ein Python-Paketarchiv aufgenommen werden sollen, und für SBOM/SCA-Tools, die SBOM-Dokumente über installierte Software benötigen, um andere Aufgaben wie die Schwachstellenanalyse oder die Softwareanalyse durchzuführen.

Reservierung des Verzeichnisses .dist-info/sboms

Dieses PEP führt ein neues Register für reservierte Unterverzeichnisnamen ein, die im .dist-info-Verzeichnis für die Distributionsarchiv und installierte Projekt-Typen zulässig sind. Zukünftige Ergänzungen zu diesem Register erfolgen über den PEP-Prozess. Die anfänglichen Werte in diesem Register sind

Siehe Abwärtskompatibilität für eine vollständige Methodik zur Vermeidung von Abwärtsinkompatibilitäten bei der Auswahl dieses Verzeichnisnamens.

SBOM-Dateien in Projektformaten

Einige Ergänzungen werden an den bestehenden Spezifikationen vorgenommen.

Build-Distributionen (Wheels)

Die Wheel-Spezifikation wird aktualisiert, um das neue Register für reservierte Verzeichnisnamen hinzuzufügen und zu berücksichtigen, dass, wenn das Unterverzeichnis .dist-info/sboms angegeben ist, das Verzeichnis SBOM-Dateien enthält.

Installierte Projekte

Die Spezifikation „Recording Installed Projects“ wird aktualisiert, um zu berücksichtigen, dass, wenn das Unterverzeichnis .dist-info/sboms angegeben ist, das Verzeichnis SBOM-Dateien enthält und dass alle Dateien in diesem Verzeichnis von den Installationswerkzeugen aus Wheels kopiert werden MÜSSEN.

Interoperabilität von SBOM-Daten

Dieses PEP behandelt Daten, die in SBOM-Dokumenten enthalten sind, als undurchsichtig und berücksichtigt, dass SBOM-Standards ein aktiver Entwicklungsbereich sind. Es gibt jedoch einige Überlegungen für Erzeuger von SBOM-Daten, die bei Befolgung die Interoperabilität und Benutzerfreundlichkeit von SBOM-Daten, die in Python-Paketen verfügbar sind, verbessern.

• SBOM-Dokumente SOLLTEN einen weit verbreiteten SBOM-Standard wie CycloneDX oder SPDX verwenden.
• SBOM-Dokumente SOLLTEN UTF-8-kodiertes JSON (RFC 8259) verwenden, wenn für den verwendeten SBOM-Standard verfügbar.
• SBOM-Dokumente SOLLTEN alle erforderlichen Felder für den verwendeten SBOM-Standard enthalten.
• SBOM-Dokumente SOLLTEN ein Feld „Erstellungszeitpunkt“ und „Erstellungswerkzeug“ für den verwendeten SBOM-Standard enthalten. Diese Informationen sind wichtig für Benutzer, die versuchen, verschiedene Phasen eines Python-Pakets während des Builds zu rekonstruieren.
• Die primäre Komponente, die vom SBOM-Dokument beschrieben wird, SOLLTE die Top-Level-Software innerhalb des Python-Pakets sein (z. B. „pkg:pypi/pillow“ für das Pillow-Paket).
• Alle nicht-primären Komponenten SOLLTEN einen oder mehrere Pfade im Beziehungsdiagramm haben, die die Beziehung zwischen den Komponenten zeigen. Wenn diese Informationen nicht enthalten sind, können SCA-Tools Komponenten ausschließen, die außerhalb des Beziehungsdiagramms liegen.
• Alle Softwarekomponenten SOLLTEN einen Namen, eine Version und eine oder mehrere Software-Identifikatoren (PURL, CPE, Download-URL) haben.

PyPI und andere Indizes DÜRFEN den Inhalt von SBOM-Dokumenten, die von diesem PEP spezifiziert werden, validieren, aber sie DÜRFEN keine Daten für unbekannte SBOM-Standards, Versionen oder Felder validieren oder ablehnen.

Reserviertes Unterverzeichnis .dist-info/sboms

Das neue reservierte Unterverzeichnis .dist-info/sboms stellt eine neue Reservierung dar, die zuvor nicht dokumentiert war und daher das Potenzial hat, Annahmen zu brechen, die von bereits vorhandenen Tools getroffen werden.

Um zu prüfen, welche .dist-info-Unterverzeichnisnamen heute verwendet werden, wurde eine Abfrage über alle Dateien in Paketarchiven auf PyPI ausgeführt.

SELECT (
  regexp_extract(archive_path, '.*\.dist-info/([^/]+)/', 1) AS dirname,
  COUNT(DISTINCT project_name) AS projects
)
FROM '*.parquet'
WHERE archive_path LIKE '%.dist-info/%/%'
GROUP BY dirname ORDER BY projects DESC;

Beachten Sie, dass dies nur Aufzeichnungen für *Dateien* enthält und daher keine Ergebnisse für leere Verzeichnisse liefert. Leere Verzeichnisse, die weit verbreitet sind und irgendwie tragend sind, sind unwahrscheinlich, daher ist dies ein akzeptiertes Risiko bei der Verwendung dieser Methode. Diese Abfrage ergab die folgenden Ergebnisse:

Nicht oben aufgeführt sind etwa 50 weitere Unterverzeichnisnamen, die in einem einzigen Projekt verwendet werden. Aus diesen Ergebnissen können wir sehen:

• Die meisten Unterverzeichnisse unter .dist-info haben mit Lizenzierung zu tun, von denen eines (licenses) durch PEP 639 spezifiziert ist und andere (license_files, LICENSES) aus Entwurfsfassungen von PEP 639 stammen.
• Das Unterverzeichnis sboms kollidiert nicht mit bestehender Nutzung.
• Andere Unterverzeichnisnamen unter .dist-info scheinen entweder nicht weit verbreitet oder zufällig zu sein.

Als Ergebnis dieser Abfrage können wir sehen, dass bereits einige Projekte Verzeichnisse unter .dist-info platzieren, daher können wir nicht verlangen, dass Build-Frontends Fehler für nicht registrierte Unterverzeichnisse ausgeben. Stattdessen wird empfohlen, dass Build-Frontends den Benutzer in diesem Szenario warnen oder einen Fehler ausgeben.

Was müssen Python-Paket-Maintainer wissen?

Python-Paket-Metadaten können bereits die Top-Level-Software beschreiben, die in einem Paketarchiv enthalten ist, aber was ist, wenn ein Paketarchiv andere Softwarekomponenten außer der Top-Level-Software enthält? Zum Beispiel enthält das Python-Wheel für „Pillow“ eine Handvoll anderer Softwarebibliotheken, die darin gebündelt sind, wie z. B. libjpeg, libpng, libwebp und so weiter. Dieses Szenario ist, wo dieses PEP am nützlichsten ist, um Metadaten über gebündelte Software zu einem Python-Paket hinzuzufügen.

Einige Build-Tools können gebündelte Abhängigkeiten möglicherweise automatisch annotieren. Typischerweise können Tools gebündelte Abhängigkeiten automatisch annotieren, wenn diese Abhängigkeiten aus einem „Packaging-Ökosystem“ stammen (wie PyPI, Linux-Distributionen, Crates.io, NPM usw.).

Was müssen SBOM-Tool-Autoren wissen?

Entwickler von SBOM-Generierungswerkzeugen müssen über die Existenz dieses PEPs Bescheid wissen und dass Python-Pakete beginnen können, SBOM-Dokumente innerhalb von Paketarchiven zu veröffentlichen. Diese Informationen müssen als Teil der Generierung eines SBOM-Dokuments für ein bestimmtes Python-Paket oder eine Python-Umgebung enthalten sein.

Ein nachfolgendes informatives PEP wird verfasst, um zu beschreiben, wie Python-Packaging-Metadaten, einschließlich des in diesem PEP beschriebenen Mechanismus, in ein SBOM-Dokument umgewandelt werden, das Python-Pakete beschreibt. Sobald das informative PEP abgeschlossen ist, werden Tracking-Issues speziell mit Links zum informativen PEP geöffnet, um die Übernahme von PEP 770 durch SBOM-Tools anzustoßen.

Ein Benchmark wird erstellt, um die Ausgaben verschiedener SBOM-Tools zu vergleichen, wenn sie mit verschiedenen Python-Packaging-Eingaben (Paketarchiv, installiertes Paket, Umgebung, Container-Image) ausgeführt werden. Dieser Benchmark soll verfolgen, wo Tools Lücken in der Unterstützung für dieses PEP und Python-Pakete haben.

Was müssen Benutzer von SBOM-Dokumenten wissen?

Viele Benutzer dieses PEPs werden nichts davon wissen, stattdessen werden ihre Software-Kompositionsanalyse-Tools, SBOM-Tools oder Schwachstellenscanner nach einem Upgrade einfach umfassendere Informationen liefern. Für Benutzer, die an den Quellen dieser neuen Informationen interessiert sind, bietet das Feld „tool“ der SBOM-Metadaten bereits Verknüpfungen zu den Projekten, die ihre SBOMs erstellen.

Für Benutzer, die SBOM-Dokumente benötigen, die ihre Open-Source-Abhängigkeiten beschreiben, sollte der erste Schritt immer lauten: „Erstellen Sie sie selbst“. Anhand der obigen Benchmarks kann eine Liste von Tools dokumentiert und Benutzern empfohlen werden, die für Python-Pakete als korrekt gelten. Für Projekte, die zusätzliche manuelle SBOM-Annotationen erfordern: Tipps zum Beitragen dieser Daten und Werkzeuge zur Pflege der Daten können empfohlen werden.

Beachten Sie, dass SBOM-Dokumente aufgrund von Unterschieden bei Abhängigkeiten, Python-Version, Plattform, Architektur usw. über verschiedene Python-Paketarchive hinweg variieren können. Aus diesem Grund SOLLTEN Benutzer nur die SBOM-Dokumente innerhalb des tatsächlich heruntergeladenen und installierten Python-Paketarchivs verwenden und nicht davon ausgehen, dass die SBOM-Dokumente für alle Archive einer bestimmten Paketversion gleich sind.

Anforderung eines einzigen SBOM-Standards

Es gibt keinen universell anerkannten SBOM-Standard und dieser Bereich entwickelt sich noch schnell (z. B. hat SPDX im April 2024 eine neue Hauptversion seines Standards veröffentlicht). Die meiste Diskussion und Entwicklung rund um SBOMs konzentriert sich heute auf zwei SBOM-Standards: CycloneDX und SPDX.

Um zu vermeiden, dass das Python-Ökosystem vorzeitig auf einen bestimmten Standard festgelegt wird, bevor sich ein klarer Gewinner abzeichnet, behandelt dieses PEP SBOM-Dokumente als undurchsichtig und macht nur Empfehlungen, um die Kompatibilität mit nachgelagerten Verbrauchern von SBOM-Dokumentdaten zu fördern.

Keine der Entscheidungen in diesem PEP schränkt ein zukünftiges PEP ein, einen einzigen SBOM-Standard festzulegen. Tools, die heute SBOM-Daten verwenden, müssen bereits mehrere Formate unterstützen, um diese Situation zu bewältigen, sodass ein zukünftiger Standard, der die Anforderung nur eines Standards aktualisiert, keine Auswirkungen auf nachgelagerte SBOM-Tools hätte.

Verwendung von Metadatenfeldern zur Angabe von SBOM-Dateien in Archiven

Eine frühere Version dieser Spezifikation verwendete ein Metadatenfeld Sbom-File, um eine SBOM-Datei innerhalb eines Quell- oder Binärdistributionsarchivs anzugeben. Dies würde die Implementierung ähnlich wie bei PEP 639 machen, das das Feld License-File verwendet, um Lizenzdateien in Archiven aufzulisten.

Das Hauptproblem bei diesem Ansatz ist, dass SBOM-Dateien sowohl aus statischen als auch aus dynamischen Quellen stammen können: wie versionierter Quellcode, das Build-Backend oder von Tools, die SBOM-Dateien nach Abschluss des Builds hinzufügen (wie auditwheel).

Metadatenfelder müssen entweder statisch oder dynamisch sein, nicht beides. Dies steht im direkten Konflikt mit dem Best-Case-Szenario für SBOM-Daten: dass SBOM-Dateien automatisch von Tools während des Builds eines Python-Pakets ohne Benutzerbeteiligung oder Wissen hinzugefügt werden. Vergleichen Sie diese Situation mit Lizenzdateien, die fast immer statisch sind.

Der 639-ähnliche Ansatz wurde schließlich zugunsten der einfachen Definition von SBOMs durch ihre Anwesenheit im Verzeichnis .dist-info/sboms fallen gelassen. Dieser Ansatz ermöglicht es Build-Backends und Tools, ihre eigenen SBOM-Daten hinzuzufügen, ohne den statisch/dynamischen Konflikt.

Ein zukünftiges PEP wird den Prozess für die statische Definition von SBOM-Dateien definieren, die dem Verzeichnis .dist-info/sboms hinzugefügt werden sollen.