The Log4j vulnerability, known as Log4Shell, was the messiest game of hide-and-seek for system and network administrators. Not only was there an Internet-wide vulnerability that needed tending to, but admins were forced to determine where exactly this piece of open source software was living inside commercial and homegrown applications.
As it turned out it was just about everywhere.
Dozens of vendors immediately issued advisories, warnings, and eventually patches for the vulnerability in the popular Java-based logging utility within their respective products—hundreds of which were affected. Administrators and security managers, as it turned out, needed to quickly ascertain which commercial and homegrown products were vulnerable as exploits quickly appeared online, faster than patches were being made available it seemed.
This was a tall order. Software security company Sonatype published data shortly after the vulnerability was disclosed that said Log4j had been downloaded more than 28 million times between August 2021 and December 2021. It was in the top 0.003% percentile among the most downloaded software components.
Given the ease of exploitation of Log4Shell and the fact that the vulnerability left servers exposed to code execution, administrators were behind the 8-ball from the get-go. Log4j was a perfect storm of a critical vulnerability combined with poor visibility into the components used by developers to build software products to put thousands of users and companies at risk in an instant.
It didn’t take long for rejuvenated discussions about a software bill of materials (SBOM) to regain steam. SBOMs were not new by any means, but they certainly weren’t top of mind for a long time until earlier in 2021 when President Biden signed the Executive Order on Improving the Nation’s Cybersecurity. Prompted by the SolarWinds supply chain attack, the executive order included a prominent section that focused squarely on secure software development practices. One glaring demand within that section: the mandate that an SBOM be published on a public website for each product within the federal supply chain.
An SBOM is essentially a component inventory and dependencies list for a software application. Some liken it to an ingredient label on food products. While somewhat simplistic, this is the best visualization of an SBOM: a description of the components—and relationships between those components—used in building software; developers often compile projects using code from numerous sources, including open source projects, for example.
Would an SBOM have prevented Log4j? Of course not. But an SBOM would have laid down clear tracks as to whether the utility was present in an enterprise application, whether an affected version was running, and it would have helped prioritize patching and mitigation efforts in a much more timely manner.
Buoyed by the mandate in the Executive Order, SBOM proponents—and detractors—became increasingly vocal about pros and cons. Those against SBOMs have made arguments that on the surface could sway some from understanding the benefits of having one, and cast a shadow on the viability and usefulness of an SBOM.
Here, we’ll bust three of the most popular myths circulating about SBOMs, and make the case for why they’re absolutely necessary in a threat environment where awareness of critical infrastructure cybersecurity and vulnerability management in those key sectors is at an all-time high.
Myth No. 1: SBOMs are a road map for attackers
Publicly available SBOMs are not an attack vector. A state actor or an experienced criminal organization is much more capable of scanning for vulnerabilities at scale, or making use of targeted phishing campaigns to infiltrate an organization, than they are to take the time to digest an SBOM for vulnerable components and software dependencies. The transparency benefits for defenders far outpace the supposed risk an SBOM would introduce.
Think about an attacker’s reconnaissance activities, in particular those that involve studying and reverse engineering software binaries. This practice has been part of an attacker’s arsenal for all of the 21st century—and largely without the availability of SBOMs at any kind of scale. An SBOM doesn’t prompt this behavior, nor make it any simpler for a threat actor.
Instead, a defender benefits greatly from understanding the third-party components such as the Log4j utility and other open source libraries, for example, that a developer may have implemented to ensure the functionality of a software application.
Open source software, meanwhile, was identified as a key national security concern by the Biden Administration in January, prompting a White House meeting of technology leaders to discuss the security of open source software. Many open source projects are under-resourced and poorly funded; these challenges often don’t come to light unless a critical vulnerability surfaces. An SBOM that identifies these potential vulnerable components is crucial for defenders and provides transparency that’s often missing as vulnerability assessments are made.
Myth No. 2: SBOMs expose business secrets
SBOMs are lists of software components, relationships, and dependencies. They are often machine readable and if updated often and used properly, can improve software security, development efficiencies, cut down supply chain risks, and enhance vulnerability management.
It would be difficult for an SBOM to expose intellectual property or leak trade secrets. SBOMs do not include source code; they only reference software components used to build the software. Open source software components that may be included in software packages are often freely available, and are governed by a host of license agreements that indicate how they can be used and altered, and what must be shared back with the open source community.
Any business organization that still has concerns about their exposure via an SBOM is under no obligation to publish theirs publicly. They should, however, reap the rewards of an internal SBOM. That kind of visibility has enormous value to everyone from engineering to cybersecurity analysts. An SBOM can be the centerpiece of vulnerability remediation, bringing developers and security teams to the same table in order to match remediation efforts to risk management priorities.
Myth No. 3: SBOMs are not scalable
The Executive Order signed by President Biden a year ago not only mandates a formal record of software components spelled out in an SBOM, but that they be made available in a machine-readable format.
“A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration,” the order says. “The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.”
Scalability is key to the success of an SBOM; developers are under enormous pressure to get software out the door on time and under budget. Impediments such as security—or an SBOM—aren’t likely to be prioritized unless they’re automated and scalable. There are three popular SBOM standards: SPDX, CycloneDX, and SWID tags, and many have urged their adoption.
Conclusion
Vulnerabilities such as Log4j demonstrate the frailty of the software supply chain and the need to shore up secure development practices, regardless of industry or company size. A software bill of materials is one more tool to aid network and system administrators in their vulnerability management efforts and overall risk management initiatives.
Myths about an #SBOM further exposing an organization to attack or leaking trade secrets hamper an enterprise's #security efforts around visibility and transparency into software assets that could put an entire organization at risk. #respectdataClick to TweetMyths about an SBOM further exposing an organization to attack or leaking trade secrets hamper an enterprise’s security efforts around visibility and transparency into software assets that could put an entire organization at risk, or worse, threaten national security or public safety. Providing clarity around SBOMs is necessary as the government elevates awareness of their effectiveness, and mandates their use at the federal level.
