Defines the formal data models for SBOMs and identifies the '97% False Positive' hurdle in standard transitive dependency scanning.
A Software Bill of Materials (SBOM) is a formal tuple (C, R, M) enumerating components, relationships, and metadata, yet its real-world adoption remains alarmingly low: only 0.56% of popular GitHub repositories and 0.5% of Maven Central releases include policy-driven SBOMs. Data accuracy is a critical barrier, with static manifest-based generation (e.g., package.json) yielding only 48-75% recall, while lock-file–centric workflows (e.g., poetry.lock) achieve perfect 1.0 recall similarity. Most critically, package-level SBOM scanners produce a 97.5% false positive rate by reporting vulnerabilities in unreachable code paths. Empirical studies show that overlaying function call graphs can reduce this noise by over 60%, establishing reachability analysis as a mandatory requirement for actionable SBOM consumption.
Package-level scanners produce a false positive rate up to 97.5%, primarily due to reporting vulnerabilities in code paths never invoked by the application.
Risk Guard identifies vulnerable packages but does not perform 'Code Reachability' analysis to determine if the vulnerable function is actually executable.
Risk Guard would be better if it integrated a 'Reachability Filter' to prioritize vulnerabilities located in functions that are actually called by the application's code.