CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 770 – Improving measurability of Python packages with Software Bill-of-Materials | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0770/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 770 – Improving measurability of Python packages with Software Bill-of-Materials | peps.python.org'> <meta property="og:description" content="Almost all Python packages today are accurately measurable by software composition analysis (SCA) tools. For projects that are not accurately measurable, there is no existing mechanism to annotate a Python package with composition data to improve measur..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0770/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="Almost all Python packages today are accurately measurable by software composition analysis (SCA) tools. For projects that are not accurately measurable, there is no existing mechanism to annotate a Python package with composition data to improve measur..."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 770</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> <span class="visually-hidden">Toggle light / dark / auto colour theme</span> </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 770 – Improving measurability of Python packages with Software Bill-of-Materials</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Seth Larson <seth at python.org></dd> <dt class="field-even">Sponsor<span class="colon">:</span></dt> <dd class="field-even">Brett Cannon <brett at python.org></dd> <dt class="field-odd">PEP-Delegate<span class="colon">:</span></dt> <dd class="field-odd">Brett Cannon <brett at python.org></dd> <dt class="field-even">Discussions-To<span class="colon">:</span></dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/76308">Discourse thread</a></dd> <dt class="field-odd">Status<span class="colon">:</span></dt> <dd class="field-odd"><abbr title="Proposal under active discussion and revision">Draft</abbr></dd> <dt class="field-even">Type<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-odd">Topic<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="../topic/packaging/">Packaging</a></dd> <dt class="field-even">Created<span class="colon">:</span></dt> <dd class="field-even">02-Jan-2025</dd> <dt class="field-odd">Post-History<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/70261" title="Discourse thread">05-Nov-2024</a>, <a class="reference external" href="https://discuss.python.org/t/76308" title="Discourse thread">06-Jan-2025</a></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a><ul> <li><a class="reference internal" href="#measurability-and-phantom-dependencies">Measurability and Phantom Dependencies</a></li> <li><a class="reference internal" href="#build-tools-environment-and-reproducibility">Build Tools, Environment, and Reproducibility</a></li> <li><a class="reference internal" href="#regulations">Regulations</a></li> </ul> </li> <li><a class="reference internal" href="#rationale">Rationale</a><ul> <li><a class="reference internal" href="#using-sbom-standards-instead-of-core-metadata-fields">Using SBOM standards instead of Core Metadata fields</a></li> <li><a class="reference internal" href="#zero-or-more-opaque-sbom-documents">Zero-or-more opaque SBOM documents</a></li> <li><a class="reference internal" href="#what-are-the-differences-between-pep-770-and-pep-725">What are the differences between PEP 770 and PEP 725?</a></li> </ul> </li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#terminology">Terminology</a></li> <li><a class="reference internal" href="#core-metadata">Core Metadata</a><ul> <li><a class="reference internal" href="#add-sbom-file-field">Add <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> field</a></li> </ul> </li> <li><a class="reference internal" href="#project-source-metadata">Project source metadata</a><ul> <li><a class="reference internal" href="#add-sbom-files-key">Add <code class="docutils literal notranslate"><span class="pre">sbom-files</span></code> key</a></li> </ul> </li> <li><a class="reference internal" href="#sbom-files-in-project-formats">SBOM files in project formats</a></li> <li><a class="reference internal" href="#sbom-data-interoperability">SBOM data interoperability</a></li> </ul> </li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li> <li><a class="reference internal" href="#security-implications">Security Implications</a></li> <li><a class="reference internal" href="#how-to-teach-this">How to Teach This</a><ul> <li><a class="reference internal" href="#what-do-python-package-maintainers-need-to-know">What do Python package maintainers need to know?</a></li> <li><a class="reference internal" href="#what-do-sbom-tool-authors-need-to-know">What do SBOM tool authors need to know?</a></li> <li><a class="reference internal" href="#what-do-users-of-sbom-documents-need-to-know">What do users of SBOM documents need to know?</a></li> </ul> </li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#why-not-require-a-single-sbom-standard">Why not require a single SBOM standard?</a></li> </ul> </li> <li><a class="reference internal" href="#id1">Rejected Ideas</a><ul> <li><a class="reference internal" href="#selecting-a-single-sbom-standard">Selecting a single SBOM standard</a></li> </ul> </li> <li><a class="reference internal" href="#open-issues">Open Issues</a><ul> <li><a class="reference internal" href="#conditional-project-source-sbom-files">Conditional project source SBOM files</a></li> </ul> </li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <p>Almost all Python packages today are accurately measurable by software composition analysis (SCA) tools. For projects that are not accurately measurable, there is no existing mechanism to annotate a Python package with composition data to improve measurability.</p> <p>Software Bill-of-Materials (SBOM) is a technology-and-ecosystem-agnostic method for describing software composition, provenance, heritage, and more. SBOMs are used as inputs for SCA tools, such as scanners for vulnerabilities and licenses, and have been gaining traction in global software regulations and frameworks.</p> <p>This PEP proposes using SBOM documents included in Python packages as a means to improve automated software measurability for Python packages.</p> <p>The changes will update the <a class="reference external" href="https://packaging.python.org/specifications/core-metadata">Core Metadata specification</a> to version 2.5.</p> </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> <section id="measurability-and-phantom-dependencies"> <h3><a class="toc-backref" href="#measurability-and-phantom-dependencies" role="doc-backlink">Measurability and Phantom Dependencies</a></h3> <p>Python packages are particularly affected by the “<a class="reference external" href="https://www.endorlabs.com/learn/dependency-resolution-in-python-beware-the-phantom-dependency">phantom dependency</a>” problem, where software components that aren’t written in Python are included in Python packages for many reasons, such as ease of installation and compatibility with standards:</p> <ul class="simple"> <li>Python serves scientific, data, web, and machine-learning use-cases which use compiled or non-Python languages like Rust, C, C++, Fortran, JavaScript, and others.</li> <li>The Python wheel format is preferred by users due to the ease-of-installation. No code is executed during the installation step, only extracting the archive.</li> <li>The Python wheel format requires bundling shared compiled libraries without a method to encode metadata about these libraries.</li> <li>Packages related to Python packaging sometimes need to solve the “bootstrapping” problem, so include pure Python projects inside their source code.</li> </ul> <p>These software components can’t be described using Python package metadata and thus are likely to be missed by software composition analysis (SCA) software which can mean vulnerable software components aren’t reported accurately.</p> <p><a class="reference external" href="https://sethmlarson.dev/early-promising-results-with-sboms-and-python-packages">For example</a>, the Python package Pillow includes 16 shared object libraries in the wheel that were bundled by auditwheel as a part of the build. None of those shared object libraries are detected when using common SCA tools like Syft and Grype. If an SBOM document is included annotating all the included shared libraries then SCA tools can identify the included software reliably.</p> </section> <section id="build-tools-environment-and-reproducibility"> <h3><a class="toc-backref" href="#build-tools-environment-and-reproducibility" role="doc-backlink">Build Tools, Environment, and Reproducibility</a></h3> <p>Going beyond the runtime dependencies of a package: SBOMs can also record the tools and environments used to build a package. Recording the exact tools and versions used to build a package is often required to establish <a class="reference external" href="https://reproducible-builds.org">build reproducibility</a>. Build reproducibility is a property of software that can be used to detect incorrectly or maliciously modified software components when compared to their upstream sources. Without a recorded list of build tools and versions it can become difficult to impossible for a third-party to verify build reproducibility.</p> </section> <section id="regulations"> <h3><a class="toc-backref" href="#regulations" role="doc-backlink">Regulations</a></h3> <p>SBOMs are required by recent software security regulations, like the <a class="reference external" href="https://csrc.nist.gov/Projects/ssdf">Secure Software Development Framework</a> (SSDF) and the <a class="reference external" href="https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act">Cyber Resilience Act</a> (CRA). Due to their inclusion in these regulations, the demand for SBOM documents of open source projects is expected to be high. One goal is to minimize the demands on open source project maintainers by enabling open source users that need SBOMs to self-serve using existing tooling.</p> <p>Another goal is to enable contributions from users who need SBOMs to annotate projects they depend on with SBOM information. Today there is no mechanism to propagate the results of those contributions for a Python package so there is no incentive for users to contribute this type of work.</p> </section> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> <section id="using-sbom-standards-instead-of-core-metadata-fields"> <h3><a class="toc-backref" href="#using-sbom-standards-instead-of-core-metadata-fields" role="doc-backlink">Using SBOM standards instead of Core Metadata fields</a></h3> <p>Attempting to add every field offered by SBOM standards into Python package Core Metadata would result in an explosion of new Core Metadata fields, including the need to keep up-to-date as SBOM standards continue to evolve to suit new needs in that space.</p> <p>Instead, this proposal delegates SBOM-specific metadata to SBOM documents that are included in Python packages and adds a new Core Metadata field for discoverability of included SBOM documents.</p> <p>This standard also doesn’t aim to replace Core Metadata with SBOMs, instead focusing on the SBOM information being supplemental to Core Metadata. Included SBOMs only contain information about dependencies included in the package archive or information about the top-level software in the package that can’t be encoded into Core Metadata but is relevant for the SBOM use-case (“software identifiers”, “purpose”, “support level”, etc).</p> </section> <section id="zero-or-more-opaque-sbom-documents"> <h3><a class="toc-backref" href="#zero-or-more-opaque-sbom-documents" role="doc-backlink">Zero-or-more opaque SBOM documents</a></h3> <p>Rather than requiring at most one included SBOM document per Python package, this PEP proposes that one or more SBOM documents may be included in a Python package. This means that code attempting to annotate a Python package with SBOM data may do so without being concerned about corrupting data already contained within other SBOM documents.</p> <p>Additionally, this PEP treats SBOM document data opaquely instead relying on final end-users of the SBOM data to process the contained SBOM data. This choice acknowledges that SBOM standards are an active area of development where there is not yet (and may never be) a single definitive SBOM standard and that SBOM standards can continue to evolve independent of Python packaging standards. Already tools that consume SBOM documents support a multitude of SBOM standards to handle this reality.</p> <p>These decisions mean this PEP is capable of supporting any SBOM standard and does not favor one over the other, instead deferring the decision to producing projects and tools and consuming user tooling.</p> </section> <section id="what-are-the-differences-between-pep-770-and-pep-725"> <h3><a class="toc-backref" href="#what-are-the-differences-between-pep-770-and-pep-725" role="doc-backlink">What are the differences between PEP 770 and PEP 725?</a></h3> <p><a class="pep reference internal" href="../pep-0725/" title="PEP 725 – Specifying external dependencies in pyproject.toml">PEP 725</a> (“Specifying external dependencies in pyproject.toml”) is a different PEP with some similarities to PEP 770, such as attempting to describe non-Python software within Python packaging metadata. This section aims to show how these two PEPs are tracking different information and serving different use-cases:</p> <ul class="simple"> <li>PEP 725 describes <strong>abstract dependencies</strong>, such as requiring “a C compiler” as a build-time dependency (<code class="docutils literal notranslate"><span class="pre">virtual:compiler/c</span></code>). PEP 770 describes <strong>concrete dependencies</strong>, such as an exact name, version, architecture, and hash of a software library distributed through AlmaLinux distribution (<code class="docutils literal notranslate"><span class="pre">pkg:rpm/almalinux/libssl3@3.2.0</span></code>). For cases like build dependencies this might result in a dependency being requested via PEP 725 and then recorded concretely in an SBOM post-build with PEP 770.</li> <li>PEP 725 is for describing <strong>external dependencies</strong>, provided by the system being used to either build or run the software. PEP 770 is for describing <strong>bundled software inside Python package archives</strong>, the SBOM documents don’t describe software on the system.</li> <li><strong>PEP 725 is primarily about identification</strong>, using a list of software identifiers. PEP 770 provides the <strong>complete functionality of SBOM standards</strong> to describe various software attributes such as license, checksum, download location, etc.</li> <li><strong>PEP 725 and PEP 770 have different users and use-cases</strong>. PEP 725 is primarily for humans writing dependencies in <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> by hand. The users of the information are build backends and users who want to build software from source. PEP 770 is primarily for tools which are capable of generating SBOM documents to be included in a Python package archive and SBOM/SCA tools which want to SBOM documents about installed software to do some other task such as vulnerability scanning or software analysis.</li> </ul> </section> </section> <section id="specification"> <span id="spec"></span><h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <p>The changes necessary to implement this PEP include:</p> <ul class="simple"> <li>Additions to <a class="reference internal" href="#spec-core-metadata">Core Metadata</a>, as defined in the <a class="reference external" href="https://packaging.python.org/specifications/core-metadata">Core Metadata specification</a>.</li> <li>Additions to the author-provided <a class="reference internal" href="#spec-project-source-metadata">project source metadata</a>, as defined in the <a class="reference external" href="https://packaging.python.org/en/latest/specifications/pyproject-toml/">pyproject.toml specification</a>.</li> <li><a class="reference internal" href="#spec-project-formats">Additions</a> to the source distribution (sdist), built distribution (wheel), and installed project specifications.</li> </ul> <p>In addition to the above, an informational PEP will be created for tools consuming included SBOM documents and other Python package metadata to generate complete SBOM documents for Python packages.</p> <section id="terminology"> <h3><a class="toc-backref" href="#terminology" role="doc-backlink">Terminology</a></h3> <p>This section describes terminology used later in the document:</p> <dl class="simple glossary"> <dt id="term-root-SBOM-directory">root SBOM directory</dt><dd>The directory under which SBOM files are stored in a <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Project-Source-Tree" title="(in Python Packaging User Guide)"><span class="xref std std-term">project source tree</span></a>, <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Distribution-Archive" title="(in Python Packaging User Guide)"><span class="xref std std-term">distribution archive</span></a> or <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Installed-Project" title="(in Python Packaging User Guide)"><span class="xref std std-term">installed project</span></a>. Also, the root directory that their paths recorded in the <a class="reference internal" href="#spec-sbom-file-field"><span class="std std-ref">Sbom-File</span></a> <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Core-Metadata-Field" title="(in Python Packaging User Guide)"><span class="xref std std-term">Core Metadata field</span></a> are relative to. Defined to be the <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Project-Root-Directory" title="(in Python Packaging User Guide)"><span class="xref std std-term">project root directory</span></a> for a <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Project-Source-Tree" title="(in Python Packaging User Guide)"><span class="xref std std-term">project source tree</span></a> or <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Source-Distribution-or-sdist" title="(in Python Packaging User Guide)"><span class="xref std std-term">source distribution</span></a>; and a subdirectory named <code class="docutils literal notranslate"><span class="pre">sboms</span></code> of the directory containing the <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Built-Metadata" title="(in Python Packaging User Guide)"><span class="xref std std-term">built metadata</span></a>— i.e., the <code class="docutils literal notranslate"><span class="pre">.dist-info/sboms</span></code> directory— for a <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Built-Distribution" title="(in Python Packaging User Guide)"><span class="xref std std-term">Built Distribution</span></a> or <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Installed-Project" title="(in Python Packaging User Guide)"><span class="xref std std-term">installed project</span></a>.</dd> </dl> </section> <section id="core-metadata"> <span id="spec-core-metadata"></span><h3><a class="toc-backref" href="#core-metadata" role="doc-backlink">Core Metadata</a></h3> <section id="add-sbom-file-field"> <span id="spec-sbom-file-field"></span><h4><a class="toc-backref" href="#add-sbom-file-field" role="doc-backlink">Add <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> field</a></h4> <p>The <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> is a new optional Core Metadata field. Each instance contains a string representation of the path to an SBOM document. The path is specified relative to the <a class="reference internal" href="#term-root-SBOM-directory"><span class="xref std std-term">root SBOM directory</span></a> for all project types. It is a multi-use field that MAY appear zero or more times and each instance lists the path to one such file. Files specified under this field are SBOM documents that are distributed with the package.</p> <p>As <a class="reference external" href="#770-spec-project-formats">specified by this PEP</a>, its value is also that file’s path relative to the <a class="reference internal" href="#term-root-SBOM-directory"><span class="xref std std-term">root SBOM directory</span></a> in both installed projects and the standardized Distribution Package types.</p> <p>If an <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> is listed in a <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Source-Distribution-or-sdist" title="(in Python Packaging User Guide)"><span class="xref std std-term">Source Distribution</span></a> or <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Built-Distribution" title="(in Python Packaging User Guide)"><span class="xref std std-term">Built Distribution</span></a>’s Core Metadata:</p> <ul class="simple"> <li>That file MUST be included in the <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Distribution-Archive" title="(in Python Packaging User Guide)"><span class="xref std std-term">distribution archive</span></a> at the specified path relative to the <a class="reference internal" href="#term-root-SBOM-directory"><span class="xref std std-term">root SBOM directory</span></a>.</li> <li>Installers MUST install the file with the <a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Project" title="(in Python Packaging User Guide)"><span class="xref std std-term">project</span></a> at that same relative path.</li> <li>Inside the <a class="reference internal" href="#term-root-SBOM-directory"><span class="xref std std-term">root SBOM directory</span></a>, packaging tools MUST reproduce the directory structure under which the source files are located relative to the project root.</li> <li>Path delimiters MUST be the forward slash character (<code class="docutils literal notranslate"><span class="pre">/</span></code>), and parent directory indicators (<code class="docutils literal notranslate"><span class="pre">..</span></code>) MUST NOT be used.</li> </ul> <p>For all newly-uploaded distribution archives that include one or more <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> fields in their Core Metadata and declare a <code class="docutils literal notranslate"><span class="pre">Metadata-Version</span></code> of <code class="docutils literal notranslate"><span class="pre">2.5</span></code> or higher, PyPI and other indices SHOULD validate that all files specified with <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> are present in the distribution archives.</p> </section> </section> <section id="project-source-metadata"> <span id="spec-project-source-metadata"></span><h3><a class="toc-backref" href="#project-source-metadata" role="doc-backlink">Project source metadata</a></h3> <p>This PEP specifies changes to the project’s source metadata under a <code class="docutils literal notranslate"><span class="pre">[project]</span></code> table in the <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> file.</p> <section id="add-sbom-files-key"> <h4><a class="toc-backref" href="#add-sbom-files-key" role="doc-backlink">Add <code class="docutils literal notranslate"><span class="pre">sbom-files</span></code> key</a></h4> <p>A new optional <code class="docutils literal notranslate"><span class="pre">sbom-files</span></code> key is added to the <code class="docutils literal notranslate"><span class="pre">[project]</span></code> table for specifying paths in the project source tree relative to <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> to file(s) containing SBOMs to be distributed with the package. This key corresponds to the <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> fields in the Core Metadata.</p> <p>Its value is an array of strings which MUST contain valid glob patterns, as specified below:</p> <ul class="simple"> <li>Alphanumeric characters, underscores (<code class="docutils literal notranslate"><span class="pre">_</span></code>), hyphens (<code class="docutils literal notranslate"><span class="pre">-</span></code>) and dots (<code class="docutils literal notranslate"><span class="pre">.</span></code>) MUST be matched verbatim.</li> <li>Special glob characters: <code class="docutils literal notranslate"><span class="pre">*</span></code>, <code class="docutils literal notranslate"><span class="pre">?</span></code>, <code class="docutils literal notranslate"><span class="pre">**</span></code> and character ranges: <code class="docutils literal notranslate"><span class="pre">[]</span></code> containing only the verbatim matched characters MUST be supported. Within <code class="docutils literal notranslate"><span class="pre">[...]</span></code>, the hyphen indicates a locale-agnostic range (e.g. a-z, order based on Unicode code points). Hyphens at the start or end are matched literally.</li> <li>Path delimiters MUST be the forward slash character (<code class="docutils literal notranslate"><span class="pre">/</span></code>). Patterns are relative to the directory containing <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code>, therefore the leading slash character MUST NOT be used.</li> <li>Parent directory indicators (<code class="docutils literal notranslate"><span class="pre">..</span></code>) MUST NOT be used.</li> </ul> <p>Any characters or character sequences not covered by this specification are invalid. Projects MUST NOT use such values. Tools consuming this field SHOULD reject invalid values with an error.</p> <p>Literal paths (e.g. <code class="docutils literal notranslate"><span class="pre">bom.cdx.json</span></code>) are treated as valid globs which means they can also be defined.</p> <p>Build tools:</p> <ul class="simple"> <li>MUST treat each value as a glob pattern, and MUST raise an error if the pattern contains invalid glob syntax.</li> <li>MUST include all files matched by a listed pattern in all distribution archives.</li> <li>MUST list each matched file path under an <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> field in the Core Metadata.</li> <li>MUST raise an error if any individual user-specified pattern does not match at least one file.</li> </ul> <p>If the <code class="docutils literal notranslate"><span class="pre">sbom-files</span></code> key is present and is set to a value of an empty array, then tools MUST NOT include any SBOM files and MUST NOT raise an error.</p> <p>Examples of valid SBOM files declarations:</p> <div class="highlight-toml notranslate"><div class="highlight"><pre><span></span><span class="k">[project]</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">"bom.json"</span><span class="p">]</span> <span class="k">[project]</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">"sboms/openssl.cdx.json"</span><span class="p">,</span><span class="w"> </span><span class="s2">"sboms/openssl.spdx.json"</span><span class="p">]</span> <span class="k">[project]</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">"sboms/*"</span><span class="p">]</span> <span class="k">[project]</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[]</span> </pre></div> </div> <p>Examples of invalid SBOM files declarations:</p> <div class="highlight-toml notranslate"><div class="highlight"><pre><span></span><span class="k">[project]</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">"..</span><span class="se">\b</span><span class="s2">om.json"</span><span class="p">]</span> </pre></div> </div> <p>Reason: <code class="docutils literal notranslate"><span class="pre">..</span></code> must not be used. <code class="docutils literal notranslate"><span class="pre">\\</span></code> is an invalid path delimiter, <code class="docutils literal notranslate"><span class="pre">/</span></code> must be used.</p> <div class="highlight-toml notranslate"><div class="highlight"><pre><span></span><span class="k">[project]</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">"bom{.json*"</span><span class="p">]</span> </pre></div> </div> <p>Reason: <code class="docutils literal notranslate"><span class="pre">bom{.json</span></code> is not a valid glob.</p> </section> </section> <section id="sbom-files-in-project-formats"> <span id="spec-project-formats"></span><h3><a class="toc-backref" href="#sbom-files-in-project-formats" role="doc-backlink">SBOM files in project formats</a></h3> <p>A few additions will be made to the existing specifications.</p> <dl class="simple"> <dt><a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Project-Source-Tree" title="(in Python Packaging User Guide)"><span class="xref std std-term">Project source trees</span></a></dt><dd>Per <a class="reference internal" href="../pep-0639/#spec-source-metadata"><span class="std std-ref">Project source metadata</span></a> section, the <a class="reference external" href="https://packaging.python.org/en/latest/specifications/pyproject-toml/">Declaring Project Metadata specification</a> will be updated to reflect that SBOM file paths MUST be relative to the project root directory; i.e. the directory containing the <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> (or equivalently, other legacy project configuration, e.g. <code class="docutils literal notranslate"><span class="pre">setup.py</span></code>, <code class="docutils literal notranslate"><span class="pre">setup.cfg</span></code>, etc).</dd> <dt><a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Source-Distribution-or-sdist" title="(in Python Packaging User Guide)"><span class="xref std std-term">Source distributions (sdists)</span></a></dt><dd>The sdist specification will be updated to reflect that if the <code class="docutils literal notranslate"><span class="pre">Metadata-Version</span></code> is <code class="docutils literal notranslate"><span class="pre">2.5</span></code> or greater, the sdist MUST contain any SBOM files specified by the <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> field in the <code class="docutils literal notranslate"><span class="pre">PKG-INFO</span></code> at their respective paths relative to the sdist (containing the <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> and the <code class="docutils literal notranslate"><span class="pre">PKG-INFO</span></code> Core Metadata).</dd> <dt><a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Built-Distribution" title="(in Python Packaging User Guide)"><span class="xref std std-term">Built distributions</span></a> (<a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Wheel" title="(in Python Packaging User Guide)"><span class="xref std std-term">wheels</span></a>)</dt><dd>The wheel specification will be updated to reflect that if the <code class="docutils literal notranslate"><span class="pre">Metadata-Version</span></code> is <code class="docutils literal notranslate"><span class="pre">2.5</span></code> or greater and one or more <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> fields are specified, the <code class="docutils literal notranslate"><span class="pre">.dist-info</span></code> directory MUST contain an <code class="docutils literal notranslate"><span class="pre">sboms</span></code> subdirectory, which MUST contain the files listed in the <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> fields in the <code class="docutils literal notranslate"><span class="pre">METADATA</span></code> file at their respective paths relative to the <code class="docutils literal notranslate"><span class="pre">sboms</span></code> directory.</dd> <dt><a class="reference external" href="https://packaging.python.org/en/latest/glossary/#term-Installed-Project" title="(in Python Packaging User Guide)"><span class="xref std std-term">Installed projects</span></a></dt><dd>The Recording Installed Projects specification will be updated to reflect that if the <code class="docutils literal notranslate"><span class="pre">Metadata-Version</span></code> is <code class="docutils literal notranslate"><span class="pre">2.5</span></code> or greater and one or more <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> fields is specified, the <code class="docutils literal notranslate"><span class="pre">.dist-info</span></code> directory MUST contain an <code class="docutils literal notranslate"><span class="pre">sboms</span></code> subdirectory which MUST contain the files listed in the <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> fields in the <code class="docutils literal notranslate"><span class="pre">METADATA</span></code> file at their respective paths relative to the <code class="docutils literal notranslate"><span class="pre">sboms</span></code> directory, and that any files in this directory MUST be copied from wheels by install tools.</dd> </dl> </section> <section id="sbom-data-interoperability"> <h3><a class="toc-backref" href="#sbom-data-interoperability" role="doc-backlink">SBOM data interoperability</a></h3> <p>This PEP treats data contained within SBOM documents as opaque, recognizing that SBOM standards are an active area of development. However, there are some considerations for SBOM data producers that when followed will improve the interoperability and usability of SBOM data made available in Python packages:</p> <ul class="simple"> <li>SBOM documents SHOULD use a widely-accepted SBOM standard, such as <a class="reference external" href="https://cyclonedx.org/specification/overview/">CycloneDX</a> or <a class="reference external" href="https://spdx.dev/use/specifications/">SPDX</a>.</li> <li>SBOM documents SHOULD use UTF-8-encoded JSON (<span class="target" id="index-0"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc8259.html"><strong>RFC 8259</strong></a>) when available for the SBOM standard in use.</li> <li>SBOM documents SHOULD include all required fields for the SBOM standard in use.</li> <li>SBOM documents SHOULD include a “time of creation” and “creating tool” field for the SBOM standard in use. This information is important for users attempting to reconstruct different stages for a Python package being built.</li> <li>The primary component described by the SBOM document SHOULD be the top-level software within the Python package (for example, “pkg:pypi/pillow” for the Pillow package).</li> <li>All non-primary components SHOULD have one or more paths in the relationship graph showing the relationship between components. If this information isn’t included, SCA tools might exclude components outside of the relationship graph.</li> <li>All software components SHOULD have a name, version, and one or more software identifiers (PURL, CPE, download URL).</li> </ul> <p>PyPI and other indices MAY validate the contents of SBOM documents specified by this PEP, but MUST NOT validate or reject data for unknown SBOM standards, versions, or fields.</p> </section> </section> <section id="backwards-compatibility"> <h2><a class="toc-backref" href="#backwards-compatibility" role="doc-backlink">Backwards Compatibility</a></h2> <p>There are no backwards compatibility concerns for this PEP.</p> <p>The changes to Python package Core Metadata and <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code> are only additive, this PEP doesn’t change the behavior of any existing fields.</p> <p>Tools which are processing Python packages can use the <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> core metadata field to clearly delineate between packages which include SBOM documents that implement this PEP (and thus have more requirements) and packages which include SBOM documents before this PEP was authored.</p> </section> <section id="security-implications"> <h2><a class="toc-backref" href="#security-implications" role="doc-backlink">Security Implications</a></h2> <p>SBOM documents are only as useful as the information encoded in them. If an SBOM document contains incorrect information then this can result in incorrect downstream analysis by SCA tools. For this reason, it’s important for tools including SBOM data into Python packages to be confident in the information they are recording. SBOMs are capable of recording “known unknowns” in addition to known data. This practice is recommended when not certain about the data being recorded to allow for further analysis by users.</p> <p>Because SBOM documents can encode information about the original system where a Python package is built (for example, the operating system name and version, less commonly the names of paths). This information has the potential to “leak” through the Python package to installers via SBOMs. If this information is sensitive, then that could represent a security risk.</p> </section> <section id="how-to-teach-this"> <h2><a class="toc-backref" href="#how-to-teach-this" role="doc-backlink">How to Teach This</a></h2> <p>Most typical users of Python and Python packages won’t need to know the details of this standard. The details of this standard are most important to either maintainers of Python packages and developers of SCA tools such as SBOM generation tools and vulnerability scanners.</p> <section id="what-do-python-package-maintainers-need-to-know"> <h3><a class="toc-backref" href="#what-do-python-package-maintainers-need-to-know" role="doc-backlink">What do Python package maintainers need to know?</a></h3> <p>Python package metadata can already describe the top-level software included in a package archive, but what if a package archive contains other software components beyond the top-level software? For example, the Python wheel for “Pillow” contains a handful of other software libraries bundled inside, like <code class="docutils literal notranslate"><span class="pre">libjpeg</span></code>, <code class="docutils literal notranslate"><span class="pre">libpng</span></code>, <code class="docutils literal notranslate"><span class="pre">libwebp</span></code>, and so on. This scenario is where this PEP is most useful, for adding metadata about bundled software to a Python package.</p> <p>Some build tools may be able to automatically annotate bundled dependencies. Typically tools can automatically annotate bundled dependencies when those dependencies come from a “packaging ecosystem” (such as PyPI, Linux distros, Crates.io, NPM, etc).</p> <p>For packages which cannot be automatically annotated and if the package author wishes to provide an SBOM the approach will be to generate or author SBOM files and then include those files using <code class="docutils literal notranslate"><span class="pre">pyproject.toml</span></code>:</p> <blockquote> <div><div class="highlight-toml notranslate"><div class="highlight"><pre><span></span><span class="k">[project]</span> <span class="p">...</span> <span class="n">sbom-files</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span> <span class="w"> </span><span class="s2">"sboms/bom.cdx.json"</span> <span class="p">]</span> </pre></div> </div> </div></blockquote> <p>For projects manually specifying an SBOM document the challenge will be keeping the document up-to-date. The CPython project has some <a class="reference external" href="https://github.com/python/cpython/blob/main/Tools/build/generate_sbom.py">customized tooling</a> for this task, but it can likely be generalized into a tool reusable by other projects.</p> </section> <section id="what-do-sbom-tool-authors-need-to-know"> <h3><a class="toc-backref" href="#what-do-sbom-tool-authors-need-to-know" role="doc-backlink">What do SBOM tool authors need to know?</a></h3> <p>Developers of SBOM generation tooling will need to know about the existence of this PEP and that Python packages may begin publishing SBOM documents within package archives. This information needs to be included as a part of generating an SBOM document for a particular Python package or Python environment.</p> <p>A follow-up informational PEP will be authored to describe how to transform Python packaging metadata, including the mechanism described in this PEP, into an SBOM document describing Python packages. Once the informational PEP is complete, tracking issues will be opened specifically linking to the informational PEP to spur the adoption of PEP 770 by SBOM tools.</p> <p>A <a class="reference external" href="https://github.com/psf/sboms-for-python-packages/tree/main/benchmark">benchmark is being created</a> to compare the outputs of different SBOM tools when run with various Python packaging inputs (package archive, installed package, environment, container image) is being created to track the progress of different SBOM generation tools. This benchmark will inform where tools have gaps in support of this PEP and Python packages.</p> </section> <section id="what-do-users-of-sbom-documents-need-to-know"> <h3><a class="toc-backref" href="#what-do-users-of-sbom-documents-need-to-know" role="doc-backlink">What do users of SBOM documents need to know?</a></h3> <p>Many users of this PEP won’t know of its existence, instead their software composition analysis tools, SBOM tools, or vulnerability scanners will simply begin giving more comprehensive information after an upgrade. For users that are interested in the sources of this new information, the “tool” field of SBOM metadata already provides linkages to the projects generating their SBOMs.</p> <p>For users who need SBOM documents describing their open source dependencies the first step should always be “create them yourself”. Using the benchmarks above a list of tools that are known to be accurate for Python packages can be documented and recommended to users. For projects which require additional manual SBOM annotation: tips for contributing this data and tools for maintaining the data can be recommended.</p> </section> </section> <section id="reference-implementation"> <h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2> <p><a class="reference external" href="https://sethmlarson.dev/early-promising-results-with-sboms-and-python-packages">Auditwheel fork</a> which generates CycloneDX SBOM documents to include in wheels describing bundled shared library files. These SBOM documents worked as expected for the Syft and Grype SBOM and vulnerability scanners.</p> </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> <section id="why-not-require-a-single-sbom-standard"> <h3><a class="toc-backref" href="#why-not-require-a-single-sbom-standard" role="doc-backlink">Why not require a single SBOM standard?</a></h3> <p>Most discussion and development around SBOMs today focuses on two SBOM standards: <a class="reference external" href="https://cyclonedx.org/specification/overview/">CycloneDX</a> and <a class="reference external" href="https://spdx.dev/use/specifications/">SPDX</a>. There is no clear “winner” between these two standards, both standards are frequently used by projects and software ecosystems.</p> <p>Because both standards are frequently used, tools for consuming and processing SBOM documents commonly need to support both standards. This means that this PEP is not constrained to select a single SBOM standard by its consumers and thus can allow tools creating SBOM documents for inclusion in Python packages to choose which SBOM standard works best for their use-case.</p> </section> </section> <section id="id1"> <h2><a class="toc-backref" href="#id1" role="doc-backlink">Rejected Ideas</a></h2> <section id="selecting-a-single-sbom-standard"> <h3><a class="toc-backref" href="#selecting-a-single-sbom-standard" role="doc-backlink">Selecting a single SBOM standard</a></h3> <p>There is no universally accepted SBOM standard and this area is still rapidly evolving (for example, SPDX released a new major version of their standard in April 2024). To avoid locking the Python ecosystem into a specific standard ahead of when a clear winner emerges this PEP treats SBOM documents as opaque and only makes recommendations to promote compatibility with downstream consumers of SBOM document data.</p> <p>None of the decisions in this PEP restrict a future PEP to select a single SBOM standard. Tools that use SBOM data today already need to support multiple formats to handle this situation, so a future standard that updates to require only one standard would have no effect on downstream SBOM tools.</p> </section> </section> <section id="open-issues"> <h2><a class="toc-backref" href="#open-issues" role="doc-backlink">Open Issues</a></h2> <section id="conditional-project-source-sbom-files"> <h3><a class="toc-backref" href="#conditional-project-source-sbom-files" role="doc-backlink">Conditional project source SBOM files</a></h3> <p>How can a project specify an SBOM file that is conditional? Under what circumstances would an SBOM document be conditional?</p> </section> </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <ul class="simple"> <li><a class="reference external" href="https://sethmlarson.dev/visualizing-the-python-package-sbom-data-flow">Visualizing the Python package SBOM data flow</a>. This is a graphic that shows how this PEP fits into the bigger picture of Python packaging’s SBOM data story.</li> <li><a class="reference external" href="https://sethmlarson.dev/early-promising-results-with-sboms-and-python-packages">Adding SBOMs to Python wheels with auditwheel</a>. This was some early results from a fork of auditwheel to add SBOM data to a wheel and then use an SBOM generation tool Syft to detect the SBOM in the installed package.</li> </ul> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> <p>Thanks to Karolina Surma for authoring and leading <a class="pep reference internal" href="../pep-0639/" title="PEP 639 – Improving License Clarity with Better Package Metadata">PEP 639</a> to acceptance. This PEP copies the specification from <a class="pep reference internal" href="../pep-0639/" title="PEP 639 – Improving License Clarity with Better Package Metadata">PEP 639</a> for specifying files in project source metadata, Core Metadata, and project formats is based on.</p> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> <p>This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.</p> </section> </section> <hr class="docutils" /> <p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0770.rst">https://github.com/python/peps/blob/main/peps/pep-0770.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0770.rst">2025-02-20 18:13:09 GMT</a></p> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a><ul> <li><a class="reference internal" href="#measurability-and-phantom-dependencies">Measurability and Phantom Dependencies</a></li> <li><a class="reference internal" href="#build-tools-environment-and-reproducibility">Build Tools, Environment, and Reproducibility</a></li> <li><a class="reference internal" href="#regulations">Regulations</a></li> </ul> </li> <li><a class="reference internal" href="#rationale">Rationale</a><ul> <li><a class="reference internal" href="#using-sbom-standards-instead-of-core-metadata-fields">Using SBOM standards instead of Core Metadata fields</a></li> <li><a class="reference internal" href="#zero-or-more-opaque-sbom-documents">Zero-or-more opaque SBOM documents</a></li> <li><a class="reference internal" href="#what-are-the-differences-between-pep-770-and-pep-725">What are the differences between PEP 770 and PEP 725?</a></li> </ul> </li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#terminology">Terminology</a></li> <li><a class="reference internal" href="#core-metadata">Core Metadata</a><ul> <li><a class="reference internal" href="#add-sbom-file-field">Add <code class="docutils literal notranslate"><span class="pre">Sbom-File</span></code> field</a></li> </ul> </li> <li><a class="reference internal" href="#project-source-metadata">Project source metadata</a><ul> <li><a class="reference internal" href="#add-sbom-files-key">Add <code class="docutils literal notranslate"><span class="pre">sbom-files</span></code> key</a></li> </ul> </li> <li><a class="reference internal" href="#sbom-files-in-project-formats">SBOM files in project formats</a></li> <li><a class="reference internal" href="#sbom-data-interoperability">SBOM data interoperability</a></li> </ul> </li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li> <li><a class="reference internal" href="#security-implications">Security Implications</a></li> <li><a class="reference internal" href="#how-to-teach-this">How to Teach This</a><ul> <li><a class="reference internal" href="#what-do-python-package-maintainers-need-to-know">What do Python package maintainers need to know?</a></li> <li><a class="reference internal" href="#what-do-sbom-tool-authors-need-to-know">What do SBOM tool authors need to know?</a></li> <li><a class="reference internal" href="#what-do-users-of-sbom-documents-need-to-know">What do users of SBOM documents need to know?</a></li> </ul> </li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#why-not-require-a-single-sbom-standard">Why not require a single SBOM standard?</a></li> </ul> </li> <li><a class="reference internal" href="#id1">Rejected Ideas</a><ul> <li><a class="reference internal" href="#selecting-a-single-sbom-standard">Selecting a single SBOM standard</a></li> </ul> </li> <li><a class="reference internal" href="#open-issues">Open Issues</a><ul> <li><a class="reference internal" href="#conditional-project-source-sbom-files">Conditional project source SBOM files</a></li> </ul> </li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <br> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0770.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>