// Comparaison

Container Security vs Security Chaos Engineering : lequel lire ?

Deux livres de cybersécurité sur DevSecOps, comparés honnêtement : à qui s'adresse chacun, ce que chacun fait de mieux, et lequel lire en premier.

Intermédiaire
4/52020
Container Security

Fundamentals for Securing Containerized Applications

Liz Rice

L'introduction first-principles de Liz Rice à comment fonctionnent réellement les conteneurs Linux — namespaces, cgroups, capabilities, seccomp, layering d'images — et les implications de sécurité qui découlent de cette mécanique.

Avancé
5/52023
Security Chaos Engineering

Sustaining Resilience in Software and Systems

Kelly Shortridge, Aaron Rinehart

Kelly Shortridge et Aaron Rinehart traitent la sécurité comme une propriété de systèmes adaptatifs complexes : au lieu de prévenir la défaillance, on la simule en continu et on conçoit l'organisation pour apprendre de chaque résultat.

À lire si

Ingénieurs et gens de sécurité qui utilisent les conteneurs au quotidien mais les traitent comme des boîtes. Le livre est la rare introduction qui explique les conteneurs comme compositions de primitives Linux plutôt que comme produit Docker, et c'est exactement ce qui rend l'argument sécurité lisible.
Architectes sécurité, SRE et ingénieurs plateforme prêts à abandonner le cadre prévention-d'abord. Particulièrement fort pour les organisations qui pratiquent déjà le chaos engineering pour la fiabilité et veulent étendre la discipline à la sécurité ; le livre est le pont.

À éviter si

Lecteurs ayant besoin de couverture en profondeur Kubernetes, supply-chain (SLSA, in-toto, Sigstore) ou cloud-runtime spécifique (Fargate, Cloud Run, ECS) ; à coupler avec les livres Kubernetes et la documentation SLSA actuelle. Léger aussi sur les alternatives runtime Wasm, qui sont une fraction croissante du champ.
Praticiens en environnements fortement régulés où les fautes intentionnelles en production ne sont pas légales, ou organisations plus petites sans la maturité opérationnelle pour mener des game days en sécurité. Mauvais premier livre de sécurité aussi : il suppose que vous savez ce que sont threat models, blast radius et boucles de rétroaction.

Points clés

  • Un conteneur n'est pas une boîte ; c'est un processus avec des vues curatées de namespaces et de ressources, et la plupart des vulnérabilités conteneurs vivent dans l'écart entre ce modèle mental et le modèle boîte.
  • Le drop de capabilities, les filesystems racine en lecture seule et les profils seccomp ne sont pas optionnels — Rice fait l'argument de manière convaincante avec des exemples concrets.
  • L'hygiène supply-chain image est la moitié de l'histoire sécurité ; le livre précède SLSA mais le motive proprement.
  • Sécurité et fiabilité partagent le même problème d'ingénierie racine : maintenir des systèmes complexes dans des bornes tolérables quand la surface de défaillance est non bornée.
  • Decision trees et analyse effort-vs-impact sont des artefacts opérationnalisables, pas du contenu de blog ; le livre apprend à vraiment s'en servir.
  • L'expérimentation continue est plus honnête que les exercices sur table : la production dit ce qui est vrai, les runbooks disent ce que quelqu'un aurait souhaité.

Comment ils se comparent

Nous notons Security Chaos Engineering plus haut (5/5 contre 4/5 pour Container Security). Pour la plupart des lecteurs, Security Chaos Engineering est le choix principal et Container Security un complément utile.

Container Security vise le niveau intermédiaire. Security Chaos Engineering vise le niveau avancé. Lisez le plus accessible d'abord si la thématique ne vous est pas familière.

Container Security et Security Chaos Engineering couvrent tous les deux DevSecOps : les lire dans l'ordre renforce les mêmes notions sous des angles différents.

Continuer la lecture

Thématiques liées