Salesforce introduced a new Automation Everywhere Bundle to accelerate end-to-end workflow orchestration, automate across any system, and embed data and AI-driven workflows anywhere.
During the past year-and-a-half, the US federal government developed a canon of guidance that addresses software supply chain security. It began with the Biden Administration's Executive Order 14028 on Improving the Nation's Cybersecurity, followed by the National Institute of Standards and Technology (NIST) publishing the first version of their Secure Software Development Framework. And most recently, the White House's memorandum (PDF) on behalf of the Office of Management and Budget (OMB) that mandates the federal use of secure third-party software.
Needless to say, the federal government has been quite busy building its case that both the private and public sectors need to address software supply chain risk head-on. However, all of the mentioned motions above, while essential to software security, do not directly address the private sector. For the many software organizations out there that do not work directly with the federal government, what can serve as their source of truth for software supply chain security?
Well, a recent report titled Securing the Software Supply Chain may be what software organizations are looking for.
The Report: Software Security's "Compendium"
This report, tagged as a "recommended practices guide for developers," was written by the federal government's Enduring Security Framework (ESF) Software Supply Chain Working Panel. The ESF has representation from government agencies, specifically the Cybersecurity and Infrastructure Agency (CISA), the National Security Agency (NSA), and the Office for the Director of National Intelligence (ODNI). It also has experts from the IT, Communications and Defense Industrial Base sectors, making the working group representative of public-private partnership.
The guidance is meant to serve as a "compendium of suggested practices for developers, suppliers, and customer stakeholders to help ensure a more secure software supply chain." It's split into 3 parts, with each part addressing either developers, suppliers, and customer stakeholders, who all have a stake in securing software supply chains.
The report consists of several key points that should help software organizations get on the right track when it comes to software security.
First, it paints an accurate picture of the problem at large, which is that there are a number of active risks to the software supply chain. It goes beyond the infamous SolarWinds incident of December 2020 to include other possible risks like software tampering, attackers abusing open source repositories, and malicious binaries.
Second, the report serves as a true "compendium." ReversingLabs Cyber Content Lead Paul Roberts noted that this report can be characterized as a Rosetta Stone for software supply chain security. The ESF pulls together both private and public sector documents that advise on software security, making it easier for software organizations to familiarize themselves with standard practices for ensuring proper software security health.
Third, the ESF's guidance makes helpful recommendations for securing software supply chains. For example, the report emphasizes the use of software composition analysis (SCA) tools, given that the risk of malicious binaries is often overlooked. It also focuses on software bills of materials (SBOMs) as being a necessary tool to understand what kinds of components a software product includes, such as open source and third-party components. Additionally, it recommends that software organizations conduct automated static and dynamic testing of newly checked-in code, allowing them to look for vulnerabilities.
While it's clear that the ESF report is a momentous step forward for secure software, there is still a hurdle to overcome: software organizations that do not do business with the federal government, as well as federal development teams and contractors, are not mandated to follow these guidelines. Instead, these organizations must incentivize themselves to do the heavy-lifting.
Thinking Beyond SolarWinds
While SolarWinds serves as the catalyst for the software security movement, it is not the only incident that demonstrates the magnitude of this problem. It has been almost 2 years since SolarWinds, and within this span of time, more attacks and new risks to the software supply chain have been discovered. Additionally, we have learned a great deal about where the industry stands when it comes to securing software.
For example, a ReversingLabs commissioned study, conducted by Dimensional Research, found that a majority of software organizations in 2022 are not equipped to handle software supply chain risks. Out of 300 respondents, roughly half of them reported that their organizations cannot protect their software against third-party risks when using open source, commercial solutions, and partner software. Also, only 37% of respondents confirmed that they have a way of detecting software tampering across their supply chain, and very few (7%) check for tampering in every development stage.
As the software industry struggles to follow secure software practices, the risks and attack possibilities to the software supply chain continue to grow. Attacks on popular open source repositories like npm and PyPI have skyrocketed by 289% over the past 4 years.
That growth is evident in recently discovered software supply chain attacks that abuse these public repositories, such as the IconBurst supply chain attack, as well as additional attacks on both npm and PyPI.
Despite the vast attack possibilities on open source repositories, this problem is just one risk to the software supply chain. The ESF report calls out a number of areas in addition to open source risk that software organizations need to pay attention to when securing their development processes.
For example, the ESF guidance notes that modern Integrated Development Environments (IDEs) are extensible with third party plug-ins, creating the possibility that malicious IDE plug-ins may compromise the local development environment. Such tools and third party plug-ins should be scanned for vulnerabilities and evidence of tampering before being added to developer machines, the ESF report argues.
Software Suppliers: Get Ahead While You Still Can
There are fair criticisms of the ESF report, such as it not being practical enough for developers to follow. However, given the wealth of content, resources, and action steps this report provides, it is clear that the document serves as a good starting point for organizations looking to secure their software development practices.
It is also likely that these same organizations do not want to become the next SolarWinds. This is why they need to implement robust software security policies that will aid their organization's ability to prevent these kinds of incidents. This is why, despite its flaws, the ESF report is a big step in the right direction.