From SolarWinds to Today: Lessons Still Not Learned

There are some breaches that change how the industry thinks about security. The SolarWinds hack was one of them.

It wasn’t just the scale or the sophistication that made it stand out. It was the realisation that software updates organisations believed were safe could become the attack vector itself. For many organisations, that moment was a wake-up call. It exposed how much implicit trust existed in software supply chains, and how little visibility there was once code moved beyond internal control.

Years later, the uncomfortable question remains. How much has actually changed?

When Trust Becomes the Vulnerability

In late 2020, SolarWinds — a widely used IT management software provider — became the centre of one of the most significant cyber espionage incidents in modern history. Attackers successfully compromised the company’s software development process and inserted malicious code into its updates. That update was then downloaded by thousands of organisations as part of routine maintenance, unknowingly giving attackers access to internal systems.

It wasn’t just the scale or the sophistication that made the breach stand out. It was the realisation that software updates organisations believed were safe could become the attack vector itself.

The most striking aspect of the breach wasn’t that attackers compromised a software provider, but that they were able to reach thousands of organisations without having to target each one individually.

After inserting malicious code into SolarWinds’ build process, the attackers were able to distribute it through a trusted software update that customers installed as part of routine maintenance. From the perspective of the organisations receiving it, everything appeared normal. The update came from a familiar supplier, arrived through official channels, and was deployed without suspicion.

That’s what made the attack so effective. Rather than exploiting a firewall weakness or an unpatched vulnerability within every target environment, the attackers took advantage of the trust organisations placed in their software supply chain.

This is what makes supply chain attacks so difficult to defend against. The very systems designed to streamline updates and maintain integrity can also become the mechanism through which risk is introduced.

The Risk Inside the Build Pipeline

Modern development pipelines are designed for speed and efficiency. Code is written, tested, integrated, and deployed at a pace that would have been unthinkable a decade ago. That speed comes with complexity.

Multiple tools, environments, and dependencies are involved in the process, each representing a potential point of exposure if not properly secured. When attackers gain access to a build pipeline, they’re not just compromising a single system, but positioning themselves upstream where they can influence everything that flows through it. This is where code signing becomes important, but also potentially misleading. A signed update creates a sense of assurance, yet it only confirms that the code came from a trusted source. It doesn’t guarantee that the source hasn’t been compromised.

Without strong controls around how code is built, tested, and signed, that trust can be misplaced.

The Blind Spot Around Software Updates

Software updates are designed to improve security. That’s why they’re often deployed quickly, sometimes automatically, with minimal scrutiny. The challenge is that this process assumes the update itself is safe.

In the case of SolarWinds, and other supply chain attacks that followed, the update mechanism became the delivery method for malicious code. Organisations applied the update as part of routine maintenance, unaware that they were introducing risk into their own environments. This highlights a gap. While there is often strong focus on detecting external threats, less attention is paid to monitoring what happens after software is installed.

Without more visibility into how systems behave post-update, it becomes difficult to identify when something isn’t quite right.

External Code, Internal Risk

Every organisation relies on external code in some form, whether through third-party software, open-source libraries, or integrated services. This reliance is unavoidable, but it introduces dependency that isn’t always fully understood.

Once external code enters an environment, it’s often treated as inherently trustworthy, particularly if it comes from a well-known vendor. That assumption can create blind spots, especially when internal validation processes are limited or inconsistent.

Validating external code isn’t about distrusting every supplier. It’s about recognising that risk doesn’t disappear because the source is familiar. The SolarWinds breach demonstrated how even reputable vendors can become part of the attack chain.

Why Zero Trust Still Feels Out of Reach

Zero trust has become a widely discussed concept in the years since the SolarWinds attack. The idea of continuously verifying users, systems, and access rather than relying on implicit trust makes sense in principle. In practice, adoption has been slower than many expected.

Part of the challenge lies in the scale of change required. Moving to a zero-trust model involves rethinking how access is granted, how systems interact and how trust is established across the organisation.

For many teams, this feels like a significant shift away from established ways of working and requires coordination across functions and a willingness to challenge long-standing assumptions. As a result, progress is often gradual. Elements of zero trust may be introduced, but rarely in a way that fully addresses the risks exposed by supply chain attacks.

The Human Decisions Behind the Technology

While supply chain attacks are often discussed in highly technical terms, they’re shaped by human decisions at every stage. Choices about how quickly updates are deployed, how thoroughly code is reviewed, and how much visibility is maintained across systems all influence the level of risk.

These decisions are rarely made in isolation. They’re influenced by deadlines and operational pressures and, in that context, trust becomes a practical necessity rather than a deliberate risk. The challenge is that attackers understand this dynamic. They don’t need to break every control if they can find a way to operate within the flow of normal activity.

Why the Lessons Haven’t Fully Landed

The SolarWinds breach highlighted a set of systemic issues, but addressing those issues requires more than awareness. It requires consistent action across multiple areas, from securing build pipelines to improving visibility into software behaviour, to strengthening validation processes and rethinking trust models.

These aren’t quick fixes. They involve changes to how organisations build, deploy, and manage technology at a fundamental level. That’s why progress can feel slow. The lessons are understood, but translating them into everyday practice is far more complex.

Moving Forward Without Blind Trust

Reducing supply chain risk doesn’t mean removing trust entirely. It means being more deliberate about where trust is placed and how it’s verified. This involves strengthening controls around development pipelines, improving monitoring of software behaviour, and ensuring that external code is subject to appropriate levels of scrutiny. It also means recognising that trust shouldn’t be static. What was considered safe at one point may not be as environments evolve.

A more resilient approach focuses on continuous validation, where assumptions are regularly tested rather than taken for granted.

How MetaCompliance Can Help

At MetaCompliance, we focus on the behaviours that sit behind complex security risks, including those exposed by supply chain attacks.

The lessons from incidents like SolarWinds aren’t just technical. They highlight how everyday decisions, from deploying updates to managing third-party relationships, can introduce risk if they aren’t fully understood.

Our approach combines targeted security awareness training with behavioural insight, helping organisations explore how risks linked to the OWASP Top 10 and supply chain vulnerabilities show up in real-world scenarios. This includes understanding how trust is established, where it can break down, and how to respond more effectively.

By supporting teams with practical guidance and context, we help organisations move beyond reactive responses and build a more consistent, informed approach to managing risk.

As supply chains continue to grow in complexity, the ability to question assumptions and make better decisions becomes increasingly important.

Get in touch with our team today to find out more.