// Comparison

Container Security vs Security Chaos Engineering: Which Should You Read?

Two cybersecurity books on DevSecOps, compared honestly: who each is for, what each does best, and which to read first.

Intermediate

4/52020

Fundamentals for Securing Containerized Applications

Liz Rice

Liz Rice's first-principles introduction to how Linux containers actually work — namespaces, cgroups, capabilities, seccomp, image layering — and the security implications that fall out of those mechanics.

Advanced

5/52023

Security Chaos Engineering

Sustaining Resilience in Software and Systems

Kelly Shortridge, Aaron Rinehart

Kelly Shortridge and Aaron Rinehart on treating security as a property of complex adaptive systems: instead of preventing failure, you continuously simulate it, and design the organization to learn from each result.

Read this if

Engineers and security people who use containers daily but treat them as boxes. The book is the rare introduction that explains containers as compositions of Linux primitives rather than as a Docker-shaped product, and that is exactly what makes the security argument legible.

Security architects, SREs, and platform engineers ready to abandon the prevention-first frame. Particularly strong for organizations that already practice chaos engineering for reliability and want to extend the discipline to security; the book is the bridge.

Skip this if

Readers needing in-depth Kubernetes, supply-chain (SLSA, in-toto, Sigstore), or cloud-runtime-specific (Fargate, Cloud Run, ECS) coverage; pair with the Kubernetes books and current SLSA documentation. Also light on Wasm-runtime alternatives, which are an increasing fraction of the field.

Practitioners working in heavily regulated environments where intentional production faults are not legal, or smaller organizations without the operational maturity to run game days safely. Also a poor first security book: it assumes you know what threat models, blast radius, and feedback loops are.

Key takeaways

A container is not a box; it is a process with curated views of namespaces and resources, and most container vulnerabilities live in the gap between that mental model and the box mental model.
Capability dropping, read-only root filesystems, and seccomp profiles are not optional — Rice makes the case persuasively with concrete examples.
Image-supply-chain hygiene is half the security story; the book pre-dates SLSA but motivates it cleanly.

Security and reliability share the same root engineering problem: how to keep complex systems within tolerable bounds when the failure surface is unbounded.
Decision trees and effort-vs-impact analysis are operationalizable artifacts, not just blog material; the book teaches you to actually use them.
Continuous experimentation is more honest than tabletop exercises: production tells you what is true, runbooks tell you what someone wished were true.

How they compare

We rate Security Chaos Engineering higher (5/5 against 4/5 for Container Security). For most readers, that means Security Chaos Engineering is the primary pick and Container Security is a useful follow-up.

Container Security is pitched at intermediate level. Security Chaos Engineering is pitched at advanced level. Read the easier one first if you're not yet comfortable with the topic.

Container Security and Security Chaos Engineering both cover DevSecOps, so reading them in sequence reinforces the same material from different angles.

Keep reading

Container Security

→ Alternatives to Container Security → What to read after Container Security