YAML security addresses vulnerabilities in YAML parsing that can lead to code execution, denial of service, and data exposure through unsafe deserialization of YAML content.
YAML security risks stem from the language's powerful features that can be exploited when parsing untrusted input. Unsafe YAML deserialization can trigger arbitrary code execution through object instantiation tags, cause denial of service through recursive references (billion laughs equivalent), and enable data exposure through unexpected type coercion. These risks are particularly significant in cloud-native environments where YAML is the primary configuration format.
YAML parsers supporting full specification features can instantiate arbitrary objects through type tags. In Python's PyYAML, the !!python/object tag creates arbitrary class instances, potentially executing code during construction. Ruby's Psych parser similarly supports object creation. Attackers craft YAML documents containing malicious type tags that trigger code execution when parsed. Safe loading modes that restrict type instantiation prevent this vulnerability class.
Parse YAML safely by using safe loading functions that disable arbitrary type instantiation—PyYAML's yaml.safe_load() instead of yaml.load(), Ruby's YAML.safe_load, and Java SnakeYAML's SafeConstructor. Validate YAML input against expected schemas before processing. Limit document size and nesting depth to prevent denial-of-service through resource exhaustion. Never parse untrusted YAML with full type resolution capabilities enabled in any programming language.
Kubernetes relies heavily on YAML for resource definitions, Helm charts, and operator configurations. Malicious YAML manifests can create privileged containers, mount host filesystems, deploy crypto miners, establish reverse shells, or modify RBAC permissions. Admission controllers like OPA Gatekeeper and Kyverno validate YAML manifests against security policies before resource creation, preventing deployment of insecure or malicious configurations.
YAML bombing is a denial-of-service attack using recursive anchors and aliases that expand exponentially during parsing, similar to XML billion laughs attacks. A small YAML document containing nested references can consume gigabytes of memory when the parser resolves all aliases. Prevention requires parsers that limit alias expansion depth, maximum document size enforcement, and resource consumption monitoring during YAML processing of untrusted input.
CI/CD pipelines process YAML configuration files for build definitions, deployment manifests, and infrastructure-as-code templates. Compromised YAML configurations can inject malicious build steps, modify deployment targets, exfiltrate secrets, or deploy backdoored applications. Securing CI/CD YAML requires code review for configuration changes, branch protection rules, signed commits, and policy enforcement preventing dangerous directives in pipeline definitions.
YAML security tools include Kubesec and kube-score for Kubernetes YAML security analysis, Checkov and Terrascan for infrastructure-as-code YAML scanning, yamllint for syntax validation, OPA (Open Policy Agent) for policy enforcement on YAML configurations, Datree for Kubernetes misconfiguration prevention, and SAST tools that detect unsafe YAML parsing patterns in application source code across multiple programming languages.
Validate YAML configurations by defining strict JSON Schema specifications for expected structure and data types, implementing admission webhooks in Kubernetes for runtime validation, using policy-as-code tools like OPA for complex security rule enforcement, scanning for known dangerous patterns like privileged containers or host network access, integrating validation into CI/CD pipelines to catch issues before deployment, and maintaining approved configuration templates.