N’utilisez pas `:latest`

• Dans un Dockerfile, :latest casse l’exigence la plus importante du CD : des builds idempotents et reproductibles
  → Cela peut non seulement faire échouer le build, mais aussi provoquer des erreurs en production
• Indiquer latest dans un manifest de Pod Kubernetes est encore pire
  → Dans un Dockerfile, un rollback reste au moins possible, mais dans un manifest de déploiement, cela crée un risque de rupture de compatibilité à n’importe quel moment où de nouveaux Pods sont déployés
• Avec pip, package.json, Terraform, etc., spécifier « une version ou plus récente » ou ne pas préciser de version produit exactement le même effet que l’usage de latest
• Utilisez impérativement les mécanismes de type lockfile fournis par les frameworks
  • Committez les fichiers de lock dans le contrôle de source
  • Lors de l’ajout de nouvelles fonctionnalités, de bugfixes ou de correctifs de sécurité, exécutez par exemple terraform init -upgrade, puis committez le fichier de lock
  • Ne mettez pas à jour les fichiers de lock pendant la CI
  • Types de fichiers de lock
    • Terraform : .terraform.lock.hcl
    • Python : Pipfile avec Pipenv
    • Node/Yarn : yarn.lock
    • Go : go.sum et go.mod
• Si possible, n’effectuez pas de résolution de dépendances au runtime
  → Transformez les dépendances en artefacts déployables et versionnez-les
• Utilisez des services comme Twistlock / Grype pour effectuer des scans de vulnérabilités