In the past several years, organizations worldwide have found that a software bill of materials (SBOM) is essential for understanding application security. By cataloguing software components and dependencies, an SBOM lets organizations spot potentially vulnerable code and gauge software-supply-chain risks.
Yet an SBOM provides only part of the picture. It tells you which pieces of software an application contains, but not necessarily what executes within that application during runtime.
A runtime bill of materials (RBOM) adds that missing perspective by showing which software components applications actually use — and which can be discarded to reduce the potential attack surface.
When used together, SBOMs and RBOMs give security teams a clearer understanding of software usage and code dependencies. This helps prioritize vulnerability management, eliminate unnecessary code and minimize exposure to known risks.
"An SBOM catalogs everything in the kitchen: every utensil, ingredient, and appliance available for use," writes RapidFort solutions architect Jacob Mammoliti in a recent blog post. "The RBOM is the finished cake, reflecting only what was actually used in production."
Why an RBOM is necessary, and how it complements an SBOM
Modern applications fold in extensive amounts of code from open-source libraries and packages, creating a long list of third- and fourth-party dependencies. An SBOM inventories all those components, including bits that may never be executed by an application that incorporates them.
Yet conventional vulnerability scanning is thorough. It will generate alerts for all weaknesses in an application, even those found in unused software. Patching vulnerabilities in idle software is a waste of time and effort, but it doesn't address the most immediate risks.
An RBOM sheds light on this problem. It tells you the difference between components that are merely present in an application and those that are executed during runtime. What's not used can be ignored or neutralized, letting security teams focus on patching only actively used components.
To go one step further, the unused code can be discarded, optimizing the software so that only the components necessary for the application to run remain.
"Software is 100% optimized when it contains only those components necessary to run," writes RapidFort Co-founder & COO Russ Andersson in a recent blog post. "Currently, the average software container is only ~20% optimized, meaning 80% of the code is not used, and must be maintained."
An application that has stripped out 80% of its code has correspondingly reduced its potential attack surface. As Andersson puts it, "The more software you have, the more risk you have."
However, an RBOM does not replace an SBOM. Instead, the two are complementary. The SBOM documents the complete software inventory, while the RBOM provides evidence of runtime usage.
Think of an SBOM as a still photograph of an application's software inventory. An RBOM adds motion and turns that photo into a movie, showing you what happens when the application runs.
How to generate an RBOM using RapidFort Profiler
RapidFort's Profiler tool generates RBOMs by observing container workloads and identifying which software components execute and which code paths are activated.
The process begins with an SBOM and a vulnerability baseline. Profiler then monitors application activity, distinguishing active dependencies from dormant libraries and packages.
The resulting RBOM helps identify unnecessary components. In the next step, RapidFort's Optimizer tool can remove excess code and harden container images.
"One Python graphics library used by a RapidFort customer had over 3,200 packages installed, yet only 200 were actually used at runtime," writes RapidFort Vice President of Product Delivery and Operations Saty Sundarram in a blog post. "This does not imply that the remaining packages were malicious or without value — only that they were not used in that deployment."
The removal of unnecessary packages produces leaner software images, which in turn reduce the number of potential vulnerabilities and simplify remediation.
"If your platform or product uses 80% of its footprint for unused components — and 95% of your vulnerabilities reside there — it may be time to deploy an RBOM," writes Sundarram.
How RapidFort Runtime extends the RBOM concept into live production
An RBOM generated during application development and testing provides valuable evidence, but production environments continue changing after deployment. Applications load new libraries, download new dependencies, create new processes and receive updates, and new vulnerabilities may emerge.
RapidFort's latest tool, Runtime, extends the RBOM's execution-aware analysis into continuously operating production workloads. It observes processes, system calls, loaded libraries, network connections and file changes without requiring application-code modifications.
"When a new vulnerability is disclosed, the platform evaluates the vulnerability against the software observed in production," writes RapidFort CTO and Co-founder Rajeev Thakur in a blog post. "It can identify affected workloads, determine whether the relevant components are present or executing, and provide supporting runtime evidence."
This continuous visibility supports faster investigation, more targeted remediation and stronger evidence of software integrity.
Together, SBOMs and RBOMs connect dependencies with operational evidence, letting security teams prioritize meaningful risks and eliminate unnecessary components. RapidFort Runtime extends visibility into production as applications and dependencies evolve.
Going back to the movie metaphor, RapidFort Runtime turns the moving picture into a continuously updated record of production activity, revealing changes in dependencies and application behavior as they occur.
And just as a film editor cuts unnecessary footage, RapidFort's optimization capabilities can help remove unused code, producing leaner, more secure applications.
