La sécurité continue au sein du DevSecOps

Qu’est-ce que la surveillance continue de la sécurité ?

La surveillance continue de la sécurité est l’évolution naturelle de la sécurité. Le développement logiciel moderne évolue vers un modèle où tout est continu, de l’intégration à la livraison et au déploiement. Les approches de sécurité traditionnelles se concentrent sur les tests des versions logicielles après leur mise en production. Mais cette approche crée des goulots d’étranglement dans le développement et risque de laisser passer des vulnérabilités en production. La sécurité continue intègre plutôt la sécurité au processus de développement, ce qui réduit les risques et élimine les goulots d’étranglement pour accélérer les mises en production.

Quels sont les avantages de la sécurité continue ?

Le développement logiciel moderne se caractérise par une architecture et des couches d’infrastructure complexes. Des approches comme les applications cloud natives, les microservices et la conteneurisation permettent aux développeurs de tester et de livrer du code plus rapidement. Les versions sont généralement petites et fréquentes. Dans certains environnements, les déploiements en production ont lieu plusieurs fois par jour.

La sécurité DevOps nécessite une nouvelle approche pour faire face à l’accélération rapide du rythme des changements logiciels. Les méthodes de sécurité traditionnelles testaient les logiciels à la fin du cycle de développement ou après leur mise en production. Les tests étaient souvent confiés à des équipes externes, ce qui créait des frictions entre les développeurs et les professionnels de la sécurité.

En outre, les approches de sécurité traditionnelles ne sont pas adaptées aux architectures et aux infrastructures logicielles modernes. Une infrastructure cloud peut être déployée en quelques minutes. Son architecture n’est pas clairement définie. Si cela séduit les développeurs modernes, l’exposition aux attaques s’en trouve élargie et la sécurisation devient plus difficile. Les approches de sécurité traditionnelles ne sont pas suffisamment adaptées pour tester ces environnements.

La sécurité continue prolonge naturellement les pratiques DevOps en intégrant la sécurité au pipeline CI/CD. Elle est étroitement liée au concept DevSecOps et à l’approche de sécurité « shift left ». Les équipes de développement prennent en charge la sécurité du code et en sont responsables, afin que les problèmes soient détectés et corrigés le plus tôt possible dans le processus de développement. Au final, la sécurité continue accélère la livraison des fonctionnalités tout en automatisant les exigences de sécurité, pour une meilleure gouvernance et une sécurité renforcée.

Comment la sécurité continue s’intègre-t-elle aux pipelines CI/CD ?

La sécurité continue applique des politiques et des tests directement dans le pipeline CI/CD, afin de sécuriser l’infrastructure et les applications à chaque étape du cycle de vie du développement logiciel :

Modélisation des menaces

La modélisation des menaces devrait idéalement avoir lieu dès les premières étapes du SDLC. Les développeurs modélisent les changements qui découleraient de l’exécution du code, sans toutefois l’exécuter. Ils obtiennent ainsi des commentaires quasi instantanés et peuvent évaluer les implications du code en matière de sécurité.

La modélisation des menaces peut rapidement se complexifier. L’approche STRIDE, par exemple, prévoit une analyse distincte pour chacun des types d’attaque les plus courants :

• Spoufing (usurpation d’identité)

• Tampering (altération)

• Repudiation (répudiation)

• Information disclosure (divulgation d’informations)

• Denial of service (déni de service)

• Elevation of privilege (élévation de privilèges)

Les méthodologies comme STRIDE aident à évaluer ce que vous développez, les problèmes susceptibles de survenir, les moyens de les atténuer et la manière d’évaluer votre processus de réduction des menaces.

La modélisation des menaces nécessite également une planification pour s’intégrer efficacement à la culture DevSecOps. Traditionnellement, elle reposait sur de nombreuses réunions préliminaires entre les développeurs et les experts en sécurité. La sécurité continue applique une approche shift left à la modélisation des menaces, en la faisant intervenir plus tôt dans le processus de développement, et adopte aussi une approche « extend right » avec des outils de modélisation tiers pour détecter et atténuer automatiquement les menaces aux étapes ultérieures du pipeline.

Revue du code et de la conception

Une fois le code écrit, il est temps de le vérifier pour s’assurer qu’il remplit sa fonction et repérer les vulnérabilités ou les problèmes de sécurité. Ce processus doit notamment consister à assainir et valider toutes les entrées à l’aide d’une bibliothèque approuvée, à appliquer une authentification sécurisée et à rechercher les vulnérabilités dans les dépendances logicielles, ainsi qu’à effectuer de nombreux autres contrôles de sécurité.

Pour découvrir d’autres bonnes pratiques, consultez notre antisèche sur la revue de code.

Tests

Une fois le code validé du point de vue de la sécurité et de la conception, il est temps de le tester. À cette étape, les développeurs créent un environnement sandbox prêt à être mis en production, puis testent le code dans ces conditions. Cela comprend des tests automatisés des appels réseau, de la validation des entrées, de l’autorisation, des journaux et du contrôle d’accès. L’application consigne-t-elle correctement les métriques de sécurité ? L’accès est-il limité aux bonnes personnes ?

Les tests de sécurité continus permettent ainsi d’obtenir rapidement des commentaires. Ils peuvent également inclure le provisionnement et le test des ressources d’infrastructure. Par exemple, dans un environnement de test déployé sur AWS, un outil appelé Managed Config Rules peut vérifier que les ressources cloud respectent les bonnes pratiques de configuration de sécurité.

Production

La production marque la fin du parcours du code, mais pas celle de la sécurité. Les ressources peuvent être modifiées, ajoutées ou supprimées. Les applications en production doivent donc faire l’objet de tests continus pour vérifier leur conformité aux normes de l’organisation, du secteur ou du gouvernement. La sécurité en production peut inclure l’application automatisée de correctifs, la gestion de la configuration et la mise à jour automatique des dépendances.

Examinons quelques bonnes pratiques à suivre pour mettre en place un programme de sécurité continue efficace.

Quelles bonnes pratiques suivre pour un processus de sécurité continue ?

La sécurité continue nécessite une planification

Il ne suffit pas de transmettre des objectifs de sécurité à l’équipe DevOps et de s’attendre à ce qu’elle applique et fasse respecter les procédures. La charge des intégrations ne doit pas incomber aux seules équipes de développement. Les équipes de sécurité doivent s’attacher à mettre en œuvre la sécurité continue en perturbant le moins possible les activités, dès l’étape de planification. Les équipes de sécurité et DevOps doivent collaborer dès le départ pour intégrer les fonctionnalités et les audits, puis travailler ensemble tout au long du processus.

La planification commence par la modélisation des menaces, dès la conceptualisation initiale d’un système, d’une application ou d’un récit utilisateur. Les tests de sécurité des applications doivent être exécutés automatiquement à chaque modification du code et après l’intégration. Tout problème potentiel doit être signalé pour examen, et les résultats transmis aux développeurs dans les outils qu’ils utilisent au quotidien.

Le processus doit être automatisé autant que possible. Le déploiement, par exemple, doit dépendre des métriques de sécurité et de la sécurité à l’exécution.

L’infrastructure nécessite une attention particulière

La flexibilité de l’infrastructure cloud implique la mise en place et l’application de politiques. Il peut s’agir de désactiver les services inutiles, de fermer les ports superflus, d’appliquer les autorisations et de veiller à ce qu’aucun outil de développement ne soit installé en production.

Le code doit être développé sur des systèmes d’exploitation sécurisés et avec des versions à jour des applications. Il faut également appliquer les contrôles de sécurité liés à la taille des clusters, aux autorisations sur l’infrastructure partagée et aux partenaires d’infrastructure ou de plateforme.

Effectuer régulièrement des tests (tests d’intrusion, bug bounty)

Les tests sont essentiels. Ils permettent de vérifier que le code est à la fois fonctionnel et sécurisé avant sa mise en production. Ils peuvent aussi être automatisés pour éviter les retards liés aux vérifications manuelles. Les tests peuvent révéler des vecteurs d’attaque, détecter des vulnérabilités potentielles et les classer en fonction de leur portée possible.

Ce niveau de test doit également s’appliquer à l’infrastructure, aux réseaux et à tout autre élément représenté sous forme de code. L’objectif est d’analyser tous les composants d’une application afin de garantir une sécurité adéquate sur l’ensemble de la pile technologique.

Utiliser des outils qui renforcent la sécurité sans perturber les développeurs

Les outils modernes permettent aux développeurs d’améliorer plus facilement la sécurité directement dans le pipeline CI/CD. Les outils de test statique de sécurité des applications (SAST) peuvent être utilisés pendant le développement logiciel pour détecter les problèmes et les vulnérabilités dans le code mis à jour. Par exemple, ils peuvent repérer si une entrée utilisateur risque de déclencher une fonction liée à une base de données et d’introduire une vulnérabilité de sécurité (une injection SQL).

Traditionnellement, les outils SAST étaient utilisés dans un processus CI distinct. Les outils SAST modernes peuvent toutefois analyser le code source en cours de développement et fournir rapidement aux développeurs des commentaires exploitables. Ils génèrent peu de faux positifs et donnent également des indications sur la correction à apporter. Pensés pour les développeurs, ils s’intègrent à l’IDE, à la CLI et aux autres outils qu’ils utilisent déjà.

Les outils d’analyse de la composition logicielle (SCA) sont une autre technologie précieuse pour la sécurité continue. Ils permettent aux développeurs de vérifier si les modifications du code source présentent des vulnérabilités liées aux dépendances avant leur fusion.

Les moteurs de politiques et les outils de type lint sont deux autres catégories d’outils qui peuvent s’exécuter à chaque livraison de code par un développeur. Les outils de gestion des secrets comme Vault contribuent aussi à sécuriser le code dans l’infrastructure cloud et les applications.

Les outils Snyk pour la sécurité continue

De nombreux outils permettent de détecter et de corriger les vulnérabilités tout au long du cycle de vie du développement. Snyk se distingue par sa priorité accordée aux développeurs et par sa plateforme de sécurité de premier plan.

Maintenir les dépendances à jour constitue un obstacle pour les développeurs. Comment savoir quand une mise à jour est nécessaire ? Les changements seront-ils utiles ? Risquent-ils d’introduire des bugs ou de compromettre la compilation ? Les mises à jour continues des dépendances, plus fréquentes et plus modestes, facilitent la gestion du problème. Les développeurs peuvent utiliser des outils pour approuver et fusionner automatiquement les mises à jour, à condition que les tests réussissent. Cela accélère au final les déploiements et automatise entièrement le processus, de la pull request à la production.

Les dépendances open source constituent un sujet de préoccupation particulier. Snyk Open Source teste automatiquement le code tout au long du pipeline CI/CD pour détecter et corriger les vulnérabilités avant leur passage en production. Une fois le code en production, Snyk surveille l’apparition de nouvelles vulnérabilités grâce à sa base de données propriétaire.

En résumé, l’analyse du code est indispensable à la sécurité continue. Sans analyse, quelles vulnérabilités ou quels bugs pourraient passer inaperçus ?