Cloud-native security is complicated to define because the landscape never stops changing. The things we cared about most five years ago we can care about least today, and the things we had not thought about are now our most vulnerable surfaces. Steve Giguere, Developer Advocate at Palo Alto Networks specializing in cloud-native application security, has spent years establishing DevSecOps best practices for enterprises moving to cloud. Previously a cloud security architect for containers and Kubernetes, he shares why personal development is critical, when Kubernetes is not the answer, and how to secure the software supply chain.
You can read the complete transcript of the episode here >
What does cloud-native security actually mean?
Cloud-native security is easiest to define by what it is not. The CNCF glossary notably did not include “cloud-native security” when it first launched because the definition was too open to criticism.
At its core, cloud-native security encompasses:
- Understanding the vast connectivity of resources, code, applications, and orchestrators within cloud environments
- Identifying the attack surfaces and vectors associated with that connectivity
- Proactively remediating risks before they become exploitable vulnerabilities
- Maintaining enough observability to be reactive when necessary and feeding that back into proactive approaches
The complexity multiplies when organizations lift and shift or migrate monoliths to microservices. Teams familiar with traditional server models suddenly face entirely new attack surfaces they do not understand. This creates a change management problem layered on top of a security problem.
The mindset shift required: organizations need to keep people in mind. If developers are not spending at least 20% of their time on personal development, staying current with how the landscape is changing, they will be doing the wrong thing within a month. Security in cloud-native environments requires continuous learning because the technology stack changes faster than annual training can address.
How has security evolved from traditional to cloud-native?
Steve traces the evolution through several phases:
- 2014-2015: Focus on static source code analysis. Open source was less prominent. Most people built their own components. Security meant “secure your code.”
- DevOps era: Fast builds exposed the slowness of traditional SAST tools. Security got a bad reputation as a blocker. Teams adopted new languages (Go, Rust) that static analysis tools did not understand.
- Cloud transformation: Infrastructure as code emerged. CSPM became necessary to check cloud configurations. Then it shifted left to scan IaC before deployment.
- Container and Kubernetes era: New orchestration layers created attack surfaces that nobody understood. Port exposure, privilege escalation paths, and metadata service access became real threats. Kubernetes security emerged as its own discipline.
- Supply chain era: The systems that build the software are now under attack. Dependencies on dependencies create risk seven levels deep.
The result: everything has flipped. The code-level vulnerabilities that consumed most security attention five years ago are now less critical than infrastructure misconfigurations, identity abuse, and supply chain attacks that were barely on anyone’s radar.
How should Kubernetes misconfigurations be avoided?
Steve recommends a defense-in-depth approach with automation at every layer:
- IDE-level checking: Plugins for VS Code or JetBrains that flag manifest issues as developers write them. Catch problems before code is committed.
- Pre-commit hooks: Tools that prevent checking in obviously insecure configurations to Git repositories.
- CI pipeline gates: Break the build when manifests reference vulnerable images or violate security policies. Combine manifest checking with SCA scans of referenced images.
- Admission controllers: The “bouncer at the door” of Kubernetes. A last line of defense that checks workloads before they are scheduled, looking for the really bad stuff.
The key insight about managed Kubernetes: cloud providers have improved defaults significantly. The gaping holes from 2018 are largely gone unless you actively turn off security features. But “trust but verify” remains essential. Cloud providers lean toward ease of use over security, so defaults will never be perfectly secure. The shared responsibility model means you cannot assume the provider handles everything.
What role does automation play in DevSecOps for Kubernetes?
Automation is not optional. You cannot have a secure platform without automating your security:
- Policy as code (Open Policy Agent): Codify security rules and apply them from IDE to production. Break pipelines when high business risk is detected.
- Context-aware decisions: Combine manifest checks with image vulnerability data, deployment context (production vs development), and network exposure to make intelligent allow/block decisions.
- Infrastructure tagging: Tools that automatically tag resources with commit information, team ownership, and cost attribution from the CI/CD platform. This creates code-to-cloud traceability.
The practical example: an Nginx image reference with known vulnerabilities deploying to an internal development server with no internet access is a different risk than the same image deploying to a production endpoint. Context-aware automation lets the first one pass and blocks the second.
Is Kubernetes the right solution for every organization?
Steve is direct: Kubernetes is not for everyone, especially early-stage startups.
When Kubernetes makes sense:
- Medium to large organizations with dynamic, scalable workloads
- Teams with platform engineering expertise to maintain it
- Applications that genuinely benefit from container orchestration
When it does not:
- Early-stage startups where pure serverless is simpler, cheaper, and more secure by default
- Workloads that are better served by a well-designed monolith (Amazon Prime Video saved 90% in cloud costs by moving back from microservices to monolith)
- Teams without the expertise to configure and maintain Kubernetes securely
Kubernetes is an attack surface in itself. It is complex and easy to get wrong. The decision should be based on growth stage, team expertise, scalability requirements, and architectural fit, not on hype or the assumption that cloud-native means Kubernetes.
How should organizations address supply chain security?
With 85-97% of enterprise codebases using open source and 62% vulnerable to supply chain attacks, this is a critical concern:
- Software composition analysis (SCA): Start in the IDE. Detect outdated or vulnerable dependencies as developers reference them. Block check-ins until minimum standards are met.
- Transitive dependency awareness: Vulnerabilities exist seven levels deep. After Log4Shell, most teams fixed their direct dependency but still had four different vulnerable versions buried in their dependency tree.
- SBOM generation and sharing: Create software bills of materials and pass them downstream so consumers know what is included. Tools like Syft make this achievable.
- Code signing and provenance (SLSA framework): The 1.0 release of SLSA provides achievable levels of supply chain security that the industry should adopt.
- Operational risk assessment: Before adopting open source, evaluate contributor activity, commit frequency, response time to security reports, and community health. Low activity is a future security risk.
The cultural imperative: if you love an open source project, contribute back upstream. Get developers to push fixes and features. When you find a vulnerability, be part of the solution rather than waiting for someone else to fix it. The Colors.js incident, where a maintainer sabotaged his own widely-used project because nobody contributed back, illustrates what happens when consumption is one-directional.
What open source tools are worth using for cloud-native security?
Steve recommends several tools for teams starting their cloud-native security journey:
- Checkov: IaC scanning for Terraform, CloudFormation, serverless templates, Kubernetes manifests (including Helm and Kustomize). Free and extensible.
- Trivy: Container image scanning. Fast, comprehensive, and the de facto standard for vulnerability detection in container images.
- Syft: SBOM generation for understanding what is inside your container images and dependencies.
- Yor: Automatic tagging of IaC resources with Git commit information for cost observability and code-to-cloud traceability.
The principle for evaluating any tool: does it solve the core problems of security, reliability, cost effectiveness, and visibility? If a tool does not address these fundamentals, it is introducing new problems rather than solving existing ones.
