Overview

In mid-2019, Kubernetes security company Alcide published findings from a cross-environment analysis conducted using its Alcide Advisor tool — a multi-cluster vulnerability scanner designed to audit Kubernetes and Istio environments against security best practices and compliance benchmarks. The results painted a concerning picture of how organizations were (or weren’t) handling sensitive configuration data and network segmentation in their Kubernetes workloads.

Key Findings

The analysis surfaced three significant gaps in Kubernetes security hygiene across the scanned environments:

• 89% of deployment scans showed that organizations were not using Kubernetes’ native Secrets resources. Instead, sensitive values such as credentials, tokens, and API keys were being wired into workloads in plain text — whether via environment variables, ConfigMaps, or container image layers.
• Over 75% of scanned deployments used workloads that mounted high-risk host file systems, including /proc, which can expose sensitive kernel and process information and widen the attack surface significantly.
• None of the surveyed environments had implemented network segmentation using Kubernetes’ native NetworkPolicy resources, meaning workloads could communicate freely within the cluster with no enforced isolation boundaries.

Why Kubernetes Secrets Matter

Kubernetes Secrets are objects designed to store and manage sensitive information — such as passwords, OAuth tokens, and SSH keys — separately from application code and pod specifications. When used correctly, Secrets reduce the risk of sensitive data being accidentally committed to version control, baked into container images, or exposed through environment variable inspection.

However, Secrets are not encrypted at rest by default in older Kubernetes versions, and they are base64-encoded (not encrypted) within etcd unless cluster operators explicitly configure encryption at rest. Simply adopting Secrets is a meaningful step forward compared to plaintext embedding, but it is not sufficient on its own. Teams should also:

• Enable etcd encryption at rest for Secret objects.
• Use RBAC to restrict which service accounts and users can read Secrets.
• Consider integrating with an external secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for stronger lifecycle management.
• Avoid passing Secrets as environment variables where possible; mounting them as files reduces certain exposure vectors.

The Risk of Mounting Sensitive Host Paths

Mounting host file system paths such as /proc into a container gives that container visibility into — and in some cases the ability to interact with — low-level kernel and process data. This is occasionally necessary for observability or system-level tooling, but should be treated as an exception rather than a default. When misused or misconfigured, these mounts can enable container escape or privilege escalation attacks. Security-conscious teams should:

• Audit all hostPath volume mounts in pod specifications.
• Apply PodSecurityPolicy (deprecated in Kubernetes 1.21+) or its successor, Pod Security Admission, to restrict which host paths workloads may mount.
• Avoid mounting /proc, /sys, or / unless there is a documented, reviewed operational need.

The Absence of Network Policies

Kubernetes NetworkPolicy resources allow teams to define rules that govern how pods communicate with each other and with external endpoints. Without any NetworkPolicy applied, all pods in a cluster can, by default, communicate freely — a flat network topology that violates the principle of least privilege and makes lateral movement trivially easy for an attacker who compromises any single workload.

That none of the environments surveyed by Alcide had implemented any NetworkPolicy was one of the starkest findings in the report. Implementing even basic default-deny ingress and egress policies, then selectively allowing required traffic, dramatically reduces the blast radius of a compromised pod.

Alcide Advisor and Azure DevOps Integration

Alongside the findings, Alcide announced that Alcide Advisor had been integrated with Azure DevOps, making it available in the Microsoft Visual Studio Marketplace at the time of the announcement. The integration was designed to embed continuous Kubernetes security scanning directly into CI/CD pipelines, covering:

• Vulnerability scanning of master API server and worker node components, including container runtimes.
• Support for multiple cluster types, including AKS, Kops, and AKS Engine.
• Continuous configuration drift detection across multi-team, multi-cluster environments.

The goal was to shift security checks left — catching misconfigurations and policy violations during development and staging rather than after production deployment.

Practitioner Perspective

David J. Brewer, founder of Eupraxia Labs — a software vendor running workloads on Azure AKS — was quoted in the announcement:

“With Alcide Kubernetes Advisor, Eupraxia Labs has been able to significantly reduce security drifts in our entire CI/CD pipeline — from development and staging, all the way to production.”

David J. Brewer, Founder, Eupraxia Labs

Gadi Naor, CTO and co-founder of Alcide, noted the broader challenge:

“The increasing complexity of multi-cluster Kubernetes environments and the persistent lack of connectivity with DevOps workflows is complicating efforts by DevOps teams to keep pace with vulnerabilities and best practices. Alcide Advisor automates and integrates cluster hygiene into the CD process natively, to arm DevOps teams to immediately identify potential vulnerabilities, configuration drifts and threats, without sacrificing agility.”

Gadi Naor, CTO and Co-founder, Alcide

Practical Takeaways for DevOps Teams

Whether or not you use a dedicated scanning tool, the gaps identified in this analysis point to a concrete checklist for improving Kubernetes security hygiene:

1. Audit for plaintext secrets. Scan your pod specs, ConfigMaps, and Helm values files for hardcoded credentials. Migrate to Kubernetes Secrets objects, then consider an external secrets management solution.
2. Enable etcd encryption at rest to protect Secret data stored in the cluster datastore.
3. Review and restrict hostPath mounts. Any mount of sensitive host paths should have a documented justification and be gated by Pod Security Admission or an equivalent admission controller.
4. Define NetworkPolicies. Start with a default-deny baseline policy and explicitly allow only the traffic your application requires. Use a CNI plugin that enforces NetworkPolicy (e.g., Calico, Cilium, Weave Net).
5. Integrate security scanning into your CI/CD pipeline. Static analysis of Kubernetes manifests can catch many of these issues before deployment. Tools in this space include open-source options such as Trivy, kube-bench, kube-score, and Checkov, as well as commercial products.
6. Apply RBAC rigorously. Limit which identities can read Secrets, access the API server, or modify workload specs.

Context and Caveats

This analysis dates from mid-2019 — an early period in the mainstream adoption of Kubernetes in enterprise environments. The Kubernetes ecosystem and the security tooling around it have matured considerably since then. However, the underlying security hygiene gaps identified — plaintext secrets, over-permissive host mounts, and absent network policies — remain common findings in Kubernetes audits years later, making the core lessons of this report still relevant for teams at any stage of their Kubernetes journey.

Note: Alcide was subsequently acquired by Rapid7 in 2021. Alcide Advisor may no longer be available as a standalone product.

The answer is not simply to hire more people — it is to make the people you have dramatically more effective. Organizations that embed security thinking across their engineering and operations teams multiply the impact of every security hire. Below are five concrete tips that help you do exactly that.

1. Get Your DevOps Team On Board With SecOps

If your development and operations teams are already working in a DevOps model, the next logical step is to extend that collaboration to security — commonly called DevSecOps or SecOps. Train the people who write and deploy code to treat security as part of their everyday responsibility, not as someone else’s problem to clean up later.

This cultural shift must be driven from leadership. When security metrics appear on the same dashboards as deployment frequency and uptime, engineers begin to internalize security as a first-class concern. Reinforce that expectation in code-review checklists, sprint retrospectives, and performance evaluations.

2. Bring Security Alerts Into DevOps Workflows

Asking developers to log into a dedicated security console they rarely visit almost guarantees that alerts will be ignored or actioned too slowly. Instead, deliver security signals where engineers already spend their time.

ChatOps platforms such as Slack, Microsoft Teams, or Mattermost are an effective bridge. Routing security alerts into a dedicated channel — or even into team-specific channels — means engineers see relevant alerts in context, can discuss them immediately, and can escalate or dismiss without context-switching to an unfamiliar tool.

The lower the friction, the more consistently your team will respond to alerts in a timely and repeatable way. Enrich alerts with contextual metadata — the host, the process, the user account involved — so the people reviewing them can triage quickly without needing deep security expertise.

3. Extend Security Visibility Across the Whole Organization

Do not stop at the engineering team. When security awareness tools and channels are accessible to everyone — product managers, support staff, finance — you gain a much larger set of eyes watching for anomalies.

Practical ideas include:

• A company-wide #security Slack channel where anyone can flag suspicious emails, unusual login prompts, or strange behavior.
• Automated alerts that ping the individual user whose action triggered a security event, asking them to confirm or deny — this dramatically speeds up triage.
• Regular, short security digests that keep the broader team informed about active threat patterns without overwhelming them.

Building this culture of openness and shared responsibility makes your organization a harder target and reduces the burden on your dedicated security staff to investigate every false positive alone.

4. Educate and Train the Entire Team

Workflow integration only goes so far if people do not understand what they are looking at. Basic security training for every employee — not just engineers — is a high-leverage investment. Key topics to cover include:

• Phishing and social engineering: How to recognize suspicious emails, links, and requests, and what to do when you spot them.
• Authentication hygiene: How to use multi-factor authentication (MFA), password managers, and single sign-on (SSO) tools correctly.
• Network safety: Which networks are safe to use, when to use a VPN, and how to stay secure while traveling for work.
• Physical security basics: Locking screens when stepping away, never plugging in unfamiliar USB devices, and following a clean-desk policy.

The goal is to raise the organization’s collective security IQ to a level that makes you an unappealing target. A well-trained team generates fewer incidents, which directly reduces the workload on your security staff.

5. Choose Comprehensive, Integrated Security Tools

Tool sprawl is a silent productivity killer for security teams. When alerts come from a dozen disconnected systems, analysts spend more time correlating data than actually responding to threats. Aim for a single-pane-of-glass approach: one platform — or a tightly integrated set of platforms — that gives your security team a unified view of your network, infrastructure, and application layer.

When evaluating security platforms, look for native integrations with the tools your teams already rely on, such as:

• Incident management tools (e.g., PagerDuty, VictorOps / Splunk On-Call)
• Chat and collaboration platforms (e.g., Slack, Microsoft Teams)
• Cloud provider consoles and APIs (e.g., AWS Security Hub, Azure Defender, GCP Security Command Center)
• CI/CD pipelines, so that security scanning happens automatically at build time

A unified toolset enables proactive vulnerability management: your team can identify and remediate weaknesses before they are exploited, rather than scrambling to contain a breach after the fact. Over time, it also builds an institutional knowledge base about your security posture and how your systems and users behave under normal conditions — making anomalies far easier to spot.

Putting It All Together

Security talent will continue to be expensive and difficult to hire for the foreseeable future. Rather than waiting for the market to change, forward-thinking organizations are restructuring how security work gets done — distributing ownership across development, operations, and the entire business, and equipping everyone with the tools and knowledge they need to contribute.

By embedding security into existing DevOps workflows, training your full team, and consolidating your tooling, you give your dedicated security professionals the leverage they need to operate strategically rather than reactively. The result is a more resilient organization and a security team that can actually scale with the business.

Originally sourced from business2community.com.

Security teams and DevOps engineers frequently operate with different priorities, vocabularies, and success metrics. DevOps teams measure themselves on deployment frequency, lead time, and mean time to recovery. Security teams measure themselves on risk reduction, compliance posture, and incident avoidance. Without deliberate effort to align these frameworks, communication breaks down — and the consequences are real: delayed releases, security controls bolted on at the last minute, or worse, vulnerabilities shipped to production.

The Root Causes of Miscommunication

Several structural and cultural factors contribute to the disconnect between security and DevOps:

• Different risk languages: Security professionals speak in terms of threat models, CVEs, and compliance frameworks. DevOps engineers speak in terms of pipelines, containers, and uptime. Neither group is wrong — they simply lack a shared vocabulary.
• Late-stage security reviews: When security is only engaged at the end of a release cycle, it becomes a bottleneck rather than an enabler. Engineers experience security as an obstacle, and security teams feel ignored during design.
• Siloed tooling: Security tools that don’t integrate into CI/CD pipelines require manual handoffs, creating friction and incentivizing teams to work around security checks.
• Asymmetric accountability: In many organisations, DevOps teams own the delivery outcome while security teams own the risk outcome. This split accountability makes it easy for each group to blame the other when something goes wrong.
• Perceived culture clash: DevOps culture prizes speed and experimentation. Traditional security culture prizes control and caution. Without deliberate bridging, these values feel mutually exclusive.

Security as a Trusted Advisor, Not a Gatekeeper

When a security team can assess brand, financial, and strategic risks, they are best able to act as a trusted advisor to the DevOps team as they build and maintain secure systems.

SecurityWeek

This framing is important. A security team that understands business risk — not just technical vulnerability — can communicate in terms that resonate with engineering leadership and product owners. Instead of flagging a misconfigured S3 bucket as a CVSS score, they can articulate the potential brand damage, regulatory fine, or customer data exposure that misconfiguration represents. That context changes the conversation from adversarial to collaborative.

Trusted advisors are consulted early and often. Gatekeepers are avoided until unavoidable. Security teams that want a seat at the DevOps table need to demonstrate that engaging with them early makes delivery faster and safer — not slower.

Practical Steps to Improve Security-DevOps Communication

1. Embed Security Early in the SDLC

Shift security left by involving security engineers during architecture and design reviews, not just pre-production audits. Threat modelling sessions held at the start of a sprint or feature cycle catch design-level risks before they are expensive to fix.

2. Adopt a Shared Risk Register

Maintain a risk register that is visible and meaningful to both security and DevOps teams. Prioritise risks using business impact, not just technical severity. This gives DevOps engineers the context to make informed trade-off decisions without waiting for a security sign-off on every ticket.

3. Integrate Security Tooling into the Pipeline

Static analysis (SAST), dependency scanning (SCA), container image scanning, and secrets detection should all run automatically within the CI/CD pipeline. When security feedback arrives in the same interface engineers already use — pull requests, build dashboards — it becomes part of normal workflow rather than a separate process to manage.

4. Define Clear Escalation Paths

Engineers should know exactly what to do when a security scanner flags a critical finding at 2 AM during a deploy. Pre-agreed escalation paths, documented acceptance criteria, and defined waiver processes remove ambiguity and prevent both over-reaction (blocking all deployments) and under-reaction (silently ignoring findings).

5. Run Joint Post-Mortems

When a security incident or near-miss occurs, conduct a blameless post-mortem that includes both security and DevOps stakeholders. Shared analysis of what went wrong builds mutual understanding and surfaces systemic communication failures that individual teams cannot see on their own.

6. Establish a Security Champions Programme

Designate security champions — engineers within DevOps teams who receive additional security training and serve as the first point of contact for security questions. This distributes security knowledge without requiring a security engineer to be embedded in every team, and it builds empathy between the two disciplines.

The DevSecOps Model as a Structural Solution

The DevSecOps movement exists precisely because the communication failure between security and DevOps is a well-recognised, recurring problem. DevSecOps treats security as a shared responsibility distributed across the entire software delivery lifecycle — not as a separate phase owned by a separate team. Organisations that successfully adopt DevSecOps typically report fewer last-minute security blockers, faster time to remediation, and improved trust between engineering and security functions.

Achieving this requires more than tooling. It requires executive sponsorship, changes to team incentive structures, and sustained investment in cross-functional training. But the alternative — continued miscommunication, late-stage security failures, and adversarial team dynamics — carries its own significant cost.

Key Takeaways

• Security and DevOps teams miscommunicate because they measure success differently and use different risk languages.
• Security teams that understand business risk — brand, financial, strategic — can act as trusted advisors rather than gatekeepers.
• Shifting security left, integrating tooling into pipelines, and establishing shared risk registers are concrete steps to improve collaboration.
• DevSecOps is the structural answer to the communication problem, but it requires cultural change, not just tooling.
• Security champions and joint post-mortems build the mutual understanding that processes alone cannot create.

Originally referenced from: The Danger of Miscommunication Between Security and DevOps — SecurityWeek.