Unused software components represent a significant and often overlooked source of vulnerability risk in containerized environments. A Software Bill of Materials (SBOM) and a Runtime Bill of Materials (RBOM) are not opposed tools but complementary ones, each serving a different purpose. An SBOM catalogs everything in the kitchen: every utensil, ingredient, and appliance available for use. The RBOM is the finished cake, reflecting only what was actually used in production. RBOM analysis identifies non-required components, libraries, and parts, while the SBOM includes every build component. AI-assisted development tools often introduce oversized dependency trees without regard for production end states, widening the gap between what is installed and what is needed. This article starts with a real-world example, explores how SBOM and RBOM practices work together, and shows how the RapidFort Platform aligns both to accelerate compliance and reduce attack surface.
Real-World Container Malware
The XZ Utils Backdoor (CVE-2024-3094) introduced a malicious backdoor into the widely used xz compression library. This backdoor enabled remote code execution via OpenSSH, granting system access. The code hid in auxiliary files and build scripts, remaining dormant until specific runtime conditions were met. Thus, the code was present in the initial SBOM but would not have been called during runtime, meaning it would not appear in the RBOM. According to RapidFort scan data, open-source Docker images were still found to include this backdoor more than 12 months after initial disclosure. Using an SBOM/RBOM comparison would have highlighted the vulnerability and allowed users to make adjustments early.
Key insight: CVE-2024-3094 existed in the image and appeared in the SBOM. It never executed at runtime, so it was absent from the RBOM. This installed-vs-executed distinction is precisely what SBOM/RBOM comparison surfaces, and why both tools together are more powerful than either alone.
SBOMs and RBOMs Explained
SBOMs contain a component list, as a software artifact, to include libraries, dependencies, and third-party code. These items provide a nested inventory of all software components and ingredients within a delivered product or system. For compliance, the term SBOM only appears in EO 14028, "Improving the Nation's Cybersecurity," under section 4, directing the federal government to enhance software supply chain security. The chart below suggests how SBOM processes are required across several different compliance standards despite the lack of explicit references.
SBOMs are static, tracking all ingredients present in the kitchen rather than what actually went into the cake. Thus, we move to RBOMs.
What RBOMs add that SBOMs cannot
RBOM tooling provides product-focused, execution-aware artifacts, revealing which software elements actually execute during build, test, and production. No compliance standard explicitly requires an RBOM, but FedRAMP and NIST 800-53 require runtime visibility into operations. CMMC 2.0 and SOC 2 are trending toward requiring runtime visibility but are defined as operational risk. RBOMs provide development and architectural insight, allowing one to filter out CVEs in unused items, as in the XZ Utils instance, and minimize the need for engineering time to patch unnecessary items. The RBOM artifact allows minimizing the SBOM, reducing audit areas, and improving focused remediation. It is important to remember that RBOM provides a foundation for container image vulnerability remediation tools aligned with frameworks like FedRAMP, DISA STIGs, and NIST 800-53.
Using SBOM and RBOM together
These examples show using an SBOM and RBOM in close conjunction. One obtains an initial SBOM, sets the kitchen, and creates an RBOM from baking the cake, thus revealing what items were not needed. In software, the RapidFort Platform's SBOM/RBOM comparison eliminates up to 99.9% of exploitable CVEs and reduces attack surface by up to 90%. The RapidFort Platform provides a path to reach these goals.
Every utensil, ingredient, and appliance you own. Complete. Static. Present regardless of whether you bake today or not.
Only what actually went into the recipe. Dynamic. Execution-aware. Reveals what was unnecessary and what can be removed.
The RapidFort Platform
The RapidFort Platform focuses on three areas to reduce CVEs and the attack surface. Named RF components run at the command line interface or behind interactive dashboard commands.
The first step applies RF Analyzer to scan and profile the customer container environment. Functions focus on reducing noise, accelerating remediation, and providing continuous coverage across multiple environments. This step baselines container risk, reconciles CVEs across multiple scanners, and identifies unauthorized software components. Based on RapidFort customer data, these actions result in approximately 20% fewer false positives compared to traditional scanners and can lead to approximately 60% reduction in manual remediation effort. Scanning happens with built-in intelligence and SLA violation visibility to enable faster remediation cycles. RF Analyzer also provides Curated Image Swap Suggestions, enabling users to replace existing images with near-zero-CVE alternatives.
The next step uses RF Profiler to identify software usage and attack surfaces through RBOM profiling of container workloads. RF Profiler identifies exactly which components execute in production, distinguishing active code paths from dormant layers. It is designed for agentless runtime profiling with minimal CPU overhead in standard Kubernetes workloads (under 1%) and is easily deployed via a Helm chart into Kubernetes clusters with no application changes required.
RF Optimizer hardens images, code, and components by automating the removal of excess code, libraries, and functions. For most LTS distributions, RapidFort provides curated or hardened images that align with STIG and CIS benchmarks. RF Optimizer requires no CI/CD changes and provides continuous hardening to seamlessly replace existing base images across the workflow. In some cases, there may be an issue that removing unused code turns on a CVE due to removing information from the code-base; these issues are addressed with the RapidFort validated vulnerability advisory dataset, which identifies false positives and corrects upstream inaccuracies for compliance.
Figure 1. RapidFort platform flow: SBOM inventory through RBOM comparison, image hardening, and automated compliance artifact generation via RF-CART.
RF CART
The final solution is RF CART. RapidFort's dynamic Compliance and Remediation Tool (CART) engine detects non-compliance and recommends, or applies, secure baselines to align systems with organizational and federal standards. Built on OpenSCAP, it continuously validates workloads against DISA STIGs, CIS Benchmarks, and NIST 800-53 controls. RF CART works on both VM and container levels and generates reports that can feed POA&M and control systems, automating compliance for monthly self-attestation requirements.
Summary
When RF compares SBOM and RBOM, we see an opportunity for improvement. Our comparison results in the elimination of up to 99.9% of exploitable CVEs, up to a 90% reduction in attack surface, and clearly identifies changes. Our cakes are better, our kitchen is cleaner, and engineering teams can move on to the next task rather than patching unused software. If you are interested in increasing your product value and decreasing the time you spend on compliance paperwork by securing containers, Docker images, and Kubernetes deployments with RapidFort, contact our team for a demo.
%20(1).jpg)
%20(5).png)
