How to reduce false positives in security scans

December 15, 2025
Miro Hrončok
Related topics:
LinuxPythonSecurity
Related products:
Red Hat Enterprise Linux

If you've ever run a security scanner on a containerized Python application built on Fedora or Red Hat Enterprise Linux (RHEL), you might have encountered a frustrating problem: the scanner flags your setuptools or pip installation as vulnerable to a CVE that's already been patched in your RPM package. The problem? Security scanners typically only see the upstream Python package version number, not the fact that you're running a backported, security-patched version from your distribution.

We're experimenting with a solution to this problem in Fedora Rawhide, and we'd like your feedback.

The problem

Version numbers don't tell the whole story. In stable Fedora releases and RHEL, the versions of setuptools and pip are often relatively old compared to upstream. However, these packages include backported security fixes. When you create a Python virtual environment in a container, security scanning tools see the version number and flag it as vulnerable—even though the actual code contains the necessary patches.

For example, a scanner might detect setuptools 65.5.1 and flag it as vulnerable to CVE-2024-6345, without realizing that the RPM package python3.11-setuptools-65.5.1-3.el9 has already mitigated that vulnerability.

The solution

We're now including the Software Bill of Materials (SBOM) information directly in Python wheels packaged as RPMs in Fedora Rawhide. The SBOM data is injected into the wheels when we build them in our rpmbuild infrastructure. This metadata allows security scanners and other tools to identify that a Python package was installed from a specific Fedora or RHEL RPM-packaged wheel, complete with version and release information.

Here's what that looks like in practice. Without SBOM, a scanner sees the following:

$ cat /opt/app-root/lib/python3.11/site-packages/setuptools-65.5.1.dist-info/METADATA | grep Name -A1
Name: setuptools
Version: 65.5.1

With SBOM included, the scanner could also read as follows:

$ cat /opt/app-root/lib/python3.11/site-packages/setuptools-65.5.1.dist-info/sboms/bom.json 
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "python3.11-setuptools",
      "version": "65.5.1-3.el9",
      "purl": "pkg:rpm/redhat/python3.11-setuptools@65.5.1-3.el9?arch=src"
    }
  ]
}

The key is the purl (package URL) field, which provides a standardized way to identify the package as originating from a specific RPM. Security scanners can use this information to check CVE databases and see that python3.11-setuptools-65.5.1-3.el9 is not vulnerable, even though upstream setuptools 65.5.1 might be.

Note: The previous RHEL example is hypothetical. This feature is not yet available in RHEL and exists only in Fedora Rawhide as a technological preview.

Try it in Fedora Rawhide

This feature is currently available as a technology preview in Fedora Rawhide (the development version of Fedora) and is subject to change. Right now, we're only packaging wheels for pip and setuptools—the minimal set needed to create Python virtual environments.

You can test it using a Fedora Rawhide container:

$ podman run --rm -ti fedora:rawhide
bash-5.3# dnf install python3.11
...
bash-5.3# python3.11 -m venv venv
bash-5.3# cat venv/lib/python3.11/site-packages/setuptools-80.9.0.dist-info/sboms/bom.json 
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "python-setuptools",
      "version": "80.9.0-1.fc44",
      "purl": "pkg:rpm/fedora/python-setuptools@80.9.0-1.fc44?arch=src"
    }
  ]
}

This works the same way with other Python versions.

The SBOM data is included according to PEP 770, which defines a standard location for SBOM information in Python packages. We're currently using the CycloneDX SBOM format, though this choice isn't set in stone. It was selected as a quick proof of concept rather than after an exhaustive analysis of all available SBOM standards.

We welcome your feedback

We're sharing this technology preview to raise awareness and gather feedback from the developer community, particularly from security scanner vendors and tool maintainers. If you're interested in seeing this feature in a future RHEL release, have concerns about the approach, or want to test integration with your scanning tools, we'd love to hear from you.

You can start a public discussion on the Fedora Python mailing list or reach us privately at python-maint@redhat.com. Your feedback will help us determine priorities and shape the future direction of this feature. Give it a try and let us know what you think!