Maj Gauche échoué : la sécurité doit descendre dans la pile pour atteindre la vitesse sans sacrifier le contrôle

Pendant des années, nous avons répété un mantra : vous devez « déplacer la sécurité à gauche » et demander aux développeurs d'assumer plus de responsabilités de sécurité tout en écrivant et en testant le code. L'idée était séduisante : résoudre les problèmes tôt est moins cher, et si les équipes de développement intègrent des contrôles dès le début tout sera plus rapide et plus sûr. Toutefois, la réalité montre que ce pari «de gauche» n'a pas résolu le problème central. Dans de nombreux environnements, la tension entre vitesse et sécurité s'est intensifiée et, surtout, les développeurs ont fini par supporter un fardeau cognitif insoutenable.

Le problème n'est pas la paresse des développeurs; c'est le modèle incitatif et la pression pour livrer rapidement. Lorsque l'entreprise a besoin de fonctionnalités, de résultats à court terme et mesurables, c'est la livraison qui est une prime. Si un contrôle de sécurité prend des heures et bloque la construction, la pression pour la dessiner apparaît naturellement. Dans ce stock reproducteur, des solutions pragmatiques telles que tirer des images publiques des registres facilitent les progrès, mais introduisent aussi des risques difficiles à contrôler.

Un bon exemple de ce qui peut échouer vient de la propre analyse de l'industrie. L'équipe de recherche de Qualys a examiné des dizaines de milliers d'images de conteneurs publics et a trouvé des résultats alarmants: d'un très large échantillon, des milliers d'images ont présenté des comportements malveillants ou des contenus sensibles incorporés. Parmi ces découvertes se trouvaient la cryptominerie intégrée dans une grande partie des échantillons malveillants et secrets (clés AWS, jetons GitHub, références de base de données) conservés dans les couches d'image. Vous pouvez lire le rapport et les détails techniques sur le blog Qualys sur cette étude Voilà..

L'erreur conceptuelle est de traiter les dépôts publics comme des bibliothèques curées et fiables par défaut. Des plateformes telles que Docker Hub, les disques de fournisseurs de cloud et d'autres services publics facilitent la distribution, mais la simple présence d'une image dans ces espaces ne garantit pas qu'elle est sûre. Télécharger une image ouverte est, en substance, une décision de confiance; et cette confiance peut être déplacée.

Alors que faites-vous ? La réponse est de déplacer la sécurité dans une autre direction : pas plus "de gauche" seulement sur l'épaule du développeur, mais une stratégie qui réduit les responsabilités et les contrôles à la couche infrastructure et plate-forme. Au lieu de demander à chaque ingénieur de se souvenir du balayage, du durcissement et de l'audition manuellement, nous devons offrir des moyens sûrs qui sont simples et rapides à suivre.

Un élément clé est la création d'un dépôt interne qui agit comme une quarantaine d'objets externes. Toutes les images externes devraient passer par un mandataire ou un registre interne qui inspecte, signe et approuve les artefacts avant d'entrer dans les pipelines. Les outils de gestion de périphériques comme Harbor peuvent aider à construire ce type de couche intermédiaire et automatiser les politiques d'acceptation; voir plus dans le projet Port.

Dans la pratique, il vaut aussi la peine de définir un "chemin d'or" pour les développeurs: modèles standard, images de base approuvées et pipelines officiels qui garantissent la sécurité par défaut. Si les équipes suivent cette voie, la sécurité devient pour elles quelque chose de transparent. Si quelqu'un a besoin de sortir du modèle, alors il nécessite des examens supplémentaires et des processus manuels qui justifient ce risque pour l'entreprise.

Les outils de politique et de contrôle de l'infrastructure font partie de la solution. Les politiques déclaratives appliquées avec les modules Terraform, les compositions Crossplane ou les règles de l'Open Policy Agent préviennent les erreurs humaines répétitives : par exemple, évitez les seaus S3 non-versionnés ou refusez d'afficher avec des images qui ne répondent pas aux exigences minimales. Open Policy Agent offre un cadre pour l'encodage de ces types de restrictions et peut être intégré dans les pipelines et les contrôleurs d'admission; consultation Agent politique ouvert pour plus d'informations.

De même, l'automatisation doit couvrir à la fois la détection et la réponse. Les scanners de conteneurs doivent être exécutés dans le CI / CD et les contrôleurs d'admission de Kubernetes devraient empêcher les conteneurs avec des vulnérabilités critiques d'atteindre le cluster. Dans le temps de fonctionnement, les outils ne devraient pas se limiter à générer des alertes; face à un comportement malveillant prouvé, le système devrait être capable d'isoler et de tuer des charges compromises, et même de marquer des nœuds pour un confinement automatique. La documentation officielle sur les contrôleurs d'admission à Kubernetes explique comment ces mécanismes fonctionnent: Contrôleurs d'admission Kubernetes.

Il est également intelligent d'adopter des approches qui automatisent la correction : si une vulnérabilité est détectée dans une image de base, la plate-forme peut générer une demande de tirage pour la mettre à jour automatiquement et, après validation, promouvoir la version sécurisée. Ce type d'écoulement réduit le temps d'exposition et réduit la charge sur l'équipement qui ne devrait pas passer son temps à des tâches d'entretien répétitives.

Cela ne signifie pas que la sécurité cessera de travailler avec le développement; au contraire, elle exige une relation plus étroite et plus proactive. La sécurité et la plate-forme doivent comprendre les exigences opérationnelles et travailler à faire de la livraison sûre l'option la plus rapide et la plus économique. Cela évite le conflit entre la réalisation des objectifs opérationnels et le respect des contrôles de sécurité, car les deux sont alignés dans la même infrastructure.

Le changement culturel est également pertinent : arrêtez de blâmer les développeurs pour les raccourcis et commencez à concevoir des systèmes qui empêchent les raccourcis. Des modèles tels que DevSecOps restent valables, mais leur mise en œuvre doit être orientée vers la simplification et l'automatisation efficace. Les ressources d'organismes tels que l'OWASP ou le NIST fournissent des guides et des cadres pour comprendre les risques dans la chaîne d'approvisionnement des logiciels et comment les atténuer. OWASP SAMM et NIST - Sécurité de la chaîne d'approvisionnement logicielle.

La conclusion est claire: si nous continuons à porter la responsabilité sur les épaules des développeurs déjà surchargés, nous obtiendrons des évasions et une exposition. Au lieu de cela, nous avons besoin de plateformes qui rendent l'option sûre aussi l'option facile. La sécurité doit « descendre » dans la pile, être intégrée à l'infrastructure et automatisée, de sorte que l'entreprise obtient vitesse sans sacrifier le contrôle ou la protection. Pour ceux qui veulent approfondir l'analyse et les recommandations spécifiques, l'étude Qualys est un bon point de départ et est disponible sur leur blog technique Voilà. et si des solutions pour les environnements cloud-natifs sont en cours d'évaluation, le rapport de Forrester sur CNAPP est une autre référence utile disponible via Qualys.