The modern cyber threat landscape is forcing critical infrastructure enterprises to rethink their approach to third-party software integration. According to the ENISA Threat Landscape 2025 report, based on an analysis of 4,875 incidents between July 1, 2024, and June 30, 2025, organizations classified as essential entities under the NIS2 directive accounted for 53.7% of all victims. Furthermore, the digital infrastructure and services sector accounted for approximately 27.7% of recorded data breaches. These figures clearly indicate that the software supply chain has become a critical attack vector.
For CTOs and CISOs, this represents a paradigm shift. Standard approaches limited to periodic library scanning for known vulnerabilities (CVE) and reactive patching are no longer sufficient to guarantee compliance with the stringent requirements of NIS2. Integrating third-party components, closed proprietary libraries, or external API solutions creates uncontrolled blind spots in an enterprise's infrastructure. If third-party code executes with the same privileges as the core system, any vulnerability within it compromises the entire corporate perimeter.
Supply chain under the NIS2 spotlight: why reactive patching is no longer effective
The NIS2 directive requires organizations to move beyond mere incident response and implement proactive risk management measures. The traditional approach to supply chain security is limited to analyzing software component specifications and updating dependencies. However, there is always a time gap between the discovery of a zero-day vulnerability and the developer's release of an official patch, during which the system remains at risk.
Data from the Cisco Cybersecurity Readiness Index 2025, based on a study of 8,000 cybersecurity leaders across 30 markets, confirms that network resilience and identity intelligence are critical protection factors. When a third-party component is integrated directly into an environment without proper isolation, it becomes a weak link. If a developer's repository is compromised, an updated library can automatically deliver malicious code into the protected perimeter. This is why security by design has become an essential tool for protection.
Architectural blind spots: how third-party components compromise the corporate perimeter
The primary danger lies in the absence of clear architectural barriers. If an enterprise integrates a report generation module or a document processing library into the same process where the main application server runs, the third-party code gains access to system memory, the file system, and the database.
This architecture introduces the following risks:
- Excessive privileges: Third-party code may execute unauthorized database queries or access system files unnecessary for its core functionality.
- Lack of independent audit: If a third-party module manages its own logging, a compromised component can hide its activity by simply deleting local log files.
- Uncontrolled network activity: A library may send stolen data to attacker-controlled servers via open network ports.
To mitigate these risks, an integrated component must be treated as a potentially untrusted object whose activity is restricted by the platform's external mechanisms.
Security by design in practice: isolating third-party code via domain metadata
One of the most reliable methods for implementing security by design is isolating third-party code within the system by applying access policies at the domain metadata level. Instead of direct database access, interaction is mediated through an abstract metadata layer.
This architectural approach is implemented in the low-code platform UnityBase, a joint development of the Intecracy Group—an alliance of independent companies linked by partner agreements and share exchanges, not a single company or holding. The platform uses a Domain Metadata model that unifies data, interface, and business logic descriptions. When integrating third-party modules into systems built on this platform, the code does not receive direct access to the DBMS. Data interaction occurs exclusively through declaratively described entities.
This allows for the enforcement of strict rules: the third-party module sees only the objects and attributes permitted by the metadata. Even in the event of a critical vulnerability within the module itself, an attacker cannot move beyond the defined model because the platform core validates all requests.
Access control and end-to-end audit: implementing RBAC and RLS
To ensure incident traceability, as explicitly required by NIS2, a centralized audit of actions is necessary, independent of the internal settings of the integrated component.
Enterprise solutions such as the Megapolis.DocNet ECM or the Scriptum.DMS document management system, which utilize UnityBase platform mechanisms, strengthen supply chain security through built-in access control:
- Role-Based Access Control (RBAC): The third-party module is authorized under a service account with the minimum necessary set of roles.
- Row-Level Security (RLS) and ACL: Access is restricted at the level of specific records (rows). For example, an OCR service will only have access to files transmitted within a specific process, without the ability to read the entire archive.
- Immutable audit (Audit Trail): Any attempt by a module to access data or perform an operation is recorded by the platform's system log (DataHistory), which is protected from modification.
It is worth noting that using an architecturally secure platform significantly reduces risks but does not guarantee automatic NIS2 compliance. Technical measures must be complemented by organizational efforts, such as rights auditing and infrastructure monitoring.
On-premises as a security foundation for critical infrastructure
For energy, government, and critical infrastructure sectors, on-premises deployment remains a priority, allowing organizations to avoid risks associated with cross-border data transfers and dependence on cloud providers.
UnityBase supports isolated on-premises environments. In the Enterprise (EE) and Defence (DE) editions, security tools are expanded to include server module integrity control, integration with certificate authorities (CRL, OCSP) for working with digital signatures according to national standards, and additional traffic encryption.
Local deployment allows network engineers to block outbound traffic from application servers to the global network, leaving only strictly regulated channels. This prevents data exfiltration in the event of a module compromise, as it loses connection to its command-and-control (C2) servers.
Architectural control matrix for third-party components for NIS2 compliance
| Isolation Level | Implementation Method | NIS2 Compliance |
|---|---|---|
| Data isolation | Restricting code access via Row-Level Security (RLS) and ACL at the platform level. | Prevention of unauthorized access and data leakage (which accounted for 27.7% of incidents in digital infrastructure according to ENISA). |
| Audit and monitoring | Independent logging of component actions by the platform, without relying on the component's own logs. | Ensuring continuous incident traceability and rapid response. |
| Infrastructure control | Deployment in an isolated on-premises environment with strict limitations on network requests. | Control over the operating environment and minimization of remote intervention risks. |
Protecting the supply chain in the era of the NIS2 directive requires abandoning blind trust in integrated libraries. Only by building systems based on architectural isolation (security by design) can enterprises turn blind spots into a controlled and manageable perimeter, ensuring the continuity of critical infrastructure operations.
FAQ
How can NIS2 compliance be ensured when using third-party APIs and libraries?
NIS2 compliance requires moving away from direct third-party code integration into the system core and transitioning to a Zero Trust model. It is necessary to apply architectural isolation, restrict access rights via RBAC and RLS at the platform level, and implement independent auditing of all module actions through platform-level logging.
What is the role of the Domain Metadata model in protecting the software supply chain?
Domain Metadata acts as a protective barrier between a third-party component and the database. The code interacts exclusively with declarative abstractions rather than the DBMS. This ensures that even if a vulnerability exists, the third-party module cannot access data outside of its permitted scope.
Why is on-premises deployment important for critical infrastructure in the context of NIS2?
On-premises deployment in an isolated environment allows network engineers to fully control outbound traffic. Blocking unauthorized connections neutralizes compromised third-party code by preventing communication with attackers' command-and-control (C2) servers and preventing data exfiltration.