In December 2020, at the time of the SolarWinds breach, I recollect that I thought it was another advanced hack. However, getting into the technical report and observing the way how offenders changed the playbook in the following five years, it became obvious: SolarWinds was not merely an incident–it was a manual.
By 2025, supply chain attacks have become almost routine, where countries individually carry out a supply chain attack once a week. The strategy of SUNBURST and SUNSPOT did not vanish, only got upgraded, automated and even multiplied into GitHub repos, npm works, and CI/CD pipelines. In a breakdown of how exactly the SolarWinds attack succeeded, how the lifecycle has transformed, and how modern attack vectors appear going into 2026, this article has been condensed.
Table of Contents
The SolarWinds Breach: SUNBURST and SUNSPOT Explained
It is not the scale of the SolarWinds compromise that is remarkable, due to the fact that it was approximately 18,000 customers that downloaded the trojanized Orion update, but rather the purity with which it was executed. So the attackers did not use a zero-day exploit and force their way. They were incorporated into the software.
How SUNSPOT Hijacked the Build Process
All this became possible with SUNSPOT being the malware. The attackers breached the development environment of SolarWinds and dropped SUNSPOT into the production line, according to the analysis provided by the CrowdStrike and Mandiant. It was not a single code injection but rather a long-lasting one.
Here’s how it worked:
- SUNSPOT used to monitor the build environment of certain compilation actions of Orion software.
- On finding the appropriate target build, it substituted authentic source code with malicious code.
- This replacement was made prior to compilation and thus, the malicious code was included in the signed binary.
- Once the build was complete, SUNSPOT repackaged its tracks by restoring the original source files.
What made this so effective? The rogue DLL was an Orion part that was a replica of a normal part. It was digitally signed using the SolarWind certificate with SolarWind own certificate and it was automatically checked and it was integrated with thousands of other files and it is just a normal Orion installation.
SUNBURST’s Stealthy Command and Control
After the trojanized update was downloaded to the customer environments, the process of SUNBURST took effect. However it did not begin right away. The malware took some two weeks before it became functional as it integrated into normal network traffic, pretending the Orion Improvement Program protocol.
I have inspected the decompiled samples of SUNBURST and it is very sophisticated:
- Delayed execution: 12-14 day sleeping so as to prevent the sandbox detection.
- Domain generation algorithm (DGA): Subdomains that had been used as the subdomains of the valid avsvmcloud[.]com were utilized to encode the information of the victim.
- Process blocklisting: Scanned with security tools and stopped in the case of the detection.
- Selective targeting: Second-stage payloads such TEARDROP or Cobalt Strike BEACON were only applied to a minor leftover of infected organizations.
The intruders were not attempting to breach all the 18,000 consumers. They were selectively targeting high-value targets, such as government agencies, security firms, and critical infrastructure operators with more in-depth attacks.
Attack Lifecycle: From Reconnaissance to Full Compromise

The SolarWinds understanding can be used to plot the greater supply chain attack lifecycle. This trend is repeated when it comes to other vectors, be it an npm package or a rogue build server.
Stage 1- Reconnaissance and Initial Access
The attackers were inside the network of SolarWinds before SUNSPOT was deployed. The investigation by FireEye alluded to the possibility of the first breach being a credential theft or phishing of developers having high access.
In modern reconnaissance, one is seeking:
- Developer accounts that are allowed to access important repositories.
- Construct servers that have weak authentication or open security holes.
- Third-party connectors (GitHub Actions, Azure DevOps, Jenkins) using excessively liberal tokens.
During my experience testing internal pipelines, organizations tend to give CI/CD systems much more access than the organization requires. One vulnerable service account will install a code and cause some building and signature of artifacts-all this is what an attacker requires.
Stage 2 – Code Injection and Tampering
Attackers inject malicious code once in the build environment in a manner that it will remain during the compilation and signature. The SolarWinds model (SUNSPOT-style build tampering) is still widespread, although some variations have been developed:
- Direct commits of code: With stolen developer credentials, code being backdoored to major branches is merged together.
- Dependency poisoning: Substituting valid library with code that contains malicious code as part of the build fetch process.
- Manipulation of build scripts: To download and run malicious code, changing the configuration files of CI/CD (GitHub Actions YAML, Jenkinsfiles) is needed.
In a report released by ReversingLabs, more than 1,300% of malicious packages increase in npm, PyPI, and RubyGems has been recorded between 2020 and 2023, demonstrating that the attackers industrialized the injecting process.
Stage 3 – Distribution Through Trusted Channels
Distribution is the genius in supply chain attacks. Rather than phishing thousands of targets one after another, the attackers attack a single vendor and make the software update mechanism to work out the rest.
SolarWinds announced SUNBURST by:
- Authorized, sign and digitized software updates through the automatic update option at the Orion platform.
- Whitelisted download servers which were trusted by customers.
- Authorized outlets that could bypass majority of perimeter controls.
This trend has been now applied to the package registries, container images, and cloud templates. When the users know they can trust the source, they will simply download and implement it without further questioning.
Stage 4 – Activation and Lateral Movement
Activation is the step when the attackers shift between the presence and the exploitation. SUNBURST two weeks of dorm was planned – they evaded most of the detection windows used by sandboxes and behavioral analysis tools.
Once active, the malware:
- Hampered pair command-and-control (C2) links under the pretence of genuine traffic.
- Obtained more tools (TEARDROP dropper, Cobalt Strike, self made frameworks)
- Transfer to different environment later based on stolen credentials of compromised environment.
- Leaked confidential information or had a constant presence in the form of intelligence collection.
Mandiant observed that the attackers had high operational security, infrastructure rotation, ephemeral payloads and not noisy activities that would cause alarms to go off.
I’ve Seen Modern Supply Chain Attack Vectors Evolve

Though build-pipeline compromise became popular by SolarWinds, the threat world has become excessive. This is what was really being attacked now.
GitHub and Code Repository Attacks
GitHub is not merely a code host, it is a key component of the supply chain of millions of projects. It is attacked on numerous layers by attackers:
Personal Access Tokens (PATs) and SSS keys: I observed that in the security audits of the machines, security auditors found that developers often leave the long lived tokens in plain-text on their machines, or hard-code in their scripts. A stolen set of these credentials allows complete access to the repository, even being able to make malicious commits.
Suiciding Workflows: Malicious Attackers Hack developer accounts in order to edit CI/CD workflows and add malicious steps that are executed when they automatically perform builds. These are workflows that are frequently given access to the production environments, artifact registries and cloud infrastructure as engineers.
Dependency Confusion: Attackers use these registries (npm, PyPI) and publish malicious packages of a name similar to that of an internal dependency. It might also be the case the build system is not configured to put special emphasis on private sources, and thus it ends up grabbing the public (malicious) one.
Open-Source Ecosystem Attacks
The open-source software supply chains represent large attack surfaces. Towards the middle of 2025, ReversingLabs stated that demand software supply chain incidents averaged 26 a month, an increase of approximately two times the demand level in 2024.
Common techniques include:
- Typosquatting Registering packages under similar name to well-known libraries (ex: “reqests” instead of requests).
- Maintainer account takeover Fraud in which package maintainers are phished or credential stuffed and then managed to publish backdoored updates.
- Malicious pull requests Malariais creating apparently useful code patches, which in turn inject a backdoor or data exfiltration obsidiosyncrasy in the code.
The thing that makes it especially perilous is trust. Although it is the developers who presume that packages contribute thousands of downloads and have many contributors. This is used by attackers by targeting popular projects such that one rogue update serves millions of installations.
CI/CD Pipeline Compromise
The new jewels are build pipelines. Breaking a CI/CD system provides attackers with the capability to populate all artifacts traversing through it.
Weaknesses in environments that I have tested can be of the following types:
- Instances of hyperprivileged build servers (have access to an administrator, cloud root).
- Environment variables that had secrets and API keys that were not rotated.
- Lack of isolation between build jobs (build jobs can access artifacts of other jobs)
- Failure to verify inputs of build (dependencies, base images, scripts) Lack of integrity Transferable, not inspectable, to verify input-validation.
Analysis of 2025 by Veracode also pointed to the fact that integrity validation and provenance tracking is weak in most organisations and easy to introduce malicious code into the production build without detection.
High-Profile Targets and Industry Lessons Since SolarWinds
SolarWinds demonstrated that attacks in the supply chain are scale-friendly. Since the time, attackers have perfected their methods and targets.
Managed Service Providers and Cloud Platforms
ENISA listed cloud-based and managed service providers (MSPs) as valuable supply chain suppliers to attackers breeding centralized platforms to have access to hundreds or thousands of downstream consumers.
Notable incidents include:
- Kaseya VSA (2021): REvil ransomware organization has broken into Kaseyas remote management system, distributing ransomware to an estimated 1,500 downstream enterprises.
- Okta breach (2022): Hackers got access to the support environment of Okta, which potentially compromised customer authentication information.
- 3CX VoIP repeatable (2023): The hackers of North Korean interest trojanized the 3CX desktop application and hit hundreds of thousands of users around the world.
The moral of the story is that multiplier effects are the only ones that are targeted by attackers. A single compromise of an MSP or SaaS provider will provide access to the whole customer base.
Critical Infrastructure and Government Agencies
SolarWinds was particularly aimed at government organizations, defense contractors and operators of critical infrastructure. This pattern continues.
The confirmed victims in the case of SolarWinds included, the U.S Treasury, Department of Commerce, Department of Homeland security, and other big cybersecurity companies.
Attackers were not interested in making a profit but instead in spying on people, thereby placing value on intelligence more than ransomware.
This has escalated its target to:
- Control systems and SCADA network in the energy sector.
- Medical device firmwares (equipment, medical devices, and data storage in clinics) and Hospital management systems.
- Telecommunications equipment (5G network equipment, routing equipment)
Emerging AI and ML Supply Chain Risks
AI model supply chains have been one of the areas that I have been keeping a keen eye on. In its report on how AI will be 2025, ReversingLabs specifically identified AI and supply chains of AI and ML software as a new attack frontier, as threat actors now start attacking both AI model repositories and AI-generated code.
The possible attack vectors are:
- Poisoned data used in training that places backdoor into models.
- Evil pre-trained models A malicious Botox model written in Hugging Face or TensorFlow Hub or PyTorch.
- Code generated by AI which inserts malicious libraries or serves to inject subtle vulnerabilities.
- Ide plugins consisting of compromised AI development IDE (VS Code extensions, JetBrains tools)
This remains a growing menace, yet the organizational infrastructure of AI development resembles the software supply chain strong-room databanks, personal tycoon removes and for any reason extensive confidence presumption.
Software Supply Chain Security: Defenses That Actually Work
The positive thing I have to say is that defenses are on the upturn. Companies and government are promoting more stiff Software Supply Chain Security measures that would close the vulnerabilities that existed in SolarWinds.
SBOMs and Transparency Requirements
SBOMs have ceased to be a nice-to-have and become mandatory. SBOMs are now legally required in CISA 2024-2025 guidance on SBOMs and in the EU software vendors, forcing transparency to become law.
SBOM comprises of all the components, libraries, and dependencies of a software artifact. When properly used, it makes it possible to:
- Quick response of the vulnerability stage (being immediately aware whether you have been compromised by a new CVE or not)
- Supply chain risk (risk identification of high-risk or non-maintained dependencies)
- Triage (reflecting on compromised elements of deployed systems)
Nonetheless, SBOMs are not sufficient. These have to be accompanied by integrity verification (digital signatures, attestations) and ongoing monitoring.
Build Attestations and Provenance Tracking
In order to avert SUNSPOT-style manipulation, organizations are embracing build attestation systems such as SLSA ( Supply-chain Levels for Software Artifacts). These frameworks ensure:
- Hermetic builds: Build systems are reproducible and closed off Build systems are closed off.
- Signed provenance Each artifact has a metadata to attest to the provenance of where, when and how it was constructed.
- Checking gates Checking systems reject artifacts whose attestations are invalid.
Gartner rates that Software Supply Chain Security tools will be positively utilized in 60 percent of large enterprises by 2025 (increasing to 85 percent in 2028) in large measure due to the pressures of compliance and successive high-popular breaches.
Runtime Integrity Monitoring
Although it is important to have good build controls, runtime monitoring is also important. I’ve used tools that detect:
- Unanticipated process execution (particularly entry by software update mechanics)
- Deviant network connections of trusted applications.
- Any intrusion involving file integrity breach on key system directories.
- The pattern of credential theft or lateral movement.
The SolarWinds attack became successful in part due to the ability of runtime monitoring to not suspect the C2 beaconing of SUNBURST. The modern software supply chain security methods applies behavioral analytics and threat intelligence to detect the post-compromise activity earlier.
What’s Coming: 2026 and Beyond
In the future, the attacks on a supply chain will remain industrialized. Here’s what’s likely:
AI-Assisted Attacks: By generating code automatically, attackers will find it easier to build polymorphic code and avoid scaling of statical analysis.
Regulatory Force: The Cyber Resilience Act is just one of many more regulations which can force vendors to develop secure-by-design and require vulnerability disclosures.
Use Shift-Left Security: Companies will incorporate supply chain controls that are earlier in the development process as dependencies are scanned and build inputs are verified and policy gates are provided as required in CI/CD.
Enhanced Attack on Developers: Social engineering of developers will go up to a notch and this will involve credential theft, coupled with supply chain injection.
Conclusion
The SolarWinds breach was not any wake-up call – it was a playbook. The compromise of the supply chain was entrenched, as seen through SUNSPOT build dizzyfishing up to stealthy C2 of SUNBURST. The techniques have found their ways in GitHub repositories, open-source ecosystems, and CI/CD pipelines 5 years later.
What’s changed is awareness. SBOMs are becoming standard. Attestations of buildings are taking off. Vendors are being made accountable by the regulators. However, attackers are also evolving, attacking AI pipelines and cloud applications and targeting developer workflows to a growing degree.
Survivability of the next wave is not only the organizations that will respond to breaches, but instead will design supply chains to be integrity-based and transparent throughout.
I’m a technology writer with a passion for AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and curious. and encourage participation I continue to research innovation and technology. Let’s connect and talk technology!



