Last week, The New York Times reported on how a Microsoft engineer uncovered a vulnerability in open-source software that, had the software been in mainstream use, could have given threat actors remote access to millions of computers around the world. This shows how, even as end users pour resources into cyber defense, threat actors, who play the long game, may be able to infiltrate the software supply chain to compromise the security of software used by millions. Supply chain vulnerability stems from the fact that much of the software we use today is not written from scratch. Instead, it is built from off-the-shelf components. Thus, infiltration of these off-the-shelf components – which are incorporated into IT systems around the world, systems used by myriad entities, from small businesses to US Government agencies – has become the go-to strategy for cyber threat actors.
A recent study estimated that software supply chain attacks are up 430% in the past two years. Recognizing this trend, the US Government sponsored an initiative in which public and private researchers will focus on open-source software security. Unfortunately, it appears we need organized government support and resources to stay ahead of this threat.
Undoubtedly, the world dodged a bullet last week. But what can we learn from this incident?
First, the fact that the malicious code appeared in open-source software led to its discovery. Had the code been hidden in proprietary software, it would have been much more difficult to detect, as many learned during the Solarwinds incident in 2020.
However, its inclusion in open-source software, if undetected, would have made it much more damaging than the Solarwinds code because open-source software is much more widely used than proprietary software. In this case, the malicious code made its way only into a beta version of Linux distributions. Had it appeared in everyday Linux systems, the magnitude of its potential reach cannot be understated.
What can you do? This should serve as a stark reminder to assess your infrastructure, as well as your supply chain, through a critical lens and to do so frequently. Based on what we know so far about the malicious code, there are several common-sense takeaways:
- Prioritize asset management. We know the actor targeted SSH, the remote access protocol used to prevent unauthorized parties access to the system. Knowing your assets, but more specifically, which assets use SSH, and on what ports, would be critical in this scenario.
- In a similar vein, stay committed to the principle of least privilege, the doctrine that a user should have access only to the data and applications needed to complete a required task.
- Incorporate a Software Bill of Materials, a nested inventory that identifies the components of a given application. By knowing the components used, organizations can assess potential vulnerabilities and address security and supply chain risk management concerns.
- When using open-source software, weigh the risks of upstream vs. downstream distribution, especially in regard to dependencies. This refers to the direction of the software flow: upstream projects release the core software and updates. Upstream updates will be implemented sooner than updates implemented via downstream distributions. In this instance, the choice of distribution could likely add an additional layer of security, as software updates travelling downstream traverse several layers of vetting.
