In early 2020, threat actors breached the build systems of SolarWinds and used this access to add malicious code into one of SolarWinds products. The product, called “Orion”, is very widely used and deployed by tens of thousands of companies, including many Fortune 500 companies.
Then, from around March 2020, when SolarWinds’ customers updated their installations of Orion, the malicious code embedded gave the threat actors a backdoor which they could then use to install additional malware, spy on, and exfiltrate data.
By now, this is a very well-known, maybe even the most famous, example of a software supply chain attack.
What has happened since then?
In short – a lot! Unfortunately, the SolarWinds’ incident was not the last time a software supply chain was breached. Software supply chain attacks have been continuing and could be accelerating.
In February, it was discovered by security researchers that many public package repositories and registries could be used to implement a Dependency Confusion attack, which allowed the insertion of malicious code or packages into several major companies’ build and development processes, including Apple and Tesla.
Then in May, it was announced that threat actors had breached a very commonly used development tool, CodeCov. And just a few days ago, it was revealed that the primary public registry for Winget, Microsoft’s new Windows 10 package manager, was being filled with corrupt, duplicate, or possibly malicious packages.
Is this new?
Despite the amount of news that these incidents have generated recently, unfortunately, software supply chain attacks are not new.
In fact, in 2015, a fake version of Apple’s XCode development environment was distributed, which, when used to develop software for iOS, inserted malicious code into dozens of iPhone apps. And in 2019, the same thing happened to Microsoft’s Visual Studio, which resulted in malware being inserted into several games developed using it.
In 2017, another software supply chain breach launched the Cyber Attack known as NotPetya. The software updates for a Ukrainian accounting product were compromised and caused an estimated $10 billion of damages.
And also, in 2018, a group of threat actors compromised software updates from the manufacturer ASUS and the computer cleanup tool CCleaner. These particular attacks are believed to be just two of six successful supply chain attacks perpetrated by this group.
Overall, these attacks have affected thousands, if not hundreds of thousands, of users and systems. And often, the difficult part is determining exactly how large the blast radius is.
Why is this happening more now?
There are a few reasons why we see an increase in software supply chain attacks, so let’s just touch on a couple of the most important ones.
The first reason is that software security is not new. For years now, we have been conditioning users to “not click links in unsolicited emails”, “Check that the site you are using is genuine and secure”, “protect username/password/credentials”, etc. As users, we have started to implement better opsec; we are more aware of threats and how to combat them.
So, as a result, the threat actors have had to move up the chain. Rather than target individual users and systems, they target the very processes by which users obtain their software. After all, who wouldn’t trust a software update that has been delivered from a software vendor's distribution platform and signed by the said vendor? Everything we have been conditioned to question and check passes in this case.
The second reason is that the blast radius is potentially so much greater. Rather than targeting thousands of users or systems and compromising just a few, an attack like that on Solarwinds results in a single compromise expanding to many thousands of compromised systems and networks.
The threat actors can leverage the distribution networks of a software vendor to do the dirty work for them. To let thousands of Trojan horses out into the wild and run wild. The payoff is just so much greater for a successful supply chain attack, that it represents a significantly larger return on investment to an attacker.
What can we do about it?
At Cloudsmith, we believe that the solution comes in the form of Continuous Packaging.
Continuous Packaging is a development methodology that offers the observability and control to ensure that software is always verified, packaged, and ready to deliver.
We have talked about this before, and you can watch our talks on continuous packaging on our YouTube channel. We think that continuous packaging is the missing link between continuous integration and continuous deployment – The cornerstones of a modern DevOps software development process.
It really comes down to using new best-in-class tools to help you have visibility and management over all packages and code used in your environments—providing trust, isolation, and performance.
Some key concepts to note:
· Minimise trust. Scan at source, during build and at packaging.
· Isolate from third parties.
· Implement and own a single source of truth for packages.
· Be a curator of software packages, not just a consumer.
· Draw a thread from build to deployment.
We will dig a bit deeper into continuous packaging in an upcoming blog, so check back soon and watch this space.
However, we are not alone. The US and UK governments have recently announced efforts to improve the security of software supply chains. These efforts should result in guidelines for best practices and minimum standards that vendors should meet.
At its core, this is what Cloudsmith does. Cloudsmith provides a single source of truth for all packages and containers you consume as part of your development process. It enables you to isolate yourself from public upstream package sources and take back control over your software supply chain.
It’s time for a change. It’s time for an overhaul of how we securely develop software, and it’s time to get ready.
