This article is based on reporting originally published at containerjournal.com in April 2020.
Alcide Brings Kubernetes Security Scanning to the Command Line
Alcide, a Kubernetes-focused security vendor, moved to advance DevSecOps adoption among developers of containerized applications by releasing sKan, a command-line interface (CLI) tool designed to integrate container security scanning directly into existing developer workflows.
According to Alcide CTO Gadi Naor, sKan makes it easier for developers to scan source code and configuration files for vulnerabilities without substantially altering how they already work — a practical requirement if security tooling is to be adopted at scale inside engineering teams.
What sKan Scans
sKan is designed to cover a broad range of Kubernetes-related artifact types, including:
- Kubernetes deployment files — standard manifests defining how workloads are deployed
- Helm charts — the widely used Kubernetes package manager format
- Custom Resource Definitions (CRDs) — Kubernetes API extensions used by operators and platform tooling
- Raw YAML and JSON resource files — common formats for infrastructure-as-code in Kubernetes pipelines
This breadth of coverage means development teams can perform meaningful security checks at the points in their workflow where these artifacts are authored or modified — before they ever reach a cluster.
Built on Alcide Advisor and Open Policy Agent
sKan shares the same core security engine used by Alcide Advisor and integrates with Open Policy Agent (OPA), a widely adopted policy enforcement framework in the Kubernetes ecosystem. This means security policies authored for OPA can be reused across the runtime and CI/CD scanning contexts, reducing duplication of effort for security and platform teams.
Beyond vulnerability detection, sKan can identify potential compliance issues — important for organizations operating in regulated industries or under frameworks such as CIS Kubernetes Benchmarks, PCI-DSS, or SOC 2.
The Real Challenge: Shifting Security Left and Right Simultaneously
Naor’s commentary highlights a tension that many organizations face when pursuing DevSecOps: the biggest barrier is not developer resistance to owning security, but the absence of tools that feel like a natural extension of developer workflows. Asking developers to adopt security practices without providing appropriate tooling and training simply moves accountability without enabling action.
Naor describes this as a need for security to shift both left and right simultaneously:
- Shift left: Developers catch vulnerabilities earlier in the development lifecycle — in code and config, before deployment.
- Shift right: Security and platform teams retain the ability to define, enforce, and audit policies centrally at runtime.
Effective DevSecOps requires both movements to happen in parallel, not as competing priorities.
Training Developers on RBAC and Kubernetes Security Fundamentals
Recognizing that tooling alone is insufficient, Alcide also provided educational resources to help developers understand and correctly implement Role-Based Access Control (RBAC) in Kubernetes. RBAC misconfiguration is a common and consequential vulnerability in Kubernetes clusters, and developers who write manifests that set overly permissive roles can inadvertently create serious security exposures.
Without training alongside tooling, organizations risk creating a dynamic in which developers are held accountable for security outcomes they lack the knowledge or capability to influence.
The Organizational Dynamics of DevSecOps Adoption
At the time of writing (April 2020), the internal ownership of DevSecOps initiatives remained unclear across most organizations. Developers had gained significant influence over platform and tooling decisions, while security teams were still navigating how much control to delegate. Several structural tensions made this transition difficult:
- There is a persistent shortage of security professionals with the capacity to be embedded in every development team.
- Security teams have historically viewed developers as a source of vulnerabilities rather than partners in remediation.
- Developers, for their part, may not have had adequate training to understand the security implications of the infrastructure code they write.
These tensions have not disappeared — they remain relevant to any organization adopting Kubernetes security practices today.
Why Containers Make Security Remediation Easier
One genuine structural advantage containers provide is ease of remediation. Because containerized workloads are defined by immutable images and declarative manifests, replacing a vulnerable component is more straightforward than patching a long-running virtual machine or bare-metal server. If a vulnerability is caught at the pre-deployment scanning stage, it can be resolved before it ever reaches production — making it invisible to runtime security monitoring, incident response processes, and end users.
This makes the economics of shift-left security particularly compelling in Kubernetes environments: catching a RBAC misconfiguration or an exposed secret in a YAML file during a CI pipeline run is far cheaper than detecting and responding to an active exploitation in a production cluster.
Context and Current Status
This article covers Alcide’s product announcements and commentary from April 2020. Alcide was subsequently acquired by Rapid7 in January 2021. Readers researching current Kubernetes security tooling should verify whether sKan or Alcide Advisor functionality has been integrated into Rapid7’s portfolio, discontinued, or superseded by other tools in the ecosystem such as Trivy, Checkov, Kubescape, or kube-bench.