The SolarWinds breach of 2020 was a landmark supply chain attack in which attackers

inserted malicious code into software updates, compromising thousands of organizations

worldwide. This paper examines how the SolarWinds attack was executed, its global
impact, and the responses it prompted. We review technological and policy solutions –
such as software bill of materials (SBOM), code signing, and supply chain security
frameworks – aimed at preventing similar incidents. We also consider the legal and
regulatory context, with a focus on New Zealand’s cybersecurity environment. Drawing on
recent studies and reports, we analyze best practices and identify gaps in current legal
approaches. In doing so, we highlight the importance of third-party risk management and
international collaboration. Our findings underscore that SolarWinds exposed critical
weaknesses in software development and oversight, leading to accelerated adoption of
supply chain risk management guidelines and influencing both technology policy and
emerging legislation.

Introduction
Software supply chain attacks occur when malicious actors insert or exploit vulnerabilities
in software components or update processes, compromising downstream users. In such
attacks, attackers target not the end-user systems directly, but trusted software
dependencies and build [Link]. These attacks are particularly insidious
because they exploit trusted channels, enabling attackers to deliver malware widely with
legitimate-looking software. While supply chain compromises have occurred in the past,
they became highly prominent in 2020–21. For example, since 2020 major incidents like
the SolarWinds breach, the Log4j vulnerability, and an attack on the open-source XZ Utils
library have come to [Link]. These high-profile cases affected thousands of
organizations, demonstrating the ease with which a single supply chain vulnerability can
spread widely. Supply chain attacks are especially dangerous because malware is
“embedded inside a legitimate product,” allowing attackers to “access the networks of
many organizations in a single stroke”[Link].

Notable examples. Beyond SolarWinds, earlier supply chain attacks provide context. In
2017, the NotPetya malware was delivered via compromised software updates, crippling
Maersk and other companies [Link]. In 2020, the SolarWinds Orion network
management software was trojanized: attackers injected a backdoor into Orion updates,
which were digitally signed and deployed to customers. According to analysis, malicious
updates were delivered to up to 18,000 SolarWinds [Link]. Similarly, in
late 2021 the widespread Log4j logging library vulnerability was exploited by attackers to
inject code into numerous systems. These incidents underscore that software
dependencies, development tools, and even hardware firmware can all be attack vectors.

Scope and objectives. This paper focuses on the SolarWinds incident as a case study of
supply chain compromise. We first detail the mechanics of the attack and its direct
consequences. Then we review the ensuing changes in cybersecurity practices, including
technical safeguards and risk-management policies. We examine proposed solutions such
as SBOMs, code signing, and new development frameworks. A key aim is to link these
security measures with legal and regulatory developments, particularly those relevant to
New Zealand. We assess how laws and standards (both international and NZ-specific)
address software supply chain risks. Finally, we discuss New Zealand’s technology
environment and awareness, considering how global lessons from SolarWinds apply
locally. Throughout, we draw solely on authoritative reports and research to ensure
accuracy and transparency.

How the SolarWinds Attack Happened

In early 2020, attackers (attributed to a state-sponsored group) compromised the build
environment of SolarWinds, the maker of Orion network management software. They
inserted a trojan backdoor (known as Sunburst/Solorigate) into legitimate Orion software
updates. Critically, these malicious updates were signed with SolarWinds’ official digital
certificate, making them appear authentic. SolarWinds later confirmed that the attack
allowed the perpetrators to deliver “infected software updates” to as many as 18,000
[Link]. These updates were released between March and June 2020.
Because the malware was embedded in trusted, signed updates, it bypassed normal
security checks and propagated widely.

CISA reported that the Orion update “injected an APT” (advanced persistent threat) into
multiple critical government and private [Link]. Once installed on victim
networks, the backdoor lay dormant for weeks, enabling the attacker to conduct
reconnaissance. The adversary also deployed additional payloads such as Teardrop (a
stealthy Windows backdoor) and Sunshuttle (an HTTP/HTTPS proxy) that established
covert command-and-control [Link]. From a forensic viewpoint, the
initial “staging” of the attack was accomplished by abusing SolarWinds’ code-signing
process. According to security analyses, SolarWinds’ software release pipeline lacked
adequate code review and verification; the signed code was “neither checked for accuracy
nor access paths”[Link]. This failure of the economy of mechanism principle
(minimizing complexity) allowed the malware to evade early detection.
Supply chain attack technique. The SolarWinds case exemplifies a software supply chain
attack: malware was injected into routine supplier updates and then disseminated to end
[Link]. In supply chain terminology, SolarWinds acted as the supplier and its
customers were downstream. This approach is especially effective when the supplier’s
software has privileged access (e.g. Orion often ran with high privileges on enterprise
networks). In SolarWinds’ own words, many of its customers (including Fortune 500
companies and government agencies) had widely-used “Orion software” on their
[Link]. By targeting this trusted pathway, the attackers gained a foothold (“initial
foothold on the internal networks of several federal – mainly U.S. – government agencies
and private companies”[Link]) without needing to breach each organization individually.

After initial infection, the attackers selectively targeted high-value victims. According to the
Danish Centre for Cyber Security (CFCS), the hackers “only exploited the backdoor to
target high-profile victims,” using bespoke malware against specific [Link]. In
practice, the attack hit a few dozen U.S. federal agencies and major corporations. In total,
at least nine U.S. agencies and over 100 private firms were confirmed compromised by the
[Link]. The attackers operated primarily for espionage: CFCS
concluded the attack was “conducted by state-sponsored hackers for the purpose of
cyber espionage”[Link]. (U.S. authorities have publicly attributed the intrusion to a
Russian intelligence group.) Notably, although the malware reached 18,000 networks,
most victims saw no follow-on exploitation. The attackers “attacked these selected
victims with bespoke malware and sophisticated attack techniques”[Link], rather than
indiscriminately striking all infected networks.

Impact and Aftermath

The SolarWinds breach had profound global impact. Thousands of organizations
inadvertently downloaded the compromised Orion [Link], making this “one of the
most comprehensive supply chain attacks known to date”[Link]. It penetrated U.S.
federal government networks (including Departments of Treasury, Commerce, Homeland
Security, and parts of the [Link]) and prominent private-sector entities. The
U.S. Cybersecurity and Infrastructure Security Agency (CISA) and FBI warned that the
attack was a “serious threat” at national [Link]. Security firm FireEye (now
Mandiant) discovered its own network had been breached on Dec 8, 2020, alerting the
world to the campaign. Public reporting emphasized that SolarWinds “took down US
federal government agencies and private companies” and reminded all IT personnel that
supply chain risks are [Link].
This incident validated concerns about supply chain risk. The New York State Department
of Financial Services (DFS) called SolarWinds “to date, the most visible, widespread, and
intrusive … software supply chain attack”[Link]. DFS noted that supply chain attacks
are particularly dangerous because they can compromise “many organizations in a single
stroke”[Link]. The breach demonstrated that even sophisticated organizations
(including technology firms and intelligence agencies) could be surprised by such an
attack. It highlighted major weaknesses in vendor risk management: for example, DFS
found that some financial firms had failed to classify SolarWinds as a critical vendor
despite Orion’s privileged access to [Link]. In response, regulators
emphasized the need for vigorous third-party risk management. The DFS report advised
organizations to thoroughly assess and monitor their suppliers, saying that third-party
oversight is a “key part” of cybersecurity [Link].

Operationally, many affected entities reacted quickly once the breach was known.
According to DFS, 94% of impacted companies removed the vulnerable Orion code within
three days of disclosure (by disconnecting systems or applying patches)[Link]. This
rapid remediation underscores the diligence of many organizations. However, DFS also
observed that many firms had immature patch management [Link].
Specifically, it noted a lack of a consistent “patching cadence” for critical systems,
implying that some updates were not applied promptly even when known. The SolarWinds
incident exposed these weaknesses. In its aftermath, U.S. federal agencies issued
emergency directives (e.g. CISA Emergency Directive 21-01) mandating fixes to Orion, and
numerous technical analyses were shared publicly.

The breach prompted companies and governments worldwide to re-evaluate security

practices. In industry, there was a renewed focus on verifying software integrity: e.g.
implementing reproducible builds, rigid code-signing processes, and network monitoring.
The SolarWinds case also spurred legislation proposals in some countries. At the policy
level, organizations that analyze such attacks (like NIST and private consortia) accelerated
work on supply chain frameworks and best practices. For example, governments
increased promotion of Software Bill of Materials (SBOM) and multi-factor code signing as
defenses against Trojanized updates.

Proposed Technological and Policy Solutions

In the wake of SolarWinds, cybersecurity experts have advanced several defenses for
software supply chains. A prominent example is the Software Bill of Materials (SBOM). An
SBOM is a detailed inventory of all components and dependencies in a software
[Link]. It acts like a “list of ingredients” for code. By generating SBOMs for
software releases, organizations can rapidly trace vulnerable libraries or malicious
inclusions. CISA describes the SBOM as a “key building block in software security and
software supply chain risk management”[Link]. In practice, SBOMs enable rapid impact
analysis when a vulnerability is disclosed: if you know exactly which product versions
include a given component, you can quickly identify at-risk systems.

Other technical safeguards include rigorous code signing and review. The SolarWinds
attackers bypassed checks by obtaining legitimate signing credentials. In future, signing
keys should be protected with hardware security modules and dual control, and signed
binaries should be subject to post-signature analysis. Automated tools can re-verify signed
updates; for example, research suggests using frameworks like STONE to verify signatures
and inspect [Link]. Enforcing strong development practices (such as
comprehensive code review and least-privilege builds) would have likely caught the
injected backdoor earlier. The incident underscored several of Saltzer and Schroeder’s
security design principles, such as economy of mechanism and complete mediation.
Better adherence to these principles (e.g. simpler, transparent build processes and
mediating every update) has been recommended.

Government and industry have launched or updated supply chain security frameworks
to guide organizations. For instance, the U.S. National Institute of Standards and
Technology published the Secure Software Development Framework (SSDF) and updated
NIST SP 800-161 to cover supply chain risk management. The industry OpenSSF project
developed a Secure Software Development Scorecard. Google introduced SLSA (Supply-
chain Levels for Software Artifacts) to recommend technical maturity levels. A recent study
notes that NIST’s SSDF, OpenSSF Scorecard, and SLSA are among the key frameworks
adopted [Link]. In fact, one analysis compiled 73 “safeguards” from ten
prominent frameworks into a unified model (the P-SSCRM framework) to help
organizations know which security tasks are [Link]. These frameworks
cover tasks like asset inventory, dependency scanning, continuous monitoring, and
incident response.

In practice, experts rank certain mitigations as especially urgent. Research mapping attack
techniques to mitigations finds that role-based access control (RBAC), continuous
system monitoring, and network boundary protection are among the highest priorities
against supply chain attacks. Conversely, it identified gaps: for example, sustainability of
open-source projects and use of “environmental scanning” tools were missing from all
existing frameworks. This suggests that even comprehensive adoption of today’s
recommended practices could leave software vulnerable to new classes of
[Link]. Thus, the SolarWinds case has accelerated calls for dynamic, multi-
layered defense-in-depth: combining procedural controls (policies, audits, supply chain
transparency) with technical tools (SBOM, secure builds, intrusion detection).

Lastly, governmental policies have been updated. For example, CISA and the White House
have issued guidance mandating SBOMs for federal procurement, and the EU’s draft Cyber
Resilience Act includes provisions on software transparency. In the U.S., agencies are
raising requirements for vendor security assessments. Financial regulators like NYDFS
have signaled that stringent third-party oversight and incident reporting are mandatory
parts of compliance. In this way, the attack has driven regulatory attention: the emphasis
is on proactive risk management, not just reactive patching.

Legal and Cybersecurity Frameworks Relevant to New

Zealand
From a legal perspective, no country was fully prepared when SolarWinds hit. In the U.S.
and EU, investigators began considering new regulations on software provenance and
supplier accountability. Recent legal analysis highlights that most national regulations are
still too general to effectively enforce supply chain security. For instance, Ludvigsen et al.
note that “current types of national regulation are not technology specific enough” to
compel companies to defend against software supply chain [Link]. In practical
terms, this means many cyber laws (e.g. data protection, national defense) address
outcomes but not the software development process itself. There are efforts, however, to
strengthen legal frameworks. The EU’s proposed NIS2 Directive and the UK’s upcoming
regulations both mention supply chain security measures.

In New Zealand, supply chain security is being integrated into broader cyber and critical
infrastructure law, though not yet via new standalone statutes. New Zealand’s Cyber
Security Strategy (updated periodically) emphasizes risk management and sector
resilience, implying that organizations should consider supplier security. Indeed,
government guidelines (such as the NZ Information Security Manual) have long advised
agencies to include supplier risks in their overall security [Link]. On
the privacy side, New Zealand’s Privacy Act sets data breach reporting rules, but does not
directly govern software integrity. Thus, protections against supply chain attacks in NZ
currently rest on general obligations (e.g. to safeguard data) and on voluntary standards.
As Ludvigsen et al. suggest for Europe, NZ too must vigilantly update its laws to match
cyber [Link].
One positive sign is alignment with international best practices. New Zealand’s authorities
have endorsed frameworks like NIST’s SCRM guidance. For example, NIST Special
Publication 800-161 provides a model for organizations to “identify, assess, and mitigate
ICT supply chain risks at all levels” of their [Link]. While NIST SP 800-
161 is technically aimed at U.S. federal agencies, NZ organizations can voluntarily use it.
There is also increasing awareness in NZ that technical controls (like SBOM and secure
build) should be backed by policy. Financial regulators (analogous to NYDFS) encourage
firms to treat critical suppliers with elevated scrutiny.

To summarize, New Zealand’s current legal framework on cyber security is evolving. The
SolarWinds case has spurred discussion in NZ about contractual obligations for software
vendors and about adopting minimum security requirements for imported software.
Although no NZ-specific supply chain cyber law has been enacted, government agencies
(such as CERT NZ and the NCSC) continue to issue alerts and guidance. For example,
when SolarWinds was disclosed, the NZ National Cyber Security Centre published a
security advisory urging organizations to urgently review their Orion installations and apply
fixes (by referencing industry advisories)[Link]. This reflects a growing role for the
state in coordinating response to such incidents. Going forward, NZ is likely to incorporate
SCRM concepts into its regulatory standards (e.g. by requiring good governance and
contingency planning around technology suppliers), paralleling global moves.

New Zealand’s Technology Landscape and Awareness

Efforts
New Zealand is a highly connected, digital economy with extensive reliance on imported
software and cloud services. Its organizations – from banks and utilities to public agencies
– depend on global software supply chains. As such, New Zealand’s technology ecosystem
is not immune to the vulnerabilities exposed by SolarWinds. In recent security discourse,
NZ experts have explicitly identified supply chain disruptions as a significant national
[Link]. The edited volume State of Threat notes that “disruptions to
supply chains and maritime trade” are among the key security challenges facing Aotearoa
New [Link]. This recognition underscores that both physical and cyber
supply chains are on the country’s risk radar.

At the organizational level, awareness is growing. Many NZ companies follow international

cybersecurity best practices. The government’s cyber security framework encourages
firms to inventory their digital assets (hardware and software) and to assess vendor
relationships – steps that directly mitigate supply chain risk. Industry groups and
consultants routinely include supply chain questions in cyber risk assessments. For
example, New Zealand’s “Certified Cyber Security Practitioner” guidelines (NZISM) include
directives that agencies should “incorporate supply chain risks into an organisation-wide
risk assessment”[Link]. In practice, this means NZ institutions are urged to evaluate
software vendors and require secure development practices contractually.

New Zealand has also participated in global efforts on SBOMs. In 2022, the government’s
Cyber Security Strategy Action Plan indicated support for improved software transparency.
Moreover, New Zealand organizations selling technology internationally may now
encounter SBOM requirements abroad, further incentivizing domestic uptake. There are
local initiatives as well: seminars and industry working groups have been held to
disseminate SolarWinds lessons. The Government Communications Security Bureau
(GCSB) and CERT NZ have issued cybersecurity advisories, including one specific to
SolarWinds Orion in December 2020, recommending immediate patching or disabling of
affected [Link].

In summary, while New Zealand has not yet enacted specialized supply chain cyber
legislation, the country’s technology community is increasingly aware of the issue. NZ’s
approach has been to align with international standards (such as NIST SP 800-161) and to
emphasize voluntary compliance and sector guidance. Educational campaigns have
stressed that best practices (SBOMs, rigorous updates, supplier audits) are relevant to
NZ’s exporters and critical infrastructure alike. The convergence of legislative signals and
industry guidance suggests that NZ will continue adapting to the SolarWinds wake-up call,
integrating supply chain scrutiny into its cybersecurity culture.

Conclusion
The 2020 SolarWinds attack exposed fundamental flaws in how modern software
ecosystems trust and verify their components. By hijacking a trusted vendor’s update
process, the attackers demonstrated that organizational cybersecurity boundaries can be
breached indirectly via suppliers. In response, both the public and private sectors have
accelerated adoption of supply chain security measures. Technically, solutions like
SBOMs, secure build pipelines, and continuous monitoring are being rolled out. On the
policy side, governments are updating cybersecurity regulations and procurement rules to
demand transparency and accountability from software vendors.

For New Zealand, the implications are clear: supply chain security cannot be an
afterthought. The SolarWinds incident underscores the need for NZ organizations to treat
software vendors as critical security partners. Embedding supply chain risk assessment
into regulatory standards, and fostering industry-wide awareness, are key steps. While NZ
has made progress in aligning with international frameworks, ongoing vigilance is required.
Legally, this may mean revisiting existing laws (such as the Privacy Act and critical
infrastructure regulations) to more explicitly cover software integrity.

In conclusion, the SolarWinds case has reshaped the cybersecurity landscape worldwide.
It has catalyzed new technical standards (e.g. SBOM adoption), invigorated global
frameworks (NIST, SLSA, etc.), and prompted policy reviews. As New Zealand integrates
these lessons, its cyber defenses – and legal structures – will hopefully become more
resilient against the next generation of supply chain threats.

Bibliography
Center for Cyber Security (CFCS). (2021). SolarWinds: State-sponsored global software
supply chain attack: The story behind one of the largest supply chain attacks in history (1st
ed., Nov. 2021)[Link]. CFCS.

Chowdhury, P. D., Tahaei, M., & Rashid, A. (2022). A Retrospective Security Analysis of
SolarWinds & Log4j. arXiv:2211.02341 [[Link]][Link].
[Link]

Cybersecurity and Infrastructure Security Agency (CISA). (n.d.). Software Bill of Materials
(SBOM)[Link]. U.S. Dept. of Homeland Security. Retrieved 2025, from
[Link]

Hamer, S., Bowen, J., Haque, M. N., Hines, R., Madden, C., & Williams, L. (2025). Closing
the Chain: How to reduce your risk of being SolarWinds, Log4j, or XZ Utils.
arXiv:2503.12192 [[Link]][Link]. [Link]

Hoverd, W. (Ed.), & McDonald, D. A. (Ed.) (2023). State of Threat: The challenges to
Aotearoa New Zealand’s national [Link]. Massey University Press.

Ludvigsen, K. R., Nagaraja, S., & Daly, A. (2022). Preventing or Mitigating Adversarial Supply
Chain Attacks: A Legal Analysis. arXiv:2208.03466 [[Link]][Link].
[Link]

Mirakhorli, M., Garcia, D., Dillon, S., Laporte, K., Morrison, M., Lu, H., Koscinski, V., &
Enoch, C. (2024). A Landscape Study of Open Source and Proprietary Tools for Software
Bill of Materials (SBOM). arXiv:2402.11151 [[Link]][Link].
[Link]

National Institute of Standards and Technology. (2015). Supply Chain Risk Management
Practices for Federal Information Systems and Organizations (Special Pub. 800-161)