The Danger of Relying Solely on SBOM Scanning¶
Many tools focus exclusively on scanning Python packages and their dependencies against public vulnerability databases. While useful, this approach has significant limitations.
Known vulnerabilities are typically tracked in databases such as the U.S. National Vulnerability Database (NVD) and catalogued using Common Vulnerabilities and Exposures (CVE) identifiers. Many open-source vulnerabilities are also aggregated in Google’s OSV database.
The Software Bill of Materials (SBOM) has become the standard way for tools to list components and match them against known vulnerabilities. However, relying solely on SBOM-based scanning has notable drawbacks.
For example, many Python applications are dynamically composed. Their actual runtime dependencies can vary depending on the environment, configuration, platform, or even runtime conditions. An SBOM generated during build time may therefore differ significantly from what is actually running in production.
This is why validating the Operational Bill of Materials (OBOM) — which reflects the real runtime environment — is increasingly important.
Key Limitations of Vulnerability Scanning in Python¶
Relying only on checks against known vulnerabilities (CVEs, OSV, etc.) creates a false sense of security. This approach has several fundamental weaknesses:
Incomplete Coverage
The vast majority of security issues in software are never publicly disclosed or assigned a CVE. Vulnerability scanners can only detect what is already known — leaving your project exposed to zero-days and undisclosed flaws.Problems with Vulnerability Databases
The CVE/NVD ecosystem is inconsistent, slow to enrich new entries, and suffers from variable data quality. Many vulnerabilities lack detailed analysis, severity scores, or patch information.Complex and Cross-Language Dependencies
Python projects often have deep, intricate dependency trees. Many core packages include (or rely on) compiled extensions written in C, C++, or Rust. Not all scanners accurately resolve these mixed-language dependencies, creating blind spots.Historical Nature of Checks
Vulnerability scanning is inherently backward-looking. It cannot detect new malicious code introduced via supply chain attacks during build, deployment, or runtime.Context and Remediation Challenges
Even when a known vulnerability is found, determining its real impact in your specific application context — and choosing the right remediation — requires significant expertise and effort.
Recommended Approach¶
Never rely exclusively on known-vulnerability scanners (SBOM or otherwise). They provide necessary but insufficient protection.
Always combine them with a capable SAST tool that analyses your source code for potential weaknesses (e.g., unsafe use of
eval(), injection risks, hardcoded credentials, improper permissions, etc.).If needed: Generate and validate both SBOMs (build-time) and OBOMs (runtime) for a more complete picture.
This layered approach — known vulnerability scanning + static code analysis + runtime validation — gives you a far more robust security posture for Python applications.