En intégrant les équipes et les outils de sécurité directement dans le cycle de développement logiciel, DevSecOps permet d’assurer que les tests de sécurité ont lieu à chaque cycle de développement. Si le concept est bien compris, son intégration laisse toutefois à désirer. Voici une méthodologie en six étapes.
Pour les esprits perspicaces, la dénomination même de DevSecOps semble inappropriée. En effet, l’intégration de Sec dans DevOps semble indiquer que la sécurité est un élément extérieur, ajouté, au processus, alors qu’elle devrait faire partie naturellement de tout processus de développement. Étant ainsi un élément naturel, elle ne devrait pas faire l’objet d’un ajout spécifique à la dénomination DevOps.
Mais le marché en a décidé autrement, certainement pour attirer l’attention des entreprises sur une évidence : la sécurité doit faire partie du processus de développement du code, dès le début. Il est vrai que lorsqu’on constate la naïveté, pour ne pas dire la légèreté, avec laquelle certains éditeurs laissent des trous béants, ceci sans parler des entreprises, il paraît nécessaire de donner une visibilité ostentatoire à la sécurité, en calant Sec bien au milieu entre Dev et Ops.
Comment passer de DevOps à DevSecOps
Ceci dit, le concept semble avoir été bien intégré et l’automatisation accrue permet de tirer parti de l’efficacité de DevOps pour garantir que les tests de sécurité des applications ont lieu à chaque cycle de développement. Cela favorise la sécurité et la cohérence, et contribue à garantir que la sécurité n’est pas moins prioritaire que d’autres mesures ou caractéristiques de qualité. Les tests de sécurité automatisés, tout comme la construction et le déploiement d’applications automatisées, doivent bien entendu être assemblés avec le reste de l’infrastructure. Le but étant de produire un code robuste, sécurisé et conforme aux réglementations, et pour des coûts moindres.
Cependant, même si le concept est compris et accepté, la pratique laisse à désirer, comme le constate Nabil Bousselham, architecte de solutions chez Veracode. « De plus en plus d’entreprises plébiscitent — en théorie — le DevSecOps. Pourtant, dans la pratique, nombre d’entre elles ne savent pas comment recourir à ce protocole », affirme-t-il. Ainsi, pour passer de DevOps à DevSecOps, Nabil Bouselham préconise une démarche en six étapes que voici :
1Phase de définition de l’architecture
La première étape consiste à analyser en profondeur l’architecture de sécurité de l’entreprise pour déterminer comment les applications fonctionnent et communiquent. Sur la base de cette analyse, les entreprises peuvent fixer de nouvelles normes opérationnelles contraignantes. Parmi elles, les exigences minimales pour les tests de sécurité et des délais fixes pour le dépannage. Elles peuvent également décider des tests de sécurité à effectuer et des mesures souhaitées afin d’en déterminer l’efficacité.
2Phase de conception
L’objectif principal de cette étape est de garantir la sécurité des environnements de développement et de test. Cela nécessite des contrôles d’accès stricts pour les pipelines CI/CD et une surveillance supplémentaire pour les scripts en arrière-plan. Les développeurs doivent également être formés aux menaces courantes.
3Phase de développement
Lorsque les prérequis sont en place, un point central peut désormais être abordé : l’automatisation des tests. Pour ce faire, les développeurs ont besoin de référentiels sécurisés. Les entreprises doivent ainsi avoir accès à des bibliothèques open source sécurisées et partagées en interne. Avec une combinaison d’outils d’analyse et de scripts, les responsables peuvent s’assurer que les développeurs ne travaillent qu’avec les versions publiées. Les entreprises devraient également établir des tests de sécurité des applications interactives (IAST). Cette méthode peut être utilisée pour identifier les faiblesses de l’exécution avant qu’un code ne soit produit.
4Phase de test
Conformément à l’approche « Shift Left », les tests doivent être lancés le plus tôt possible dans le cycle de vie du logiciel. Il va sans dire que les entreprises doivent débusquer des bogues dans leurs logiciels avant les criminels. De plus, les environnements de test doivent être contrôlés en permanence pour garantir leur efficacité. Grâce à divers tests effectués en parallèle, des méthodes peuvent être identifiées pour ralentir le système et le remplacer par des méthodes plus efficaces.
5Phase de prédéploiement
Il s’agit dans cette phase de combiner sécurité et vitesse. À cette fin, les entreprises ont recours aux services cloud à la demande. Les environnements de production doivent également être protégés contre les fuites de données en utilisant des outils tels que le masquage des données ou la tokenisation, qui garantissent que les développeurs disposent de toutes les données de test, mais sans avoir accès aux informations sensibles.
6Phase de déploiement
La dernière phase consiste à laisser les bulles de test individuelles croître afin de déterminer si le code qui fonctionnait avant le déploiement s’exécute également pendant le déploiement. Si le déploiement doit ensuite être étendu, les entreprises peuvent avoir recours à trois méthodes :
- un déploiement bleu-vert ou rouge-noir : l’ancien et le nouveau code s’exécutent en parallèle sur leurs propres serveurs. Si des erreurs se produisent, les équilibreurs de charge reviennent à l’ancien code ;
- le test des canaris : les sessions individuelles sont converties au nouveau code. Si des erreurs sont découvertes, le code correspondant est retiré et les problèmes sont scrutés pour résolution ;
- le balisage de fonctionnalités : de nouveaux éléments de code peuvent être activés et désactivés à l’aide du balisage de fonctions. Si des erreurs sont identifiées dans une nouvelle section de code, les développeurs peuvent désactiver la fonction jusqu’à ce que le problème soit résolu.
