Dynamic SBOM: Monitoring the Pulse of Software Security
Monitoring a system’s SBOM (Software Bill of Materials) is a crucial part of developing and maintaining a secure system throughout its lifetime. Tracking the SBOM enables developers to continuously detect vulnerabilities and decide on proper mitigations.
Dynamic SBOM (DSBOM) represents an advancement in software security assessment compared to its predecessor, known as static SBOM. While the static SBOM analysis provides a comprehensive overview of the system components, including libraries and dependencies, the dynamic SBOM adds a layer of real-time insight by actively monitoring the calls made to third-party libraries during code execution.
The distinguishing feature of dynamic SBOM is its ability to accurately identify and track the actual usage of libraries within an application. This real-time monitoring ensures a more precise understanding of the software’s ecosystem and potential vulnerabilities, leading to more effective prioritization of security mitigations.
What Are the Benefits of DSBOM?
Dynamic SBOM makes prioritizing mitigations easier, and far more effective. In the example below, the static SBOM reported as CVE-2023-31484 is related to libperl 5.36.0. The dynamic scan doesn’t show any use of this library for this specific application. However, the dynamic SBOM does indicate that the application loads libcurl. By cross-referencing this with the static SBOM, one can see that the version of libcurl is 7.86.0, which has CVE-2023-27534.
It’s now easy to determine prioritization. If this application needs to be assessed, CVE-2023-31484 for libperl can wait, while CVE-2023-27534 for libcurl is more urgent.
How DSBOM Works
At the outset, the “PlaxidityX DSBOM” replaces all calls to the dynamic libraries with a trap interrupt, or “breakpoint” (works on x64 and ARCH64). This is accomplished by replacing the assembly code in memory.
Then, the code is executed.
Key Considerations for Using Dynamic SBOM
It’s important to take into account the following considerations when utilizing dynamic SBOM:
Why Use DSBOM instead of ltrace
ltrace records every call to external libraries, including those that repeat themselves (e.g., printf), resulting in slower performance. DSBOM, on the other hand, registers each call only once, optimizing speed and efficiency. Additionally, ltrace only has visibility into direct calls from the app, but cannot track inner functions or transitive calls from other libraries. In contrast, DSBOM can identify the critical path within the code. For instance, if a vulnerability exists in a particular function, DSBOM can provide an alert even if the call comes from a third-party library.
Use DSBOM to Complement Static Analysis
Dynamic SBOM complements static analysis – but cannot replace it entirely – for several reasons:
- Incomplete Coverage: Dynamic analysis may not provide full coverage of all application functionalities (due to insufficient code coverage), necessitating the use of static analysis to identify potential exploits.
- Dependency Impact: Even if a particular library is not directly utilized by the main application, another component or subsystem may rely on it, impacting the prioritization of vulnerability fixes.
- Unused Libraries: Identifying and removing unused libraries from the system based on dynamic SBOM results can enhance system security by reducing attack surfaces.
Coverage and Effectiveness
The results of dynamic SBOM correlate directly with the coverage achieved during monitoring. Higher coverage, achieved through comprehensive testing methodologies like unit tests or products such as PlaxidityX AutoTester Automotive Fuzz Testing Tool , leads to more reliable and actionable results for enhancing system safety and security.
Line coverage measures the percentage of code lines executed during testing. This is the metric used in DSBOM analysis. In the following chart, we can see the impact of line coverage on library discovery. This example uses a small, purpose-built code example, and the results may differ in larger projects.
The outcome of a static SBOM will look something like this.
This table simply informs the user about the applications or libraries present in the system, regardless of whether they are actively used. As shown in Figure 6, you will see some applications and libraries in the system that are not used by the main application.
This example clearly demonstrates how increasing coverage improves detection. However, there are still undetected libraries that do not overlap with the static SBOM. See the complete comparison between the runs in Figure 4.
The fact that DSBOM relies on coverage means that even with high coverage, if it doesn’t cover the areas where the libraries are called, the results will still be poor. Therefore, it’s a matter of coverage quality, not just quantity.
Another point worth mentioning is that DSBOM also reports on all required libraries, even if they were not called (i.e., none of their functions were called). This is also a good indication of the system requirements. In the table below, we can see that out of a random sample, only one library was actually used, while all the others were required. Overall, only 11% of the loaded libraries were called in areas with high coverage. This could mean three things:
- Dead code: There is unnecessary use of third-party code that is not needed.
- Low coverage: This code is not tested.
- A transitive dependency. There is nothing to do, as it’s common to utilize only partial functionality of a library.
This table illustrates the number of libraries loaded into process memory compared to those actually called during runtime. The displayed data represents a small, randomly selected portion of the complete table, which is too extensive to be fully presented here.
Figure 8 demonstrates the number of applications and libraries in the system compared to the actual libraries used by the main application. Following the DSBOM analysis, we can see that only 14 out of 1,000 libraries are actively used. This is critical insight when it comes to prioritizing vulnerability mitigations. Such a streamlined approach makes the lives of CISOs much easier, not to mention the programmer and product manager. Highlighting the areas that have more critical vulnerabilities simplifies decision-making, as well as helping analysts avoid alert fatigue.
Conclusion
Dynamic SBOM has emerged as a pivotal tool in enhancing software security assessment by providing real-time insights into library usage during code execution. Its ability to complement static analysis – although not entirely replace it – showcases its importance in uncovering vulnerabilities that static analysis alone may overlook or prioritize incorrectly. By accurately identifying and tracking library usage, Dynamic SBOM aids in prioritizing security mitigations effectively.
However, it’s also crucial to note that Dynamic SBOM’s coverage and effectiveness are directly tied to monitoring coverage, emphasizing the need for comprehensive testing methodologies. Additionally, the reporting of all required libraries, regardless of their usage, serves as a valuable indicator of system requirements and potential issues such as dead code or low testing coverage. Dynamic SBOM, when integrated judiciously alongside static analysis, can contribute significantly to fortifying software ecosystems against potential threats.
