Freely subscribe to our NEWSLETTER

“This vulnerability really brought light to the age-old issue of “You can’t protect what you don’t know you have” that we used to see more commonly in asset inventory and patching compliance. Log4J really was an evolution to this issue and shined a spotlight on the harsh reality that it is not good enough to just know what operating system or applications are installed; instead, we need to understand the building blocks of shared libraries that comprise our applications and operating systems to find and remediate certain vulnerabilities.

This is where a Software Bill of Materials (SBOM) solution becomes crucial in shining light into the dark software caves. An SBOM builds out a list of all the packages and shared libraries used in each application, along with their version number, so if a vulnerability is released for a specific package, you can either update that package, remove it, or contact a vendor to see if a new patch is available to remediate the vulnerability. Having that bastion of knowledge available at a moment’s notice before public lists of known vulnerable software applications are posted enables users to protect themselves and mitigate the impact of being exploited sometimes even before a vendor knows. When Log4J was discovered, many security researchers, myself included, were blindly attempting to exploit the vulnerability in their home labs, and we found multiple vendors that hadn’t reported they were affected yet. An SBOM would eliminate this shotgun approach to finding a vulnerability in the first place and let us know exactly where to do more detailed proof of concept exploitation and vulnerability disclosure.

Log4J is not alone in the grand scheme of shared library exploits, but it was catapulted to the headlines because of its ability to perform what’s called a Remote Code Execution (RCE) vulnerability. RCE allows for code to be executed remotely and possibly without needing to authenticate with an application. Log4J illustrated how finding a vulnerability in open-source software can provide footholds in not just one application but often a large majority of the applications used by some of the largest corporations today, and I expect shared library/software exploits like this will only become more common. Rather than calling out or punishing responsible security researchers for finding additional exploits like Log4J in open-source software, we should encourage research and support the groups that make these shared libraries as they commonly work for free and out of passion for making great software. Funding an open-source software developer allows them to devote more time and resources to develop stronger and more secure libraries which benefits the larger community.”