Why Runtime SBOMs? 5 Keys to Securing Your Software Supply Chain at Runtime

\n

Software Security: Do We Really Know What Software Is Running in Production?

The moment a new vulnerability is disclosed, security teams typically ask one question first:

“Is the affected library present in our systems?”

The problem is that answering this question immediately—and with certainty—is more difficult than it may seem. Build records may indicate that a specific version of a library was included, and deployment documentation may be properly maintained. However, that information alone cannot definitively prove which code is actually loaded and running on production servers right now.

For example, the following variables may arise in a production environment:

• A specific module was loaded after deployment due to a configuration change
• A plugin, agent, or dynamic library was injected at runtime
• Different dependencies were activated due to configuration differences between development, staging, and production environments
• A component that was not included in the container image was referenced because it remained in the server environment
• Emergency patches or manual changes caused the actual production state to differ from the build artifact

An SBOM generated at build time is an important starting point, but it may not provide a complete picture of reality in the production environment. While a build-time SBOM explains “what was built,” what security teams truly want to know during incident response is “what is actually running.”

This is precisely where the Runtime SBOM comes in.

A Runtime SBOM is an approach that collects and organizes, in SBOM format, information about the libraries, binaries, packages, plugins, and other components actually loaded while an application or container is running. In other words, it is less a static deployment specification and more a living software inventory of the system in operation.

This approach is especially powerful when a new vulnerability is disclosed. Security teams can go beyond simply checking whether the affected library exists in a repository or image and verify questions such as:

• Is the vulnerable library actually running on production servers?
• Which services and instances are affected?
• Are modules that were not approved at build time present in the production environment?
• Does the current runtime configuration match the approved SBOM and deployment policies?

This significantly changes the perspective of Software Security. Security is no longer complete with activities limited to inspecting code during development and blocking vulnerabilities before deployment. It must also include continuously verifying the actual state of the production environment and identifying differences between build results and runtime results.

Ultimately, the core value of a Runtime SBOM lies not simply in generating a list. It is a technology for determining whether an organization truly understands the software it operates—and how quickly it can detect signs of compromise, vulnerabilities, or unauthorized changes.

The Gap Between Build Records and Runtime Reality: A Blind Spot Software Security Can Easily Miss

You built from the same source code and even generated an SBOM in the CI/CD pipeline. So does that mean the production server is running only the components listed in that SBOM?

Reality is more complicated. Development, validation, and production environments may have different configurations, plugins, environment variables, container images, and external libraries. An SBOM stored in a repository shows “what was built,” while the production environment shows “what is actually running.”

This gap has become one of the most challenging blind spots in modern Software Security and supply chain security.

What a Build-Time SBOM Tells You—and What It Cannot

A build-time SBOM analyzes source code, package managers, container images, and build artifacts to create a list of components. Based on dependency information from tools such as Gradle, npm, and Maven, it records library names, versions, licenses, and transitive dependencies.

This approach is particularly effective at answering questions such as:

• Which open-source components and libraries were included in the build?
• Does the build contain packages with known vulnerabilities?
• Were any unapproved licenses used?
• Can policy violations be blocked before deployment?

However, a build SBOM alone cannot fully account for every variable in the production environment. In particular, the records and reality may diverge in situations such as:

• External JARs, native libraries, or plugins that exist only on production servers
• Modules that are selectively activated depending on the environment-specific configuration
• Components downloaded or mounted after a container starts
• Patch files added by administrators during emergency remediation
• Libraries dynamically loaded at the application-server or operating-system level
• Base images and runtime environments changed after the build

In other words, even when an SBOM is generated accurately, it may only be a document describing the result of a build at a specific point in time. It is not proof that guarantees which code is actually loaded into memory and invoked on the production server.

A build SBOM is closer to a blueprint, while a Runtime SBOM is closer to an inspection checklist for a building currently in operation.

Why Do “Repository Records” and “Production Facts” Diverge?

A development environment may use the latest library, while production continues to use an older version for compatibility reasons. Conversely, a specific module may be temporarily replaced to resolve a production incident, or an external solution may inject additional libraries.

Differences can arise in container environments as well. A configuration that was secure when the image was created may later receive new files through volume mounts, initialization scripts, or integrations with external registries. In Java applications, code that was not clearly visible during the build may also be executed depending on application-server settings, the classpath, and the plugin architecture.

This issue becomes even more apparent during vulnerability response. When a new CVE is announced, security teams are not simply asking, “Have we ever acquired or built the vulnerable library?”

The questions they actually need to answer are:

1. Does the vulnerable component exist on a server currently operating in production?
2. If it exists, is it actually being loaded or executed?
3. Which service, version, and container is using it?
4. Is there any unauthorized difference between the build-time SBOM and the production environment?
5. Which targets need to be patched immediately?

If these questions cannot be answered quickly, vulnerability response becomes a broad, estimation-based exercise across the entire system. By contrast, understanding runtime reality enables risk-based response, allowing teams to prioritize the targets that pose the greatest actual risk.

The Final Gap That Runtime SBOMs Close

A Runtime SBOM is an approach that collects the components actually loaded while an application is running and manages them in SBOM form. By using agents or runtime hooks, organizations can observe binaries, libraries, packages, plugins, and configuration information, then compare them with the build-time SBOM.

The key point is not to replace the build SBOM. The two SBOMs answer different questions.

| Category | Build-Time SBOM | Runtime SBOM | |---|---|---| | Reference point | Before build, packaging, and deployment | During execution and operation | | Core question | What was built? | What is actually running? | | Primary data | Dependency trees, build artifacts, image contents | Loaded libraries, executing modules, runtime configuration | | Main uses | Pre-deployment policy validation and proactive vulnerability blocking | Runtime anomaly detection, forensics, and actual impact analysis | | Representative risks | Dynamic loading and runtime changes may not be reflected | Performance overhead and management of collection scope and accuracy |

For example, if a library not present in the build SBOM is discovered on a production server, this may be more than a simple asset omission. It should be treated as a signal to investigate unauthorized changes, faulty deployments, vulnerable plugins, or signs of a supply chain compromise.

Conversely, if a vulnerable library is recorded in the build SBOM but the corresponding module was never deployed or loaded in the production environment, response priorities can be adjusted more precisely.

What Should You Trust? Not One or the Other, but a “Verifiable Connection”

Organizations do not need to choose between the SBOM in the repository and the Runtime SBOM from the production server. What they need to trust is a verifiable flow that connects the two sets of data.

• Generate a build SBOM from source code and dependency information
• Sign the build artifacts and the SBOM
• Verify integrity and policy compliance throughout the deployment process
• Confirm the actual runtime configuration with a Runtime SBOM
• Continuously analyze the differences between the two results

When this connection is in place, an organization can move beyond claiming, “We built with secure libraries.” It can also prove that “the service currently running in production is operating with an approved configuration.”

Ultimately, the essence of Software Security is not about producing more documents. It is about detecting the difference between build records and runtime reality—and controlling that difference before it turns into a security risk.

XSCAN Server Runtime and Software Security: Turning the Moment of Execution into Evidence

If organizations could automatically capture which code is actually running on production servers and use the results for vulnerability and integrity verification, the standard for software supply chain security would change. That is because they could verify the reality of systems currently serving users—not merely rely on a list created at build time.

In Korea, RedPenSoft’s XSCAN Server Runtime presents this Runtime SBOM approach as a commercial solution. The concept is straightforward: identify the libraries, packages, modules, plugins, and other components loaded when an application runs, then organize them into an SBOM to verify the composition of the production environment.

The Gap Between Build Artifacts and Production Reality

Traditional Build-time SBOMs are critically important throughout development and deployment. By analyzing source code and dependency files, they document which open-source components and libraries are included and enable vulnerability scanning within CI/CD pipelines.

However, it is difficult to assume that the production environment is always exactly identical to the build artifact.

• Specific modules may be dynamically loaded depending on environment-specific settings.
• Plugins, native libraries, and external agents may be added to production servers.
• Emergency patches or manual configuration changes may result in a running configuration that differs from the one deployed originally.
• In containerized and virtualized environments, the actual runtime configuration may vary depending on the combination of images, runtimes, and configuration values.

This is where Runtime SBOMs play a crucial role. Rather than stopping at documenting “what was built,” they provide operational security data that proves “what is currently running.”

Turning Running Components into a Security Inventory

Approaches such as XSCAN Server Runtime focus on collecting components actually loaded on production servers or within application runtimes, then generating an SBOM based on that real-time execution state.

The resulting Runtime SBOM can help answer questions such as:

• Which open-source components and libraries are actually being used by the current service?
• When a specific vulnerability is disclosed, is the affected component present on the production server?
• If it is present, is it merely installed—or is it actually running and loaded?
• Have modules or unauthorized components not included in the build-time SBOM been added?
• Do the configuration and integrity details of the deployment artifact match those of the production environment?

For example, when a critical open-source vulnerability is disclosed, organizations often have no choice but to conduct broad searches across their entire asset inventory. With a Runtime SBOM, however, they can more quickly narrow the scope by determining whether the library is actually loaded by a running service, which version is in use, and which systems require immediate attention.

From Vulnerability Assessment to Integrity Verification

The value of Runtime SBOMs extends beyond vulnerability identification. Supply chain attacks can also occur when malicious modules are inserted outside the normal build and deployment process, or when components in the production environment are tampered with.

Comparing runtime configuration data with SBOMs generated during the build and deployment stages can therefore help identify anomalies such as the following:

| Verification Target | Security Significance | |---|---| | Differences between the Build SBOM and Runtime SBOM | Identifying unauthorized modules, missing components, and environment-specific changes | | Library version information | Determining whether vulnerable versions are actually in use and prioritizing patches | | Executable and package integrity | Checking for possible tampering or abnormal replacement | | Configuration and runtime environment information | Tracking security risks that occur only in production | | SBOM signing and verification information | Strengthening the trustworthiness of component inventories and the traceability of their distribution |

With this verification framework in place, security teams can move beyond asking, “Is a vulnerable package installed?” and address the far more practical question: “Is vulnerable code running in this service right now?” This is why Runtime SBOMs are gaining attention from a Software Security perspective.

The Production Stage Fills the Final Gap in Supply Chain Security

Supply chain security is not complete with development-stage SAST, SCA for open-source analysis, pre-deployment image scanning, and CI/CD policy verification alone. Software ultimately meets users in production, and that is where attacks become reality.

Runtime SBOMs connect the security information accumulated during development, build, and deployment to the production stage. In other words, they can serve as a mechanism for verifying whether the chain of trust created by DevSecOps remains intact in the actual service environment.

However, several factors should be considered during implementation:

• The impact of runtime collection agents or monitoring functions on service performance
• The scope of visibility across environments involving Java, native binaries, containers, and dynamic plugins
• Interoperability with standard SBOM formats such as CycloneDX and SPDX, as well as existing security tools
• The accuracy of collected SBOMs and the reliability provided by digital signatures
• The response process that follows vulnerability detection, including ownership assignment, patching, exception approval, and re-verification

Ultimately, the message presented by XSCAN Server Runtime is clear: supply chain security can no longer stop at “scanning before deployment.” Securing and verifying the actual runtime configuration as evidence at the moment of execution is becoming the new Software Security standard—one centered on the production environment.

A Software Security Strategy for Turning SBOMs into a Trust Framework, Not Just a List

Simply creating an SBOM does not make a system secure. Inaccurate inventories, unverified sources, and unsigned files can instead create the illusion that “security is being managed.” True Software Security begins when an SBOM is treated not as a mere document, but as a trust framework that can be tracked and verified from creation through deployment, operation, and retirement.

An Accurate SBOM Is the Starting Point for Security Response

The first requirement for an SBOM is accuracy. If components that are not actually included appear on the list—or if libraries running in production are missing—the priorities for vulnerability response become distorted. In particular, transitive dependencies, container base images, runtime plugins, and dynamically loaded modules are easy to miss through static analysis alone.

Organizations should therefore manage SBOMs generated during the build phase as foundational assets, while continuously supplementing them with Runtime SBOMs verified in production environments.

• Build-time SBOM: Identifies components based on source code, package managers, and build artifacts.
• Deployment-time validation: Confirms that the images, packages, and binaries being deployed match the approved SBOM.
• Runtime SBOM: Verifies the libraries and modules actually loaded on servers or inside containers.

Only when these three outputs are connected can an organization explain not only “what was built,” but also “what is actually running.”

The Origin and Change History Must Be Proven

Recording only a library’s name and version in an SBOM is not enough. It must also be possible to trace where the component came from and what process it went through before being included in the product.

For example, even when two open-source packages have the same version, their level of trust may differ depending on whether one was downloaded from an official repository, passed through an internal mirror, or was an arbitrarily modified file provided by a developer. Supply chain attackers may infiltrate systems by using names similar to legitimate packages or by injecting malicious code into the build process.

To reduce these risks, the following information should be linked to the SBOM and deployment metadata:

• Component name, version, and hash value
• Package supplier and download path
• Build tools and build environment used
• Build time, responsible pipeline, and approval history
• Target server, container image, and service version
• Reason for the change and records of exception approvals

The key is not merely to say, “This library exists,” but to prove that “This library came from a trustworthy source and was deployed through an approved process.”

The SBOM Itself Must Be Protected with Digital Signatures

An SBOM is also an important security asset. If an attacker tampers with the SBOM file, they could conceal vulnerable components or add false information, clouding the security team’s judgment. For this reason, the SBOM’s integrity must be protected from the moment it is generated.

In practice, organizations may consider the following process:

1. Generate the build artifacts and SBOM together in the CI/CD pipeline.
2. Apply a digital signature or hash to the generated SBOM.
3. Store the binary, container image, SBOM, and signature information together in the artifact repository.
4. Verify the hashes and signatures of the image and SBOM during deployment.
5. Collect a Runtime SBOM in the production environment and compare it with the approved configuration.

With this structure in place, organizations can verify step by step whether the deployment target is an approved artifact, whether the SBOM has been altered after creation, and whether the actual production environment complies with policy.

An SBOM Is Not a One-Time Deliverable but a Lifecycle Asset

Vulnerability information is constantly changing. A library that is safe today may become an immediate target for review tomorrow when a new CVE is disclosed. An SBOM is therefore not a document to be created once and stored away; it is a lifecycle asset that must be continuously updated, verified, and retired.

An effective management framework requires the following:

• Version control: Preserve SBOMs for each application release and compare the differences between them.
• Vulnerability correlation: Automatically cross-analyze newly disclosed vulnerabilities against the SBOM inventory.
• Policy management: Detect prohibited licenses, end-of-support components, and high-risk packages.
• Exception management: Record compensating controls and expiration dates for vulnerabilities that cannot be remediated immediately.
• Retirement management: Apply retention policies to related SBOMs and evidence when a service is decommissioned or a component is replaced.

In production environments especially, Runtime SBOMs must be used to identify unauthorized modules, outdated libraries, and configuration differences between environments. This is more than documentation for audit responses—it is an operational security activity that directly reduces the real attack surface.

Trustworthy SBOMs Are Completed by Operational Visibility

The ultimate question of software supply chain security is simple: “What is running on this system right now, and can it be trusted?”

By connecting build-stage SBOMs, signed deployment artifacts, and Runtime SBOMs collected during operation, organizations can answer this question with far greater accuracy. Development teams can reduce the use of unauthorized dependencies, security teams can quickly assess the impact of vulnerabilities, and operations teams can identify gaps between the actual server configuration and organizational policies.

Ultimately, the value of an SBOM does not lie in the length of its list. Only when its creation path is verified, its change history is preserved, and it is connected to deployment and runtime environments does an SBOM become the foundation of trust that protects the software supply chain.

Software Security: The Operations Team’s Next Question—How Much Real-Time Visibility Is Enough?

Runtime SBOM may seem like the final piece of the supply chain security puzzle. That is because it goes beyond dependency lists recorded at build time to reveal the code actually loaded and executed in production environments. However, expanding the scope of observation does not automatically complete the security picture.

Continuously analyzing running servers and containers requires agents, runtime hooks, and log-collection systems. Along the way, teams must also manage performance overhead, explosive data growth, false positives and omissions, and the potential exposure of personal information and confidential configuration values. Ultimately, operations teams must answer two questions:

What should we collect?
And how far can we trust the information we collect?

Broader Visibility Is Not Always Better

The accuracy and operational cost of a Runtime SBOM can vary significantly depending on what is collected. For example, in a Java-based service, teams may observe JAR files, class loaders, external libraries, and application-server plugins. In container environments, the scope may include image layers, running processes, mounted volumes, and packages downloaded dynamically at runtime.

However, collecting every element at the same level of detail can quickly increase operational complexity.

| Observation Target | What It Can Reveal from a Security Perspective | Operational Considerations | |---|---|---| | Packages and libraries | Open-source components and versions actually in use | Indirect dependencies and duplicate packages must be identified | | Executables and binaries | Unregistered executables and signs of tampering | Hash calculation and comparison policies are required | | Dynamic modules and plugins | Code added while the system is running | Load-time tracking and an approved baseline are needed | | Container configuration | Differences between the image and the runtime environment | Temporary containers and sidecars must be managed | | Environment variables and configuration files | Whether the runtime configuration has changed | Policies for collecting and masking secrets are essential | | Network connections | External downloads and abnormal communications | Increased log volume and privacy issues must be considered |

Therefore, during initial adoption, a practical approach is to prioritize the information directly needed for asset identification and vulnerability response, rather than collecting every runtime activity. For example, services subject to strict regulation may first focus on inspecting libraries currently in use and the integrity of container images, then gradually expand coverage to plugins, configuration changes, and external communications.

Turn the Difference Between Build SBOMs and Runtime SBOMs into Alerts

The core value of a Runtime SBOM does not lie simply in creating another inventory. More importantly, it helps identify the differences between the configuration approved at build time and the configuration actually running in production.

It can detect situations such as:

• A library not present in the build SBOM is loaded on a production server
• An unapproved plugin or agent has been added
• A file manually patched during an emergency response remains in the environment
• The hash of an actual executable differs from that of the container image
• A vulnerable library exists but is not actually called by the service
• A production-only module or configuration absent from the development environment has been enabled

Not every difference should be treated as a critical incident. Production environments may legitimately contain additional components, such as monitoring agents, backup tools, and authentication modules. Therefore, from a Software Security perspective, what matters is not simply discovering differences, but classifying them and managing their approval status through policy.

For example, response criteria can be divided as follows:

• Immediate blocking or isolation: Unsigned binaries, known malicious hashes, and prohibited license components
• Urgent review: Actively loaded libraries with high-risk vulnerabilities and unapproved external downloads
• Register as an approved exception: Production monitoring tools, approved security agents, and temporary maintenance modules
• Trend monitoring: Inactive dependencies and components whose usage is unclear

Collected Data Can Also Become a Target

A Runtime SBOM contains detailed information about the production environment. Data showing which libraries are running, which versions are in use, and which configurations are applied is a valuable asset to defense teams—but it can also be useful to attackers.

When environment variables and configuration files are collected together, they may contain sensitive information such as API keys, database connection details, internal addresses, and certificate paths. Therefore, the collection system requires safeguards such as:

• Masking and tokenization of sensitive environment variables and configuration values
• Encrypted storage of SBOMs and runtime observation data
• Separation of viewing privileges through role-based access control (RBAC)
• Mutual authentication between collection agents and the central management server
• Maintaining audit logs for SBOM creation, modification, and exception approvals
• Secure deletion of raw data after its retention period expires

The reliability of the SBOM itself must also be verified. If a collection agent has been tampered with or an attacker can falsify runtime information, the Runtime SBOM may become the basis for incorrect decisions. Verifying agent binary signatures, validating the integrity of collected data, and digitally signing generated SBOMs while maintaining their history are not optional enhancements; they are close to baseline control requirements.

Minimum Standards Operations Teams Should Define First

Adopting a Runtime SBOM does not end with purchasing a security solution. Operations, development, and security teams must jointly define the baseline for it to deliver real value.

It is advisable to first reach agreement on the following four areas:

1. Identify services with the highest protection priority
   Define the initial scope by starting with internet-facing services, systems processing personal information, services subject to public-sector or financial regulations, and critical APIs.

2. Define a trusted baseline SBOM
   Use build SBOMs generated through CI/CD, signed deployment artifacts, and approved container images as the baseline.

3. Establish a policy for acceptable runtime differences
   Clearly define which configuration changes should be blocked automatically and which should go through an approval process.

4. Connect the process to vulnerability response
   When a vulnerable component is discovered through the Runtime SBOM, establish a process that continues through owner notification, identification of affected services, patching or rollback, and exception approval.

The purpose of a Runtime SBOM is not to monitor the production environment excessively. Its purpose is to answer quickly and with evidence the question, “Can we trust the software that is actually running right now?” When teams design a balance between visibility and performance, as well as between data protection and analytical accuracy, a Runtime SBOM can become more than a simple inventory—it can serve as a practical Software Security control.