RunSafe Security this week added an ability to generate a software bill of materials (SBOM) based on the code actually included in an application before it is deployed in a production environment.
The RunSafe Security Platform already enables DevOps teams to safely run code written in languages such as C or C++ by reordering how code is actually executed. That capability prevents cybercriminals from creating, for example, a buffer overflow that exploits a known vulnerability by preventing them from discovering where to inject malicious code.
In addition, the RunSafe Security Platform provides access to monitoring tools that enable DevOps teams to track what components running in memory are being used to build an application. That capability is now being extended to generate an SBOM.
RunSafe Security CTO Shane Fry said that approach creates a more accurate SBOM because unlike other approaches it is not generating an SBOM based on what source code was used or, conversely, trying to analyze application binaries. Both those approaches create SBOMs that are often inaccurate or incomplete, he said.
DevOps teams then have to create a process to manually triage SBOMs using senior application developers that are costly to hire or contract, noted Fry.
In contrast, The RunSafe Security Platform tracks what code is being loaded into an application, either directly from within a continuous integration/continuous delivery (CI/CD) platform or server being used to build software, said Fry. In total, the RunSafe Security Platform keeps track of more than 400 sources of application vulnerabilities to ensure the SBOM created is accurate. They can then opt to safely deploy software with known vulnerabilities by reordering how code is run in memory, or use those insights to better prioritize remediation efforts. noted Fry.
With the rise of more stringent regulations and compliance mandates, the number of DevOps teams now required to provide SBOMs every time an application is deployed or updated has expanded greatly. The challenge is that the SBOMs, rather than providing a precise accounting, represent more of a best guess of what’s been included, said Fry.
It’s not clear to what degree organizations are relying on SBOMs for anything more than complying with a mandate, however, wherever a new vulnerability is discovered knowing exactly what code is running where becomes crucial. Many DevSecOps teams, for example, in the absence of having any SBOM at all are still looking for where all the vulnerable instances of a Log4j tool for monitoring Java code might still be running, more than a year after the issue was initially discovered.
In theory, of course, many organizations are moving to convert unsafe code into another language such as Rust, but those efforts will take many years to complete. In the meantime, when it turns out that the SBOM provided is incomplete or inaccurate there will be an inevitable backlash. Most mandates require an SBOM but don’t have any specific accuracy requirements. It’s largely up to each organization to determine to what degree to comply with the letter versus the spirit of the mandate.
Ultimately, however, there will come a time when a DevOps team that created an SBOM will be called to account for its veracity when the next application security crisis inevitably ensues.
