Comment contrôler en amont avec l'intégration continue ?

Le contrôle en amont est une approche qui déplace les tests vers le début du cycle du développement logiciel (d'où le « contrôle en amont »). D'autre part, si les tests de sécurité sont effectués lorsque le code est prêt pour la production, il peut être difficile de revenir en arrière et de résoudre les problèmes. Il est même parfois trop tard pour les résoudre rapidement. Cela peut entraîner des retards dans les transferts, des problèmes de sécurité et des cloisonnements entre la sécurité et le reste des équipes DevOps.

Alors que les entreprises tentent de passer à une structure DevSecOps, il est essentiel d'introduire les tests de sécurité plus tôt dans le cycle de développement. La façon de le faire est d'intégrer des tests de sécurité dans les pipelines de déploiement afin que le code soit continuellement testé par rapport aux autres validations dans le dépôt partagé, mais également au niveau de la sécurité.

L'intégration continue (CI) est un processus qui améliore la qualité du code via des pipelines de déploiement. La sécurité peut être intégrée à ces pipelines plus tôt dans le processus, ce qui aide les entreprises à contrôler en amont.

Intégrer la sécurité dans les pipelines d'intégration continue

Les tests statiques de sécurité des applications (SAST) sont un moyen d'automatiser la sécurité grâce à l'intégration continue. SAST analyse le code source et permet aux développeurs de résoudre les problèmes plus tôt dans le cycle du développement logiciel.

Dans GitLab CI/CD, le pipeline de déploiement vérifie le rapport SAST et compare les vulnérabilités entre les branches source et cible. Ces résultats apparaissent dans la merge request.

Les tests dynamiques de sécurité des applications (DAST) fonctionnent souvent en tandem avec SAST. Alors que SAST analyse le code source, DAST analyse les erreurs de runtime dans les applications exécutées. Une fois qu'une application est déployée, elle est exposée à de nouvelles formes de risques de sécurité, tels que le cross-site scripting ou les vulnérabilités « Broken Authentication ».

Comme avec SAST, GitLab vérifie le rapport DAST, compare les vulnérabilités entre les branches source et cible et affiche les résultats. Toutefois, la comparaison utilise uniquement le dernier pipeline exécuté pour la validation de base de la branche cible.

D'autres types de tests de sécurité comprennent les tests interactifs de sécurité des applications (IAST) et la protection de sécurité des applications en temps réel (RASP). IAST place un agent dans une application. RASP est un outil de sécurité placé dans une application qui peut répondre aux attaques en direct.

Réduire la complexité de la chaîne d'outils

En plus de la maintenance fastidieuse, une chaîne d'outils complexe peut exposer un système aux risques de sécurité. De nombreuses équipes DevSecOps utilisent des plug-ins, des scripts ou des intégrations personnalisées codées directement dans le code source pour rassembler leurs outils. Étant donné que certains d'entre eux doivent être effectués manuellement, ces chaînes d'outils sont sujettes à des erreurs humaines. En outre, plus d'outils signifie plus d'authentification, plus d'autorisations, des exigences de sécurité et moins de visibilité sur le cycle du développement logiciel. À cause de ces couches d'abstraction, il est plus difficile non seulement de cerner les problèmes, mais aussi de les résoudre.

Un système complexe intègre plusieurs points d'échec. Si les entreprises veulent contrôler en amont, réduire une partie de cette complexité facilite l'intégration de la sécurité et de la conformité dans le cycle de vie du développement. Une chaîne d'outils complexe ou un environnement de plug-in peut également causer des pipelines fragiles qui nécessitent une attention particulière.

Durcir vos systèmes d'intégration continue

Le durcissement est le processus de sécurisation d'un système en réduisant sa surface de vulnérabilité. Semblable à la réduction de la complexité de la chaîne d'outils pour restreindre les sources de risque, le durcissement des listes de contrôle permet à une entreprise d'examiner ses systèmes internes pour s'assurer qu'ils suivent les meilleures pratiques de sécurité.

Une recommandation est de durcir les systèmes qui hébergent les dépôts d'artefacts source et de compilation, les serveurs CI et de livraison continue (CD), ainsi que les systèmes qui hébergent les outils de gestion, de compilation, de déploiement et de publication de la configuration. Assurez-vous que votre équipe sait ce qui est fait sur site par rapport à ce qui est dans le cloud, et comment cela affecte les workflows.

Le durcissement de votre système d'intégration continue, en plus de l'intégration des analyses de sécurité dans vos pipelines de déploiement, peut faciliter le contrôle en amont pour les équipes.  Les équipes DevOps matures mettent naturellement en œuvre des tests de sécurité dans leur processus d'intégration continue et adoptent l'approche du contrôle en amont. Plutôt que de traiter la sécurité comme une réflexion après coup, ces équipes DevSecOps la gardent à l'esprit en permanence.