Early in December of 2021, the international cybersecurity community mobilized in response to the discovery of the Log4J vulnerability. This critical vulnerability was within the logging library of Apache, a core component used across millions of Java-based applications.
The vulnerability, known as Log4Shell, rated a 10/10 on the CVSS (Common Vulnerability Scoring System), with hackers that were exploiting this error being able to execute code within LDAP servers. With this, any software that used Log4J was compromised and could be directly exposed to ransomware.
The rapid response was heard across the globe, with government security centers from the U.K. to the U.S. issuing warnings to companies and urging businesses to protect their organizations. While patches and short-term fixes were released in the following days, with America’s FTC (Federal Trade Commission) requiring all U.S. businesses to patch to an updated version or face legal backlash from January 4th onward.
Events like these were not hugely irregular, with the 2021 Executive Order on Improving the Nation’s Cybersecurity arising as a national response to safety concerns. This EO detailed the changing approach that the U.S. government would take to cybersecurity. With a budget of nearly $11 billion USD, an 11% increase from previous years, the total capital that the U.S. designated to cybersecurity has made their stricter approach to security send waves around the world.
What was in the E.O.?
The May 2021 Executive Order was the Biden administration’s push into cybersecurity, with their main focus being on making government systems stronger, safer, and harder to break into. The EO broke down a year of calendar events that companies will be pushing to meet, documenting the main elements and advances that companies and software providers would have to strive for.
These changes spanned from setting out clear definitions of what software is on day 45, outlining a minimum element software bill of materials (SBOM) on day 60, and additional reviews and guideline updates within the first 365 days. Other key points that the release covered were:
- Removing barriers between government and private sector and sharing of Information.
- Modernizing cybersecurity practices in the Federal Government.
- Improving investigation and remediation capabilities.
- Creating a standardized playbook with specific definitions and case examples of how to respond to cybersecurity breaches.
As software is an incredibly broad field, the EO sought to unify what people considered software, as well as the standards that were placed on this industry in relation to security and integrity.
How Has the Private Sector Responded To the EO?
Although the specifications set out by the EO pertained mainly to software that is actively used by the U.S. government, the private sector is already rapidly moving to follow the mandate. While there is a scale of response, with industries such as manufacturing, aviation, and transportation having more extreme consequences if something were to go wrong–potential life and death consequences–and thus adapting more rapidly, the vast majority of software companies in the industry are now working to these specifications.
As stated by Alex Rybak, Director of Product Management at Revenera:
“Certainly any industry that talks about bodily harm – automotive, flying, driving; anything that moves – those have more consequences if software is exploited. These regulated industries [… ] are more risk averse following the Log4Shell event and want full disclosure so that when there’s the next vulnerability, they can query instead of having a scandal.”
Typically, across the software supply chain, from top vendors to individual customers, businesses asking for a SBOM has become more common practice. Companies that can accurately define which open-source software and third-party components they’re using and where it comes from, can prove a clear understanding of their own company, making them seem much more trustworthy and secure to their clients.
Due to the increasing demand for SBOMs, with the looming shadow of Log4J, the software supply chain has become much more wary, with strict documentation and a need for accurate inventories of what is included within a software application becoming vital.
How does the EO impact the software supply chain?
While the EO only extends to companies based in the United States, its echo has been heard around the world. No matter where a software company is based, the international capabilities of these platforms have led to software developed in the U.K., China, and India being deployed on U.S. territory. With the changes to U.S. regulations, this has had a knock-on effect on software vendors internationally.
Somewhere down the chain, software is almost always sold to U.S. customers, or even the U.S. government, meaning that the mandate set out for U.S.-based software is now effectively extending to the vast majority of the world. With this in place, companies have to ask themselves:
- Are we following the outlined software development framework?
- Are our standards for code integrity and code security high enough?
- How are we testing that our code is secure?
- Is there an incident response team that can take care of any risks that may arise?
With these considerations in mind, companies are now paying more attention to open source guidelines. Quite simply, if your software wants to have access to the full scope of the international supply chain, it must comply with the rules and regulations set out by America’s cybersecurity EO.
Final Thoughts
Coming off the back of Log4Shell, the U.S. government intensified its cybersecurity policies, focusing on expanding their understanding of modern cybersecurity practices and increasing the documentation around software in general. As a result of this, SBOMs have become commonplace across the international industry as a whole, with any software that is being actively distributed commonly needing an accompanying SBOM.
While there is a higher degree of documentation and admin associated with the creation of an SBOM, the industry has also flourished with a range of solutions that mechanize the process, helping companies to efficiently test their code and create an inventory of what their software supplies.
As the United States continues to focus on the close monitoring of software that is used and deployed within U.S. territories, the global response will similarly rise to adapt documentation processes. From testing code safety to the creation and distribution of SBOMs, we have now entered the era of software composition transparency.
For those that want to learn more about the current security and license compliance challenges, the Open Source Exchange provides a valuable discussion from field-experts, upon which much of this article was based.
