In the cybersecurity ecosystem, we tend to focus our efforts on development security. We invest significant resources in auditing proprietary code, looking for programming flaws, misconfigurations, or technical vulnerabilities in our own systems. However, the reality of today’s threats shows that the most critical incidents do not always occur due to a coding error, but because of something far more difficult to patch: supply chain compromise and trust in third parties.
Recently, the compromise of the update infrastructure of Notepad++ once again highlighted the fragility of this implicit trust model. Protecting the perimeter is no longer enough when we invite external actors into our network through automatic updates and software dependencies.
Below, we analyze how these types of attacks are redefining corporate security and why international standards and the latest European regulations now require a strong focus on suppliers.
The Notepad++ Case: Anatomy of a Trust Compromise
To understand the real scope of a supply chain attack, it is essential to analyze the recent incident that affected Notepad++.
The attackers did not exploit a vulnerability in the text editor itself. The Notepad++ source code was not modified, nor were programming flaws identified in the main application. Instead, the attack focused on the distribution mechanism, specifically the WinGUp component, responsible for managing automatic software updates.
What exactly happened
Between mid and late 2025, advanced threat actors compromised part of the infrastructure serving the project’s official updates. From that point on, a highly selective and stealthy supply chain attack was carried out:
- The user requested a legitimate update from Notepad++.
- The update component contacted a server that appeared to be official.
- For specific selected targets, the server delivered a malware-modified binary, credibly signed and packaged.
- The updated software continued to function correctly, avoiding immediate suspicion.
- The deployed malware enabled cyber espionage, persistence, and communication with external command-and-control infrastructures.
The attack was not massive. Its danger lay precisely in its targeted nature: only specific profiles were attacked, allowing adversaries to maintain a low profile for months and delay detection.
The key lesson
This incident illustrates one of the most critical risks of modern security:
software can be functional, legitimate, and seemingly secure, yet its origin may be poisoned.
Implicit trust in update channels — especially in widely used tools considered “secure” — has become a high-value strategic attack vector.
Why Is the Supply Chain the New Battleground?
Supply chain attacks exploit a basic principle: organizations trust their suppliers. If we download a tool from an official website or integrate a widely used library, we assume the risk is minimal.
This assumption is no longer valid.
Current risks can be grouped into three major vectors that must be actively monitored:
Compromise of Distribution Infrastructure
As in the Notepad++ case, where the update channel is hijacked and used as an entry point.
Dependency Contamination (Dependency Confusion)
Injection of malicious code into open-source libraries (npm, PyPI, Maven, etc.) that developers automatically integrate into corporate software.
Compromise of the Build Environment (CI/CD)
Infiltration into the supplier’s build systems, injecting malware even before the software is digitally signed, as occurred in the well-known SolarWinds case.
In all these scenarios, the attacker benefits from a key advantage: they inherit the trust of the legitimate supplier.
Regulatory Framework: Third-Party Security Is No Longer Optional
The severity and recurrence of these incidents have not gone unnoticed by regulators. In Europe, the approach has radically changed: third-party risk management is no longer a recommendation — it is a legal and auditable requirement.
ISO/IEC 27001:2022
The latest version of the standard significantly strengthens controls over suppliers. Annex A (controls 5.19 to 5.22) requires:
- Formal supply chain security management.
- Supplier risk assessment.
- Continuous monitoring of compliance with security requirements.
NIS2 Directive
The new European directive marks a turning point. Article 21.2.d explicitly states that essential and important entities must manage supply chain-related risks, considering the specific vulnerabilities of each supplier and service provider.
National Security Framework (ENS)
In its updated version, the ENS reinforces the obligation to establish security conditions in the acquisition of ICT products and services, requiring guarantees proportional to the risk of the service provided.
Omnibus Package and Digital Transparency
The Omnibus regulatory package, although primarily focused on consumer protection and digital services, reinforces a key principle:
the obligation of transparency, integrity, and control in software update and distribution processes.
This directly impacts automatic update mechanisms and suppliers’ responsibility over their supply chain.
Cyber Resilience Act (CRA)
The Cyber Resilience Act introduces, for the first time, horizontal cybersecurity obligations for products with digital components, including software.
Its requirements include:
- Security by design & by default.
- Digital supply chain risk management.
- Secure and verifiable update mechanisms.
- Obligation to remediate vulnerabilities throughout the product lifecycle.
With the CRA, supply chain security ceases to be a “technical best practice” and becomes a direct legal responsibility of manufacturers and suppliers.
Defense Strategy: From “Trust” to “Verify”
At Inprosec, we know that banning third-party software is not viable. The key is to abandon blind trust and adopt a continuous verification model aligned with current regulatory frameworks.
We propose a strategy based on three pillars:
Inventory and Visibility (SBOM)
You cannot protect what you do not know.
- What it is: a Software Bill of Materials (SBOM) detailing all components and dependencies of an application.
- What it’s for: it enables rapid identification of exposure in the event of a supplier or specific library compromise and facilitates compliance with NIS2, ISO 27001, and the CRA.
Hardening the Update Process
Updates are necessary, but they are also one of the most critical attack vectors.
- Hash verification: verifying the integrity of binaries (SHA-256) through independent and trusted channels.
- Sandbox environments: testing critical software updates in isolated environments before mass deployment, analyzing anomalous behavior.
Zero Trust Network Principles
Assuming compromise is possible means limiting its impact.
- Segmentation: workstations and servers should not have unrestricted Internet access.
- Whitelisting: allowing only strictly necessary communications to known update domains, blocking connections to unknown C2 infrastructures.
Conclusion: Origin Is as Critical as Code
The Notepad++ incident is not an anomaly — it is a symptom of a deeply interconnected digital ecosystem.
Information security no longer ends at our firewall. It extends to our suppliers, their development processes, their distribution infrastructures, and their update mechanisms.
With the arrival of NIS2, ENS, Omnibus, and the Cyber Resilience Act, this reality is formalized: digital supply chain management is a legal, technical, and strategic obligation.
Adopting a proactive stance, demanding transparency from suppliers, and applying internal compensating controls is the only way to protect data and ensure operational resilience in an environment where trust must be verified, never assumed.
Does your organization comply with ISO 27001, NIS2, and CRA supplier management requirements? At Inprosec, we can help you audit and strengthen your digital supply chain.