EoS Security Strategy#

This guide addresses concerns regarding the use of dependencies, such as specific .NET and NodeJs versions, that may have reached their official "End of Support" (EoS) from their respective vendors. While it is natural to be concerned about security vulnerabilities in unsupported components, Critical Manufacturing's approach, particularly when deploying the MES in containerized environments like Kubernetes, significantly mitigates these risks.

The core principle is that the security of an application is not solely dependent on the direct patching of every single component by its original vendor. Instead, a robust, multi-layered security strategy, coupled with the inherent isolation and control offered by container platforms, provides a strong defense.

Why "End of Support" Dependencies Aren't a Major Risk#

Even when a dependency like a .NET runtime version is no longer officially supported by Microsoft or NodeJS LTS versions, our MES maintains a high level of security posture due to several critical measures described on the subsections below.

1. Containerized Environments: Contained, Isolated, and Hardened#

Our MES runs within containerized environments, where dependencies like .NET are isolated from the host system and other workloads. This fundamental isolation prevents potential vulnerabilities from spreading or affecting the underlying operating system or Kubernetes node.

All containers are built using minimal base images, drastically reducing the overall attack surface and dependency footprint. This means less unnecessary software that could introduce vulnerabilities.

We implement stringent runtime controls to enhance security:

• Read-only file systems: Limits the ability of malicious code to modify critical system files.
• No privilege escalation: Prevents processes from gaining elevated permissions.
• Non-root users: Containers operate with restricted user privileges, minimizing potential damage.
• Kubernetes NetworkPolicies: Restricts communication paths between containers, preventing unauthorized lateral movement.

Even if a vulnerability were to exist in the .NET or NodeJS runtimes, exploiting it within this highly controlled and isolated environment is significantly more challenging and often ineffective.

2. Runtime Security and Behavioral Monitoring#

Beyond static isolation, you may setup and use your own runtime security tooling to actively monitor container behavior for any anomalies or suspicious activity.

Tools like Falco and eBPF-based monitors continuously observe container behavior. Any unexpected behavior—such as unusual process calls, attempts at privilege escalation, or unauthorized network access—triggers immediate alerts or automatic containment actions. This provides real-time visibility and control, effectively compensating for the lack of official vendor patching for specific dependencies.

Critical Manufacturing Observability Service can also contribute to the live monitoring of the MES.

3. Trusted, Audited Supply Chain#

Even though the .NET runtime within a deployed MES container might not change frequently, the container itself is under our full control and undergoes rigorous security validation:

• Static Security Scanning: Containers are subjected to static security scanning before deployment to identify and address potential vulnerabilities.
• Signature Verification: We use signature verification to ensure the authenticity and integrity of our container images.
• Controlled, Reproducible Builds: Our build processes are controlled and reproducible, eliminating manual tampering and ensuring consistency.
• Signed, Vetted Images: We only ship signed, vetted images through our CI/CD (Continuous Integration/Continuous Delivery) process, effectively locking down the supply chain even with a static runtime.

4. Kubernetes-Level Protections#

The underlying Kubernetes platform provides its own robust set of security features that significantly enhance the overall security posture, independent of individual application dependencies:

• Role-Based Access Control (RBAC): Tightly limits administrative rights and access to Kubernetes resources.
• Namespace Isolation: Provides logical isolation for multi-tenant or multi-application deployments, preventing cross-contamination.
• Automated Patching and Upgrades: The cluster infrastructure itself is actively maintained, with automated patching and upgrades, ensuring the foundational security evolves.
• Secret Management: Kubernetes offers secure secret management with encryption and rotation capabilities, protecting sensitive data.

These Kubernetes controls are actively maintained and audited, ensuring that the system's security posture continuously evolves, even if a specific application layer component remains static.

Why Our Approach Is Not a Significant Risk: A Comparison#

To further illustrate the benefits of our approach, consider the stark differences between legacy VM/server deployments and modern Kubernetes with containers:

In Summary#

We maintain a consistent .NET/NodeJS version over the lifespan of your MES release, which can exceed Microsoft’s 3-year and NodeJS 30-month LTS window. While this might seem like a security risk, our strategy prevents it. Our confidence is based on several factors:

• Strong isolation and immutability of containers.
• Hardened, minimal runtime environments.
• Active behavioral monitoring and runtime enforcement.
• Robust Kubernetes-native controls and infrastructure patching.

This strategy ensures the safe, long-term operation of your MES, meeting modern security standards even without constant, direct .NET or NodeJS updates from the respective vendors.