Blogs

Ingress NGINX Retirement: Treating Community Projects As Critical Vendors

Ingress NGINX has been the de-facto front door for a huge number of Kubernetes clusters. It started life as an early, generic implementation of the Ingress API — flexible, cloud-agnostic, and easy to drop into almost any environment. Over time it became the default answer to “how do I get traffic into my cluster?” for on-prem, self-managed and even some managed Kubernetes setups. That is exactly why its retirement matters. The project will continue on best-effort only until March 2026, with no new versions or security fixes afterwards. A core ecosystem component is effectively moving into read-only mode. Users now have to pick a path: adopt a Gateway API-based controller, move to a vendor-backed ingress, or rethink traffic management around managed load balancers. oai_citation:0‡Kubernetes

Continue reading

Distroless Done Right: Curated Minimalism Before Image Minimalism

Distroless is the right destination, but the first move is curated understanding, not a pre-trimmed base. Start by building a system that you can explain: enumerate every component actually used, record why it’s present, and generate an SBOM that reflects your choices—not the entire contents of a generic “slim” image. Only when owners can articulate “what, why, and where” for each package does minimalism become a defendable boundary. Security enables safety when the boundary is intentional, observable, and reversible.

Continue reading

Why Behavioral-Model Asset Security Platforms Will Not Take Off

From a technical perspective, a behavioral-model–driven asset-security platform for vehicles and robots seems elegant.
It connects behavioral anomaly detection → remote inspection → emergency takeover into a closed loop, providing theoretically complete observability and protection.
Yet under real industrial logic, such systems will not take off.

Continue reading

Guarding GenAI Integrity on Kubernetes: Identity Down, Policy Up

AI workloads amplify Kubernetes’ flexibility—and its failure modes. Integrity requires controls that understand models, data paths, and runtime drift, not just pods and namespaces. Push identity down with workload-bound credentials; push policy up with context from model criticality and data sensitivity. Watch the gray zones: GPU device plugins, sidecar sprawl, and egress to model registries. Least privilege, immutable images, and runtime enforcement are table stakes; without AI-aware guardrails, the blast radius grows silently. If latency budgets reject CPU hooks, pivot to eBPF plus network policy—not “trust me” exemptions.

Continue reading

Activities flow chart of ISO 21434 Clause 15

ISO 21434

ISO/SAE 21434 is an international standard that provides a framework for addressing cybersecurity risks throughout the lifecycle of automotive systems. It defines requirements and guidelines for managing cybersecurity in road vehicles, from the concept phase to design, development, production, operation, and decommissioning. The standard aims to ensure that cybersecurity is integrated into the entire product development process, helping organizations identify and mitigate vulnerabilities, respond to incidents, and continuously improve their cybersecurity posture in response to evolving threats.

Continue reading

Activities flow chart of ISO 21434 Clause 8

ISO 21434

ISO/SAE 21434 is an international standard that provides a framework for addressing cybersecurity risks throughout the lifecycle of automotive systems. It defines requirements and guidelines for managing cybersecurity in road vehicles, from the concept phase to design, development, production, operation, and decommissioning. The standard aims to ensure that cybersecurity is integrated into the entire product development process, helping organizations identify and mitigate vulnerabilities, respond to incidents, and continuously improve their cybersecurity posture in response to evolving threats.

Continue reading