The modern cyber threat landscape has finally dispelled any illusions IT architects may have held regarding the security of third-party code. According to the ENISA Threat Landscape 2025 report, software supply chain attacks have become one of the most critical vectors for compromising corporate systems. Data from the European regulator, which analyzed 4,875 incidents between July 1, 2024, and June 30, 2025, indicates that essential entities under NIS2 accounted for 53.7% of all affected organizations. Furthermore, digital infrastructure and services were the source of approximately 27.7% of confidential data breaches.
For organizations subject to the European NIS2 directive, this marks the end of the era of formal compliance. Reactive scanning and periodic patching are no longer sufficient to stop threats integrated directly into legitimate libraries. Modern engineering practice requires a shift toward an architectural paradigm where any third-party component is treated as potentially compromised by default.
Supply chain under fire: why reactive patching fails NIS2 requirements
Traditional security approaches relied on perimeter defense and regular system updates following the disclosure of known vulnerabilities (CVE). However, in the face of modern threats, this approach is inherently reactive. Attackers increasingly employ tactics such as typosquatting, hijacking developer accounts for popular open-source libraries, or injecting hidden backdoors directly into source code during the development phase.
The NIS2 directive imposes strict requirements for managing cybersecurity risks in supply chains. Organizations are obligated to evaluate not only their own infrastructure but also the security posture of the solutions they purchase or integrate. According to ITU data, as of 2025, approximately two-thirds of the world's population uses the internet. This scale of interconnection between digital services makes every integration point a potential gateway for attack. If a system's architecture allows third-party code to execute with maximum privileges, the first successful attack on a dependency will lead to the compromise of the entire infrastructure.
Anatomy of a threat: how a third-party library vulnerability compromises the system core
A typical enterprise application contains hundreds of direct and thousands of transitive dependencies. When a developer integrates a popular npm package (e.g., for image processing or date formatting), that code typically inherits the same execution rights within the container or server as the primary business logic.
If an attacker gains control over that package's repository and releases an update containing malicious code, the sequence of events is immediate:
- The component initiates an outbound connection to the attacker's command-and-control (C2) server.
- The malicious code scans environment variables for database passwords, API keys, and secrets.
- Using the application's database access rights, the attacker performs unauthorized reading or modification of critical data.
As a result, traffic that appears legitimate to a firewall becomes a vehicle for data exfiltration. No classic WAF will detect anomalies because the requests originate from a trusted process.
Component verification via SBOM: the first step toward supply chain transparency
To meet NIS2 requirements for supply chain transparency, the fundamental step is implementing an SBOM (Software Bill of Materials)—a detailed, machine-readable passport of all software components and dependencies.
As noted by experts at Anchore, using an SBOM allows for the automation of verification processes and compliance monitoring for supply chain security. However, an SBOM alone does not guarantee full NIS2 compliance and does not protect against zero-day attacks within legitimate packages. The primary value of an SBOM lies in providing visibility: it allows organizations to instantly determine if their infrastructure contains a newly discovered vulnerability, reducing incident response time from weeks to minutes.
Architectural isolation: designing systems with zero trust for third-party code
Since it is impossible to completely avoid third-party libraries, a reliable solution is to limit the blast radius through architectural isolation and micro-segmentation. As noted in the Microsoft Azure Well-Architected framework (Cost Optimization section), modeling costs and risks during the design phase is significantly more effective and cheaper than optimizing infrastructure after the fact.
The principle of domain isolation requires that third-party code performing specific tasks (such as PDF generation or file parsing) runs in isolated containers with minimal system privileges and no direct database access. Interaction between the system core and third-party modules must occur exclusively through typed interfaces using API gateways.
Data-level access control (RLS/ACL) as the final line of defense
Even if an attacker manages to compromise an application service, the system must not allow them to gain uncontrolled access to data. Traditional permission management at the table level is insufficient.
The final line of defense is the implementation of access control directly within the platform core or at the DBMS level:
- ACL (Access Control List): clear definition of subject rights to perform operations on objects.
- RLS (Row-Level Security): dynamic data filtering at the row level. If a compromised service attempts to read all records in a table, the system core will return only those rows belonging to the current security context.
In practice, building such barriers requires a platform that supports these mechanisms at its architectural level. An example of such a technological foundation is the full-stack JavaScript low-code platform UnityBase, developed by the Intecracy Group alliance (where InBase is a key, but not the only, developer). The platform uses a unified Domain metadata model that links data descriptions, APIs, and system behavior.
Thanks to the built-in RLS mechanism and ACL support (available in Enterprise and Defence editions), developers can isolate the domain model at the core level. If an integrated third-party npm package is compromised, it cannot execute unauthorized database queries that bypass business rules: every access operation is automatically validated by the DBMS-agnostic ORM layer, regardless of the application code.
Built-in security in practice: designing resilient infrastructure without excessive costs
| Architectural barrier | What it solves | Limitations and nuances |
|---|---|---|
| Verification level (SBOM) | Prevents the use of known vulnerable components during the build phase. | Does not protect against zero-day attacks in legitimate packages. |
| Domain isolation level | Separates third-party integrations and API gateways from critical business logic. | Requires precise design of interaction interfaces. |
| Data access level (RLS/ACL) | Limits a compromised service's access to only authorized rows in the database. | Must be implemented at the platform core level, not the application code. |
Building secure infrastructure that aligns with the spirit and requirements of the NIS2 directive requires abandoning the concept of a "trusted internal perimeter." Combining transparency via SBOM, isolation of third-party modules, and strict data-level segmentation allows for the creation of a resilient system capable of localizing incidents and protecting critical information even if one component is directly compromised.
FAQ
How exactly does implementing an SBOM help meet NIS2 directive requirements for supply chain security?
An SBOM provides transparency and machine-readable visibility into software composition, allowing organizations to automatically and rapidly identify vulnerable components. This is key to meeting NIS2 risk management requirements, although it does not inherently block zero-day attacks.
What is the difference between standard access control (ACL) and row-level security (RLS) when a service is compromised?
ACL typically controls access to an object or table as a whole (e.g., permission to read an orders table). RLS operates at the level of specific records (rows), allowing a service to interact only with data directly belonging to its current session context, which significantly minimizes the data breach radius during a compromise.
Is it possible to isolate third-party npm packages without completely rebuilding a monolithic architecture?
Yes. High-risk or specific functions that utilize third-party dependencies can be moved into separate microservices, isolated containers, or serverless functions (sandboxes). The main system will interact with them exclusively through restricted APIs, blocking direct database access.