Stopping Software Supply Chain Attacks in 2025

Software supply chain attacks in 2025 target not just final applications, but the open source packages, CI/CD pipelines and third-party providers that build and deliver them. To reduce SolarWinds-style risk, security leaders in the US, UK and EU need SBOMs, hardened build pipelines, stricter third-party risk management and alignment with frameworks such as NIST SSDF, CISA guidance, NIS2 and DORA.

Introduction

SolarWinds should have been the “never again” moment for software supply chain attacks but instead it was a starting gun. Since SunBurst, we’ve seen waves of attacks on npm, Nx and other package ecosystems, with AI now helping attackers generate malware and automate large-scale compromise.

Global costs from software supply chain attacks are estimated at around $60 billion in 2025 and are projected to more than double by 2031. At the same time, ReversingLabs and Sonatype report that malicious packages and software supply chain incidents continue to grow sharply year-on-year.

For CISOs from Washington, D.C. to London and Berlin, this means software supply chain attacks are now a board-level resilience problem, not just a niche application security concern. At Mak It Solutions, we see the same pattern when helping clients plan for ransomware, AI-powered threats and secure SDLC improvements across cloud, web and mobile portfolios.

Note
This article is for general information only and does not constitute legal, regulatory or financial advice.

What Are Software Supply Chain Attacks?

A software supply chain attack happens when adversaries compromise software components, build systems or third-party providers so that trusted updates or dependencies silently deliver malware into many organisations at once. After SolarWinds, we’ve learned that these attacks can start in source code repositories, CI/CD pipelines, open source registries or SaaS platforms, but end inside sensitive workloads in New York, London or Frankfurt.

Classic Supply Chain Cyber Attacks vs Modern Software Supply Chain Attacks

Classic supply chain cyber attacks often focused on hardware tampering, counterfeit equipment or compromising logistics vendors. Modern software supply chain attacks, by contrast, target the digital assembly line: open source packages, build scripts, container images, deployment tools and managed services.

For a US healthcare provider or the NHS in the UK, this means a seemingly routine update to a monitoring tool or API gateway could import a backdoor. For German manufacturers or banks supervised by BaFin, attackers might instead compromise a cloud-hosted MES solution or a third-party fintech platform.

How Software Supply Chain Attacks Work in Practice

In practice, most software supply chain attacks follow a repeatable pattern.

Dependency confusion and typosquatting
Attackers publish malicious packages with similar names to internal or popular libraries so build systems pull in the wrong code.

Code repository compromise
Stolen credentials or abused access in GitHub, GitLab or Bitbucket allow adversaries to inject malicious commits or GitHub Actions workflows.

CI/CD pipeline abuse
Compromised build agents, misconfigured secrets or stolen signing keys let attackers backdoor artifacts and still produce “validly signed” releases.

Malicious updates to trusted software
As with SolarWinds Orion, trojanised updates are distributed through normal channels to thousands of endpoints.

The 2025 OWASP Top 10 now explicitly calls out “Software Supply Chain Failures”, underlining that these are no longer exotic edge cases but a mainstream application security issue.

Real-World Examples Beyond SolarWinds

Recent npm and Nx incidents show how easily attackers can weaponise popular JavaScript ecosystems. The Shai-Hulud worm campaigns compromised hundreds of npm packages and tens of thousands of GitHub repositories, harvesting CI/CD secrets and cloud keys before propagating further. CISA has issued specific alerts on widespread npm supply chain compromises and indicators of compromise.

Beyond JavaScript, ReversingLabs observed a double-digit percentage increase in malicious packages uploaded to open source repositories in 2023.  Major cloud ecosystems (AWS, Azure, Google Cloud) and SaaS platforms are also attractive targets: compromising a single observability agent, backup tool or SSO plugin can provide access to thousands of tenants in one move.

SolarWinds and the ‘SunBurst’ Moment for Software Supply Chain Attacks

SolarWinds’ SunBurst backdoor showed how compromising a single Orion update could silently infect thousands of US federal agencies, UK and EU organisations, turning trusted software into a global trojan horse.  It reframed software supply chain attacks from niche espionage tactics into systemic risk.

What Happened in the SolarWinds Orion Supply Chain Attack

In 2020, threat actors compromised the build environment for SolarWinds’ Orion IT monitoring platform. Between March and June 2020, they injected the SunBurst malware into signed Orion updates, which were then distributed to customers through normal channels.

The attackers maintained long dwell times, using the backdoor to move laterally, steal credentials and access email and cloud resources. The campaign was discovered when FireEye investigated its own breach, and publicly disclosed in December 2020, triggering global incident response efforts.

Who Was Affected: From Washington, D.C. to London and Berlin

US victims included federal civilian agencies in Washington, D.C., critical infrastructure operators and Fortune 500 enterprises. In the UK, public sector bodies and regulated industries such as financial services and the NHS had to urgently assess their SolarWinds exposure. Across the EU, institutions in Brussels and major companies in Berlin, Munich and other hubs faced the same “Are we affected?” scramble.

For many boards, this was the first time they saw a third-party IT tool create such deep systemic risk across both on-prem and cloud estates.

Why SolarWinds Changed How We Think About Trust in Software

SolarWinds shattered three assumptions.

Signed updates are always safe
SunBurst proved that if the build system is compromised, code signing alone cannot guarantee integrity.

We’ll see big attacks quickly in our logs
Many victims lacked sufficient logging, telemetry or retention to spot or reconstruct SunBurst activity.

Third-party risk is just procurement paperwork
Concentration risk around a small number of IT and cloud vendors became painfully obvious.

Cybersecurity Ventures now estimates software supply chain attacks will cost the world tens of billions of dollars annually, growing by around 15% per year through 2031.

Lessons Learned from SolarWinds for Governments and Enterprises

The core lesson from SolarWinds is that software supply chains must be governed like critical infrastructure: executive visibility, continuous vendor risk management and tested incident response are now non-negotiable for US, UK and EU organisations.

Governance and Board-Level Oversight of Software Supply Chain Risk

Regulators and national agencies now expect boards to treat software supply chain risk as part of overall operational resilience. In the UK, NCSC has warned that “highly significant” cyber incidents many involving suppliers have risen by about 50% year-on-year, and has explicitly called on FTSE 350 boards to engage.

For US federal suppliers, EO 14028 ties secure software development, SBOMs and supply chain controls directly to eligibility for government work. In Germany and wider EU markets, BaFin, BSI and other supervisors expect boards to oversee ICT and third-party risk under DORA and NIS2.

Many Mak It Solutions clients now fold software supply chain risk into their broader cloud and AI governance programmes rather than treating it as a separate “AppSec only” topic.

Vendor and Third-Party Cyber Risk Management (TPRM) Upgrades

Post-SolarWinds, TPRM teams have been forced to move beyond static questionnaires. Updated DDQs now ask about.

Alignment with NIST SSDF for secure development.

Use of SBOMs and vulnerability management processes linked to EO 14028.

Zero trust approaches for admin and support access into customer environments.

Independent attestations such as SOC 2, PCI DSS and HIPAA security safeguards for SaaS and cloud providers.

In EU financial services, DORA and updated EBA guidelines now form a three-pillar model for third-party risk management, clearly distinguishing ICT providers from non-ICT outsourcers.

Incident Response and Cross-Border Notification After a Supply Chain Breach

When a SolarWinds-style breach hits, time-bound notification rules kick in.

In the US, notification requirements vary by sector (e.g., SEC, HHS for HIPAA, state data breach laws), while CISA coordinates advisories and cross-agency response.

Under NIS2, essential and important entities must provide early warning within 24 hours and more detailed reports within 72 hours and one month.DORA adds strict timelines and content requirements for ICT-related incidents in EU financial entities, with EBA guidance shaping how to operationalise this.

Cross-border teams should rehearse these flows ahead of time: who talks to CISA in Washington, who talks to NCSC in London, and who handles ENISA/BaFin expectations in Berlin and Brussels.

Frameworks, Regulations and SBOMs Shaping Software Supply Chain Security

In the post-SolarWinds era, regulators expect organisations to align software supply chain security with frameworks like NIST SSDF, CISA guidance, NIS2 and DORA and to use SBOMs as a core control for transparency and incident response.

US Landscape Executive Order 14028, NIST SSDF and CISA Guidance

Executive Order 14028, Improving the Nation’s Cybersecurity, sets the tone for US federal and critical-infrastructure software security. It mandates higher security standards across federal software supply chains, including SBOMs, zero trust architecture and enhanced vendor risk assessments.

NIST’s Secure Software Development Framework (SSDF) (SP 800-218) defines a set of secure development practices that agencies now expect vendors to follow and attest to. CISA’s Secure Software Development Attestation Form operationalises this requirement for federal suppliers, creating a standard way to declare conformity.

For SaaS providers in New York or Austin that sell into FedRAMP or state markets, these expectations increasingly spill over into commercial contracts too, not just federal ones.

UK and EU Landscape NIS2, DORA, GDPR/DSGVO and NCSC/ENISA Guidance

In the UK, the NCSC supply chain security collection and the government’s Software Security Code of Practice outline expectations for secure software, supplier assurance and lifecycle management. London-based banks and Open Banking providers are under pressure from both NCSC and the FCA to demonstrate supply chain resilience.

Across the EU, NIS2’s Article 21 requires essential and important entities to address cybersecurity risks in their supply chains and supplier relationships, guided by ENISA’s technical implementation advice.  DORA complements this by setting out detailed ICT risk and third-party risk obligations for financial entities.

For German firms under BaFin and BSI oversight, the interplay between GDPR/DSGVO, DORA and NIS2 means software supply chain evidence (from SBOMs to TPRM artefacts) must be ready for inspection at short notice.

Why SBOMs Became a Critical Control After SolarWinds

SBOMs (software bills of materials) have become a cornerstone control because they answer a single critical question fast: “Where are we exposed?” When a SolarWinds-style event or a new vulnerability like Log4Shell drops, teams with SBOMs can quickly search thousands of applications for affected components across on-prem and cloud.

EO 14028 explicitly calls for SBOMs from software vendors to the US government, pushing the entire ecosystem including Apple platforms, AWS/Azure/GCP marketplaces and major SaaS vendors  toward greater transparency.  NIS2 and DORA don’t always use the term “SBOM”, but their expectations for documented, up-to-date software and supplier inventories effectively require similar capabilities.

For CISOs in London, Berlin or San Francisco, SBOM repositories are now table stakes for regulated workloads not an optional innovation project.

Hardening CI/CD Pipelines and Open Source Dependencies Against Supply Chain Attacks

To harden against software supply chain attacks, organisations should treat CI/CD systems, package registries and open source dependencies as high-value assets, protecting them with least privilege, strong integrity checks and automated detection tools.

Common Attack Paths into CI/CD Pipelines

Recent npm and GitHub campaigns show how attackers exploit CI/CD systems.

Compromised build agents via stolen credentials or vulnerable runners.

Tampered artifacts in package registries or container registries, especially when promotion rules are weak.

Stolen or mismanaged code signing keys, allowing malicious binaries to appear legitimate.

Abused GitHub Actions or GitOps pipelines, as seen in Shai-Hulud campaigns that injected malicious workflows into victim repos.

Locking down CI/CD in AWS CodePipeline, Azure DevOps, GitHub, GitLab or on-prem tools now matters as much as hardening production Kubernetes clusters.

Managing Open Source Software Supply Chain Risks

Open source is now the default for application development, but it comes with real supply chain risks:

Dependency confusion and typosquatting in npm, PyPI and Maven registries.

Malicious maintainers or hijacked projects publishing backdoored updates.

AI-generated malicious packages that blend into the noise of regular updates.

A 2024 survey by BlackBerry reported that more than 75% of organisations had experienced a software supply chain attack in the previous 12 months.ReversingLabs found a 28% increase in malicious packages uploaded to open source registries in 2023, while Sonatype data shows that detected software supply chain attacks roughly doubled again in 2024.

For US SaaS providers, UK Open Banking APIs and German Mittelstand Industry 4.0 suppliers alike, that means dependency hygiene is no longer optional.

Detection and Prevention Tools for Software Supply Chain Attacks

A practical control stack usually includes.

Software composition analysis (SCA) and SBOM generators to inventory components and map vulnerabilities.

Artifact signing and verification (e.g., Sigstore/cosign) integrated into CI/CD.

Binary integrity and provenance checks before deployment to Kubernetes, serverless or on-prem platforms.

Runtime protection and anomaly detection for unusual network calls or process trees from build tools and agents.

Mak It Solutions often combines these with broader cloud observability and cost-optimisation work, so that teams in the US, UK and EU can secure and right-size their environments in the same motion.

Building a Post-SolarWinds Roadmap for US, UK and EU Organisations

A realistic post-SolarWinds roadmap for stopping software supply chain attacks in 2025 sequences quick wins (visibility and SBOMs), medium-term changes (CI/CD hardening and TPRM uplift) and longer-term operating model shifts.

Prioritising Investments by Region, Sector and Risk

Priorities inevitably differ:

US federal suppliers must align first with EO 14028, NIST SSDF and CISA attestation requirements, then extend those practices to commercial lines of business.

UK public sector and critical national infrastructure should map NCSC’s supply chain principles into procurement frameworks and multi-supplier operating models.

German and EU-wide financial services need to treat DORA and updated EBA ICT/TPRM guidelines as their backbone, ensuring boards can evidence compliance to BaFin and EU supervisors.

Risk-based roadmapping means placing the most critical cloud workloads, Open Banking APIs or health data platforms at the front of the queue.

Selecting Partners, Platforms and Managed Services

When evaluating partners and platforms, security leaders should look for:

Native support for SBOM generation and management.

Mappings to NIST SSDF, NIS2 and DORA controls.

Strong integrations with AWS, Azure and Google Cloud, including identity, key management and observability.

Clear evidence for regulators and auditors not just marketing slides.

Mak It Solutions, for example, already helps teams design secure multi-cloud architectures, compare AWS vs Azure vs Google Cloud options and build web and mobile applications with security baked into the SDLC.

Turning Lessons Learned into Ongoing Resilience.

To turn SolarWinds-era lessons into everyday resilience and genuinely stop software supply chain attacks in 2025 and beyond, you need a repeatable playbook, not just a one-off project. Here’s a simple 4-step starter plan for the next 90 days:

Baseline visibility
Generate SBOMs for your most critical apps and map suppliers and cloud services for each.

Lock down CI/CD
Enforce MFA, rotate secrets, restrict runner access and implement artifact signing in your main pipelines.

Refresh TPRM
Update DDQs and contracts to reflect NIST SSDF, NIS2 and DORA, and prioritise high-impact vendors.

Drill incident response
Run a SolarWinds-style tabletop spanning US, UK and EU teams, including regulator and customer communications.

Mak It Solutions can support this with targeted maturity assessments, pilot projects on critical apps and a practical software supply chain security playbook tailored to your regulatory footprint.

Key Takeaways

Software supply chain attacks now focus on open source dependencies, CI/CD systems and third-party SaaS, not just on-prem apps.

SolarWinds’ SunBurst backdoor showed how a single compromised update could impact thousands of organisations globally.

Frameworks like NIST SSDF, EO 14028, NIS2 and DORA now set the baseline for software supply chain governance in the US, UK and EU.

SBOMs, SCA and artifact signing are becoming mandatory controls for regulated workloads and federal/financial suppliers.

Hardening CI/CD pipelines and tightening TPRM are the fastest levers to reduce real-world exposure.

A practical 90-day roadmap can combine quick wins (visibility) with medium-term changes (pipeline security) and long-term operating model shifts.

If you’d like help turning these ideas into a concrete roadmap for stopping software supply chain attacks in 2025, Mak It Solutions can work with your CISO, engineering and risk teams to baseline your current supply chain posture, prioritise investments and stand up SBOM and CI/CD security capabilities that align with NIST SSDF, NIS2 and DORA. Start with a focused maturity assessment on a handful of critical applications, then expand once the playbook is proven. ( Click Here’s )

You can reach the team via the Contact page on Mak It Solutions to schedule a working session with our cloud, security and analytics specialists.

FAQs

Q : Are small and mid-sized businesses really targets for software supply chain attacks?
A : Yes. Attackers increasingly see small and mid-sized businesses as attractive stepping stones into larger enterprises and government agencies. NCSC has highlighted that smaller suppliers in big UK supply chains are especially vulnerable, and US and EU regulators now expect critical entities to assess their suppliers’ cyber posture, not just their own. Even if you don’t run your own CI/CD pipelines, using compromised SaaS tools, plugins or agents can still expose your environment.

Q : How do software supply chain attacks differ from traditional data breaches or ransomware incidents?
A : Traditional breaches often start with phishing, exposed credentials or vulnerable internet-facing systems, and then pivot directly inside your network. Software supply chain attacks typically compromise upstream components – open source packages, build systems or third-party vendors so malicious code arrives through trusted updates or integrations.The result is that many organisations are hit simultaneously, sometimes long before the campaign is detected.

Q : What should I ask my SaaS and cloud providers today about their software supply chain security?
A : Ask providers whether they follow NIST SSDF, can share SBOMs for critical components and have completed CISA’s secure software attestation (if they sell into US public sector).In the UK and EU, check how they address NIS2 and DORA expectations for ICT third-party risk, and whether their own suppliers are covered by similar controls. You should also probe their incident response processes, log retention and notification commitments.

Q : How often should we refresh our SBOMs and third-party risk assessments in regulated industries?
A : For regulated workloads, SBOMs should be regenerated whenever you ship a significant new release or change core dependencies monthly or even per-build for fast-moving services.TPRM reviews for critical suppliers are typically annual at minimum, but NIS2 and DORA effectively push towards more continuous monitoring and on-demand evidence. Many organisations blend periodic deep reviews with automated checks on vulnerabilities, security ratings and attestations.

Q : Can cyber insurance policies cover losses from SolarWinds-style software supply chain attacks?
A : Many cyber insurance policies do cover some losses from third-party or supply chain incidents, but wordings vary and may exclude nation-state activity or systemic infrastructure events. Insurers increasingly expect evidence of strong controls aligned with frameworks like NIST SSDF, NIS2 and DORA before offering favourable terms. You should work with legal, risk and brokers to clarify how upstream software incidents are treated and what responsibilities you retain around patching, SBOMs and TPRM.