Accurics today announced it has integrated its tool for discovering violations of security policies that occur when developers provision infrastructure as code with both the continuous integration and continuous delivery (CI/CD) platform and the static application security assessment testing (SAST) tools from GitLab.

Om Moolchandani, chief information and security officer (CISO) and CTO for Accurics, said both integrations make it easier for developers to discover security issues earlier as part of a DevSecOps workflow using the company’s Terrascan tools.

Many of the issues organizations are having with cloud security these days can be traced back to misconfigurations created by developers when configuring infrastructure using tools such as Terraform. Accurics created Terrascan to identify those misconfigurations.

The integration with GitLab makes it easier to incorporate Terrascan into a DevOps workflow in a way that also aggregates data collected from both SAST and dynamic application security testing (DAST) tools, said Moolchandani. That approach effectively unifies what today are two separate cloud infrastructure and application development pipelines by enabling DevOps teams to employ threat scores to enforce security policies as code that are deemed too risky to deploy with block builds, he added.

At the same time, the integration with SAST and DAST tools provides the context developers need to prioritize remediation efforts before applications are deployed in a production environment, noted Moolchandani.

Organizations of all sizes are now trying to strike a balance between two conflicting agendas. On the one hand, infrastructure-as-code (IaC) tools such as Terraform have played a critical role in enabling developers to build and deploy applications faster. The issue is that developers lack the security expertise required to ensure infrastructure is secured properly at a time when cybercriminals are more aggressively seeking to compromise software supply chains. Organizations most likely won’t slow down the rate at which applications are being deployed to make sure software supply chains are not compromised. However, in the absence of best DevSecOps practices—which still are not widely implemented—there may be a backlash against shifting application responsibility left toward developers.

The challenge that creates is most organizations don’t have enough security expertise available to review applications in a timely manner before they are deployed, which results in them hoping security issues will be discovered and remediated during the application update cycle before cybercriminals find a way to exploit a vulnerability.

Of course, hope does not make for an application security strategy. Organizations will need to find ways to enable developers to better secure applications while simultaneously making it easier for cybersecurity teams to maintain a zero-trust IT environment that reduces the chances organizations will be breached via, for example, a phishing attack to steal developer credentials.

Regardless of how DevSecOps workflows and zero-trust IT architectures are implemented, it’s clear organizations have run out of time to resolve longstanding security issues that are now making the kinds of headlines no one wants to see.

Overview

Citrix announced that its Application Delivery Controllers (ADC) have been validated to run on Red Hat OpenShift, the enterprise Kubernetes platform. As part of the alignment, Red Hat also certified the Citrix Operator—software designed to simplify the deployment and lifecycle management of Citrix ADC instances on OpenShift clusters.

What Is a Citrix ADC and Why Does It Matter for Kubernetes?

An Application Delivery Controller sits between clients and application servers, handling far more than a basic load balancer. A typical ADC provides:

• Layer 4–7 load balancing – distributing traffic intelligently across services
• Web Application Firewall (WAF) – filtering malicious requests before they reach application code
• SSL/TLS offload – terminating encrypted connections at the ADC to reduce backend compute overhead
• Server health monitoring – detecting and routing around unhealthy instances
• Service graphs – visualising the topology and health of microservice dependencies

In a Kubernetes environment, these capabilities complement—and in some cases replace—lighter-weight alternatives such as the Envoy proxy or a standalone Istio service mesh.

Red Hat OpenShift Joins AWS EKS, GKE, and AKS

According to Pankaj Gupta, Senior Director for Product Marketing for Networking at Citrix, Red Hat OpenShift joins Amazon EKS, Google GKE, and Microsoft AKS as validated Kubernetes platforms for Citrix ADC. The addition of OpenShift is strategically significant because OpenShift can be deployed both on-premises and in public clouds, making it a foundation for hybrid and multi-cloud ADC federation—a single, consistent ADC policy spanning data-centre racks and cloud VPCs.

The Role of the Citrix Operator

The Operator pattern—originally defined as a framework by CoreOS (later acquired by Red Hat, which was subsequently acquired by IBM)—packages operational knowledge about a piece of software into a Kubernetes controller. Citrix’s certified Operator automates day-1 and day-2 tasks for ADC instances running on OpenShift, including initial deployment, configuration updates, and scaling, without requiring manual intervention via the ADC management CLI.

Deployment Form Factors

Citrix ADC is available in multiple deployment form factors, giving teams flexibility to match the ADC to their infrastructure:

• CPX – containerised ADC, runs as a sidecar or standalone pod inside Kubernetes
• VPX – virtual machine appliance, deployable on hypervisors or cloud instances
• BLX – software ADC running directly on bare-metal Linux
• MPX / SDX – dedicated hardware appliances for high-throughput data-centre use

Organisations that already own MPX or SDX hardware can extend those assets to front Kubernetes workloads rather than replacing them, reducing capital expenditure during a cloud-native migration.

Integration with the Cloud-Native Observability Ecosystem

Citrix ADC integrates with a range of open-source observability and delivery tooling commonly used in cloud-native stacks, including:

• Prometheus & Grafana – metrics collection and dashboarding
• Spinnaker – continuous delivery pipelines
• Fluentd & Kibana – log aggregation and visualisation
• OpenTracing & Zipkin – distributed request tracing

Citrix Service Graph provides end-to-end visibility across microservice transactions, helping teams track the health of individual services as container versions are updated.

ADCs vs. Service Meshes: A Different Architectural Argument

Gupta’s position is that tools like Envoy-based proxies or Kubernetes-native service meshes such as Istio address only part of the problem: they operate entirely within the Kubernetes boundary and offer no continuity with the existing ADC estate that already handles monolithic application traffic.

Citrix’s argument is that extending ADCs—rather than introducing a parallel proxy layer—enables a single management console to cover both legacy monolithic applications and modern microservices. This matters in practice because most enterprises are not rewriting their entire application portfolio at once. Applications are modernised incrementally: isolated processes are gradually extracted as microservices while the monolithic core continues to run. A unified ADC platform can serve both without requiring separate operational toolchains.

Gupta also signalled that service mesh capabilities are expected to converge into larger ADC platforms over time—positioning ADCs as the long-term unifying layer for application traffic management regardless of deployment model.

Key Takeaways for DevOps and Platform Engineers

• Citrix ADC is now validated on Red Hat OpenShift, making hybrid-cloud ADC deployment more practical for OpenShift users.
• The certified Citrix Operator reduces Day-2 operational overhead when managing ADC instances in Kubernetes.
• Multiple form factors (CPX, VPX, BLX, MPX/SDX) mean existing hardware investments do not need to be abandoned.
• Deep integrations with Prometheus, Grafana, Spinnaker, Fluentd, OpenTracing, and Zipkin align ADC observability with standard cloud-native tooling.
• The ADC-vs-service-mesh debate is not necessarily binary; Citrix’s roadmap hints at service mesh capabilities being absorbed into the ADC platform.

This article is based on reporting originally published by Container Journal in August 2019.