Ceci est un impératif : les entreprises de développement informatique doivent être à la fois agiles et sécurisées. Le DevOps ne suffit plus. C’est pourquoi les équipes de sécurité et de développement doivent travailler à l’unisson, afin de produire un code conforme aux réglementations, plus robuste et moins coûteux. Pour répondre à ces enjeux, 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.
Car réussir sa transition vers le DevSecOps implique de réévaluer le rôle et la responsabilité des équipes de sécurité et des équipes de développement. Ce changement de culture soulève un véritable défi, puisque la plupart des professionnels de la sécurité n’ont jamais travaillé aux côtés des équipes de développement. Or, la clé du bon fonctionnement du DevSecOps réside dans la capacité de ces deux parties à travailler ensemble.
Ainsi, comment adopter une stratégie AppSec permettan de transformer efficacement DevOps en DevSecOps ? Réponse en six étapes avec le cabinet d’analystes Securosis qui a publié son dernier rapport en la matière, « Building an Enterprise DevSecOps Program ».
1. Phase 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 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é.
2. Phase 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.
3. Phase 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.
4. Phase 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 veulent trouver 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.
5. Phase de pré-déploiement
Il s’agit désormais 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.
6. Phase 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 en nouveau code. Si des erreurs sont découvertes, le code correspondant est retiré et les problèmes sont résolus.
* Le balisage de fonctionnalités : de nouveaux éléments de code peuvent être activés et désactivés à l’aide du balisage de fonctionnalités. Si des erreurs sont identifiées dans une nouvelle section de code, les développeurs peuvent désactiver la fonctionnalité jusqu’à ce que le problème soit résolu.
___________________
Par Nabil Bousselham, architecte de solutions, Veracode