Le DevSecOps, c’est notamment l’application des meilleures pratiques de sécurité tout au long de votre processus de livraison logicielle : du cycle de développement aux déploiements. On parle souvent de « shift-left security » pour décrire cette approche, car la majeure partie des actions de sécurité sont ajoutées au début du processus (sur le côté gauche de la boucle DevOps).
De nombreux outils sont disponibles pour améliorer la sécurité à chaque étape de vos pipelines. Le problème est que fréquemment, choisir de bons outils sans être un expert en sécurité peut être difficile.
Cet article va vous aider à démarrer avec une courte liste d’outils de sécurité. L’objectif n’est pas de fournir une liste exhaustive, mais d’indiquer des outils qui peuvent vous aider à couvrir un large éventail de nouvelles vulnérabilités.
Le DevSecOps et le « Shift-left security »
Vous souvenez-vous de notre belle boucle DevOps ?
Les étapes les plus à gauche de la boucle DevOps planification — développement — compilation — test nécessitent des contrôles de sécurité. Pourquoi prendre le risque de « releaser » et de déployer une application vulnérable en production lorsque vous pouvez ajouter une « security gate » dans votre pipeline pour empêcher les menaces connues ?
Plan: Standard de conformité et modèle de menaces
Lors de la phase de planification, il y a deux activités essentielles en matière de politiques de sécurité : définir les standards de conformité et un modèle des menaces. Cependant, celles-ci sont souvent oubliées et laissées de côté, car les équipes de développement ne sont pas familières avec ces activités souvent réservées aux experts en sécurité. Le modèle des menaces est essentiellement un diagramme qui examine la solution et identifie les points vulnérables, afin de définir les solutions techniques pour les atténuer.
Voici une courte liste d’outils pour créer vos modèles de menaces :
- OWASP Threat Dragon: une plateforme open source de modélisation des menaces.
- PlantUML: mon outil « diagramme as code » préféré.
Code: Static Application Security Testing (SAST)
Pour protéger votre application, il est important de vérifier si votre code respecte les bonnes pratiques de sécurité. Pour cela, il existe des outils d’analyse statique du code source, également appelés Static Application Security Testing (SAST). En règle générale, ces outils recherchent une liste de vulnérabilités, sans exécuter le programme. Ils examinent les dépendances ainsi que la logique de votre code, comme la validation des requêtes et la protection contre l’injection de code.
Il est préférable d’utiliser ces outils lors du processus de développement pour avoir des retours rapides avant même que votre pipeline CI/CD n’entre en jeu et échoue lors de l’analyse des vulnérabilités. Recherchez des outils avec un « plugin » pour votre IDE ou créez des « git hooks » pour valider le code avant de pousser.
Voici une liste d’outils que vous voudrez peut-être explorer :
- SonarQube & OWASP dependency-check: peut-être les outils les plus populaires du moment.
- Codecov: un concurrent de SonarQube très en vogue dans la communauté open source.
Build: Analyse d’images
Analyser votre code ne suffit pas, car le système d’exploitation qui l’exécute peut également être vulnérable. Pour les applications « modernes », nous avons tendance à utiliser des conteneurs. Par conséquent, il est important d’analyser votre conteneur à la recherche de vulnérabilités pendant la phase de construction. Vous devez par ailleurs « re-builder » et scannez vos conteneurs chaque semaine pour obtenir les derniers correctifs pour remédier aux failles sécurité.
Voici une liste d’outils pour scanner vos images de conteneur :
- QUAY: clair, simple et facile d’utilisation
- AquaSecurity: très complet et peut être utilisé comme opérateur dans Kubernetes.
- Snyk: un outil qui cache derrière la commande docker scan.
Test: Dynamic Application Security Testing (DAST)
Les outils DAST évaluent la sécurité de votre application durant son exécution, en testant le logiciel comme si un utilisateur interagissait. L’objectif est d’identifier les vulnérabilités courantes et sévères en analysant l’exécution du code. Il est important de coupler le DAST avec des tests automatisés et des tests de charge pour générer autant de données que possible afin de détecter les trous de sécurité avant d’envoyer votre logiciel en production.
Voici la liste des outils pour DAST:
- OWASP ZAP
- Contrast
- Aqua DTA
Comment fonctionne le renforcement de la
sécurité dans les processus?
Le plus grand changement de DevOps à DevSecOps c’est l’idée de renforcer la sécurité le plus tôt possible dans le processus. Par conséquent, les étapes du côté gauche de la boucle DevOps sont améliorées pour « attraper » autant de vulnérabilités que possible avant de déployer des applications, bien sûr plus sécurisée.
Vous vous demander peut-être, qu’en est-il de la partie droite de notre boucle DevOps? Eh bien, les meilleures pratiques de sécurité ont toujours été centrées sur le côté opérationnel. Il y a donc déjà beaucoup d’efforts qui sont faits de ce côté-là. Le DevSecOps n’amène rien de nouveau de ce côté-là.
Encore une fois, l’idée clé de DevSecOps est la sécurité vers la gauche (shift-left security) et la sensibilisation des développeurs aux pratiques de développement sécuritaires. Ne vous inquiétez pas, les Ops aussi ont beaucoup de pain sur la planche en matière de sécurisation de leurs plateformes IaaS, PaaS et SaaS.
Si vous souhaitez en savoir plus sur les services DevOps proposés par Gologic, n’hésitez pas à nous contacter. Notre entreprise propose également un bilan de santé DevOps pour votre compagnie afin de vous concentrer sur vos enjeux prioritaires.
Par Gologic en collaboration avec Alexandre Couëdelo.
