SolarWinds: supply chain risk now belongs in the risk model

In December 2020, details emerged of an attack that changed how security has to be thought about. Attackers compromised the build process of SolarWinds and inserted malicious code into an update for their Orion product - an IT infrastructure monitoring tool used by thousands of companies and government organisations worldwide.

The update was signed with a valid SolarWinds digital signature, distributed through official channels, and installed by administrators as a routine update. Identifying it as malicious with standard tools was practically impossible.

This is a fundamentally different kind of attack from phishing or a code vulnerability.

What made this attack different

The standard security model is built on distrust of what is external and trust of what is internal. If software comes from a verified vendor, is signed, and was downloaded from the official site - it is considered trusted. That trust is exactly what was exploited.

The attackers did not break through the defences of SolarWinds' customers directly. They entered through a door the customers opened themselves - through an update from a trusted vendor.

In security terms, this is called a software supply chain attack. The concept is not new - it had been discussed in academic circles and the security community. But SolarWinds made it concrete and large-scale.

Why this concerns everyone, not only those who used Orion

The direct victims are organisations with Orion installed. But the lesson applies to everyone who uses external software. Which is everyone.

The question is not "would we be affected by SolarWinds". The question is "what software do we have installed, who produces it, and how do we verify it has not been compromised".

Before December 2020, most companies were not asking this question systematically. After it, it cannot be ignored.

How the risk model changes

The traditional vendor management model in security focused on: does the vendor have certifications, how do they store data, what does the contract say about liability. That matters, but it is not sufficient.

SolarWinds adds a new layer: the vendor's software development and delivery process is itself part of your attack surface. If the vendor is compromised, the product you trust becomes a vector.

This does not mean abandoning all external software - that is physically impossible. It means:

• knowing what software is installed in your infrastructure and who produces it;
• understanding what access each product has to your systems;
• monitoring security notifications for key components;
• having a response plan if a trusted vendor is compromised.

Three questions for a director or owner

1. Do we have an inventory of installed software - not only corporate applications, but monitoring tools, agents, and IT management utilities?
2. Who in our company monitors security notifications from key software vendors?
3. If it emerged tomorrow that one of our software vendors had been compromised - do we have a response procedure?

SolarWinds is not the last attack of this kind. This is a new category of threat that will remain relevant. It needs to be included in the risk model not as an exceptional scenario but as a working category.