SolarWinds is a software company whose products are used by organisations to monitor and manage IT infrastructure. One of its key products the Orion platform (which was named the SolarWinds Platform in 2022), provided organisations with tools for monitoring networked systems and infrastructure. The importance of Orion made it an attractive target for attackers. The SolarWinds supply-chain attack of 2020 demonstrated that one of the greatest cybersecurity risks may come through a source that organisations already trust, i.e. their software suppliers. Rather than directly attacking each victim organisation, the attackers compromised SolarWinds software development and distribution process by inserting malicious code into legitimate updates of its Orion network-management platform and installing the affected updates meant their customers were consequently exposing their organizations environments to the attackers.
Modern organisations are increasingly dependent on third-party software, cloud services, open-source components and technology providers and as these dependencies increase, so does the potential impact of a compromised supplier. This incident exposed a fundamental weakness in conventional cybersecurity thinking; organisations cannot assume that software is secure simply because it originates from a trusted vendor.
According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), attackers compromised SolarWinds Orion software and distributed malicious code through legitimate software updates. CISA identified affected Orion versions ranging from 2019.4 HF 5 through 2020.2.1 HF 1, which had been released between March and June 2020.
The malicious component became known as SUNBURST.
The significance of SUNBURST was that it was not distributed as an obviously malicious application, instead it was embedded within legitimate SolarWinds software. The compromised organisations were following normal IT practices by downloading and installing these updates because it was a genuine update from a trusted supplier.
Microsoft’s analysis of the incident described the compromised Orion DLL as the initial mechanism through which attackers established access to affected environments. The attackers could then selectively pursue organisations rather than immediately revealing themselves across every affected system.
A conventional cyber attack may follow a relatively straightforward pattern; an attacker directly compromises a vulnerable organisation using different methods such as phishing, ddos, credential surfing etc. This supply chain attack used a slightly different approach by breaching a trusted supplier/ software to gain access to the target organisations environment. This distinction is important because modern organisations rarely operate in isolation. They depend on numerous third parties for software, infrastructure, cloud services, security tools and other digital capabilities.
NIST has identified software supply-chain security as a critical cybersecurity issue because organisations increasingly depend on technology products and services that are developed, integrated and maintained outside their direct control. The most important feature of the SolarWinds attack was not simply the malware itself. It was the trust relationship between SolarWinds and its customers.
Organisations generally expect software updates from established vendors to be legitimate. Updates are necessary for security, performance and functionality, meaning that refusing software updates altogether is not a realistic security strategy.
The attackers exploited precisely this relationship.
The SolarWinds incident also raises a broader question about traditional cybersecurity architecture. Over the years in cybersecurity, considerable emphasis has been placed on protecting a defined network perimeter. The assumption was that trusted activity occurred inside the perimeter while malicious activity originated outside it. But modern organisations and digital environments do not have such clear boundaries. Employees work remotely, organisations use cloud platforms, applications communicate through APIs, software is supplied by third parties, open-source libraries are incorporated into commercial products, and even managed service providers have privileged access to customer environments. As a result, the modern attack surface extends beyond the organisation itself. Organisations now must not only consider how secure their organisation is but also the security of the stakeholders which their systems and people depend on.
SolarWinds demonstrated that securing the software supply chain requires controls throughout the software development lifecycle. This attack poses a serious question; How can an organisation guarantee the security of software when it cannot directly control the environment in which that software is developed?
Software integrity verification mechanisms that help verify that software has not been unexpectedly modified during development, compilation or distribution can be implemented but it cannot by itself guarantee 100% the integrity of software before it enters the environment. Digital signatures are valuable, but this incident demonstrates that simply knowing that software was signed by a legitimate vendor does not necessarily prove that the software itself is free from malicious modifications.
A Software Bill of Materials (SBOM) provides information about the components contained within software. SBOMs can improve visibility into software dependencies and help organisations identify potentially vulnerable components.
However, SBOMs like the others should not be regarded as a complete solution. They provide visibility, but organisations still need controls to protect the software development and build processes that produce the final software. Organisations must monitor the behaviour of applications after deployment. This is particularly important because supply-chain compromises may involve software that appears legitimate during installation but behaves abnormally after deployment.
The SolarWinds incident raises an uncomfortable question; can organisations ever eliminate supply-chain risk?
The answer is probably no. Modern organisations are too dependent on interconnected technology ecosystems to eliminate third-party dependencies entirely. Attempting to remove all external software and suppliers would be impractical and could create other operational risks. The more realistic objective is therefore risk reduction and resilience.
Organisations should assume that at some point a trusted supplier could be compromised and therefore security architecture should limit what an attacker can do when a compromise occurs. This means moving from a prevention only mindset towards a combination of prevention, detection, containment and recovery. This is perhaps the most important lesson from SolarWinds. A mature cybersecurity strategy should only not ask “How do we stop the breach?”. It should also ask “If a trusted supplier is compromised tomorrow, how quickly can we detect it, contain it and recover?”. That shift in thinking is essential because no security control is perfect.
In a connected digital economy trust is necessary, but trust without verification and continuous monitoring can become an attack vector.
References
Cybersecurity and Infrastructure Security Agency, “Active Exploitation of SolarWinds Software,” Alert, Dec. 13, 2020. [Online]. Available: CISA — Active Exploitation of SolarWinds Software
CISA, “CISA Releases CISA Insights and Creates Webpage on Ongoing APT Cyber Activity,” Dec. 23, 2020. [Online]. Available: CISA — Ongoing APT Cyber Activity
M. A. Scholl, “SolarWinds and Beyond: Improving the Cybersecurity of Software Supply Chains,” National Institute of Standards and Technology, May 25, 2021. [Online]. Available: NIST — SolarWinds and Beyond
Microsoft, “Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack,” Microsoft Security, Dec. 18, 2020. [Online]. Available: Microsoft Security — Analyzing Solorigate
J. Martínez and J. M. Durán, “Software Supply Chain Attacks, a Threat to Global Cybersecurity: SolarWinds’ Case Study,” International Journal of Safety and Security Engineering, vol. 11, no. 5, pp. 537–545, 2021, doi: 10.18280/ijsse.110505. [Online]. Available: Publisher article
CISA, “CISA Releases CISA Insights and Creates Webpage on Ongoing APT Cyber Activity,” Dec. 23, 2020. [Online]. Available: CISA Alert
“An Empirical Study on Reproducible Packaging in Open-Source Ecosystems,” in Proc. IEEE/ACM International Conference on Software Engineering, 2025, doi: 10.1109/ICSE55347.2025.00136.
U.S. Securities and Exchange Commission, “SEC Charges SolarWinds and Chief Information Security Officer with Fraud, Internal Control Failures,” Press Release 2023-227, Oct. 30, 2023. [Online]. Available: SEC — SolarWinds enforcement action
CISA Software Bill of Materials
https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom
This was a great read, Adwoa. The SolarWinds incident has always stood out to me because it shattered one of the biggest assumptions in cybersecurity that updates from trusted vendors are inherently safe. What made SUNBURST so unsettling wasn’t just the sophistication of the malware, but the fact that organizations were compromised while doing exactly what they were supposed to do: patch, update, and maintain their systems.
Your breakdown captures that perfectly. The idea that attackers didn’t need to break in through a firewall or exploit a zero‑day, but instead rode in through a signed, legitimate update, still feels like a turning point for the industry. It forced everyone to rethink what “trust” actually means in a world where software is built, integrated, and shipped across ecosystems we don’t fully control.
I also appreciate how you highlighted the limits of SBOMs, digital signatures, and traditional perimeter based thinking. SolarWinds made it clear that supply chain security isn’t just about prevention it’s about resilience. Detection, containment, and recovery matter just as much, especially when the compromise originates from inside the trusted circle.
Thanks for laying this out so clearly.
Thank you for your thoughtful response. Yes the SolarWinds incident fundamentally challenged the assumption that software from trusted vendors is inherently safe. The fact that organisations were compromised through legitimate updates highlights the limitations of relying solely on perimeter based security and traditional trust models. The Solarwinds incident indeed demonstrates that in an interconnected digital ecosystem, trust must be continuously verified rather than assumed.
Hey Adowa, I really enjoyed the point you made about organizations needing to consider the security of their wider technology ecosystem really stood out to me. It seems that putting your eggs in someone else’s basket can be a vulnerability in itself. In today’s times, organizations reliance on some other vendors, software providers, cloud services, and other third parties is almost a guarantee but that reliance also means the organization has a potential weakness somewhere that’s not in their direct control.
I noticed a similar idea in my Carhartt data breach post. While the situation was very different, the incident showed how organizations and individuals can place trust in another party to protect their information or be part of their infrastructure. Once that third party is compromised, attackers can use it for further attacks, which were phishing and social engineering attempts in my case and in this SolarWind case, the installation of SUNBURST.
I also agree with your point that eliminating the supply-chain risk is unrealistic. Instead, organizations will need to focus on containing the damage or breach when something does go wrong. SolarWinds is a good example of why trusting a legitimate vendor or signed software update isn’t enough. In today’s interconnected environment, trust needs to be accompanied by verification, monitoring, and a plan for when that trust could be broken.
Hi Adwoa, This is a very insightful read. What really stood out to me here is how much we rely on trust when it comes to software and vendors. If an update comes from a trusted vendor, most organizations are going to install it without thinking twice. SolarWinds showed how that trust can also be used against you.
I also like the point about not just focusing on prevention. You can have all the security controls in place and still have something get through. Being able to detect it early, contain the damage, and recover quickly is just as important. That’s probably one of the biggest lessons from SolarWinds for me. Well Written!
One aspect I found particularly interesting is how the SolarWinds incident challenged the assumption that software from a trusted vendor is inherently trustworthy.
I also appreciate the emphasis on supply-chain security as a risk management problem. The key lesson for me is that organizations must assume trust can be compromised and should design their environments,
systems and operations with detection, containment and recovery in mind. As you mentioned, the real question is not whether a supplier could be compromised but how quickly can an organization identify and respond when it happens.
This is such a great write up, Adwoa!
The incident points to the fact that threats can come from the most unexpected way. Cybersecurity teaches us to trust but verify. Code repositories, CI/CD systems, open-source packages, Vendors, SaaS providers or managed service providers can all be victims of such type of compromise, So, its always a good practice to first understand what we are trusting, establish trust through/against industry standards, verify hardware and software before deployment, control exposure and always assume that trust will fail.
Simple tasks like verifying serial numbers, authenticity, integrity and validating sources of materials can help put the assailant at bay
Reading this one may turn towards the idea that using fully open-source software where the code can be inspected by everybody before running would mitigate the potential for an issue like this. But I remember an incident from years ago where university researchers were able to successfully get accepted patches to the Linux kernel containing insecure code. They then went back and committed secure code before any of the code could enter the kernel itself but the principle itself is shown (This led to these researchers getting the entire University of Minnesota banned from contributing to the kernel: https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source ). It is very likely that large open-source projects like these have other purposefully added vulnerabilities brought in by OS updates authored by organizations and governments without an academic interest in bragging about their accomplishments.