À l'heure actuelle, le développement d'applications est aussi intéressant que problématique. En effet, les développeurs d'applications modernes et cloud utilisent désormais les pratiques DevOps, dont les outils gagnent rapidement en maturité. L'approche DevOps a fourni aux entreprises une méthode pour répondre plus rapidement à leurs besoins. Mais à quel prix ? Le coût se traduit, et se mesure, en termes de complexité croissante et d'affaiblissement de la sécurité. Ce prix est trop élevé et rares sont les entreprises prêtes à donner suite. 

Dans de nombreuses entreprises, les problèmes de sécurité stoppent ou retardent le déploiement des applications conteneurisées. Il pourrait sembler tentant de revenir aux anciennes pratiques de développement dépassées, mais ces dernières ne constituent en aucun cas une solution viable. Vous devez plutôt améliorer votre approche DevOps et incorporer la sécurité et l'automatisation tout au long du cycle de vie. La sécurité et l'automatisation doivent être intégrées au processus, non pas en tant qu'étapes indépendantes, mais en tant qu'éléments constitutifs de l'ensemble du cycle de vie de l'application. Le schéma ci-dessous fournit une vue d'ensemble du cycle de vie DevSecOps. 

Vous remarquerez que la sécurité n'est pas représentée comme un élément distinct ; elle est intégrée à l'ensemble du cycle. Dans l'idéal, la plupart des mécanismes de sécurité sont automatisés et quasiment invisibles aux yeux des équipes de développement et d'exploitation. Cependant, la réalité est toute autre, puisque la plupart des entreprises ont encore recours aujourd'hui à des processus essentiellement manuels et invasifs pour intégrer la sécurité.

Le terme DevSecOps est souvent utilisé de façon abusive, comme s'il suffisait d'ajouter quelques touches de sécurité çà et là pour que la magie du DevSecOps opère. Ta da ! Malheureusement, en pratique, ce n'est pas aussi simple. À l'heure actuelle, le terme DevSecOps désigne plus souvent des éléments de solution qu'une solution complète. Voyons cela plus en détail…

Passer du DevOps au DevSecOps

De nombreuses entreprises ont intégré la sécurité dans certains domaines du DevOps. 

Mary : « Salut ! Il paraît que vous avez avancé les phases de test la semaine dernière... Ça y est, tout est bien sécurisé ? »

Bob : « En effet, nous avons adopté la méthode DevSecOps et c'est génial ! J'ai reçu une grosse prime et j'ai pu annoncer aux collègues du centre opérationnel de sécurité qu'ils pouvaient partir en congés payés jusqu'à la fin du trimestre. »

Trop beau pour être vrai, non ?

L'approche DevSecOps ne consiste pas uniquement à déplacer les tests au début du cycle de vie des applications. Elle vise à intégrer la sécurité tout au long du cycle de vie DevOps. Il faut y penser à chaque étape afin de garantir que les contrôles et vérifications nécessaires sont mis en place sur l'ensemble du cycle. Ainsi, lors du passage en production, en cas d'intrusion, la surface d'exposition aux attaques est réduite au minimum. Plus facile à dire qu'à faire. 

Vous êtes décidé à vous lancer sérieusement ? Alors voyons ensemble comment procéder. « Le secret, c'est la technologie ! N'est-ce pas ? » Non...

Tout est question de culture

Si tout l'équipage ne rame pas dans la même direction, le bateau tourne en rond. Il est donc essentiel de développer une culture de la collaboration entre les développeurs, les équipes d'exploitation et, bien sûr, les équipes de sécurité. La première étape consiste à comprendre la structure de l'entreprise, à identifier les services où la collaboration est déjà bien établie et ceux où des progrès restent à faire. Utilisez comme exemple les services où tout se passe bien afin de valoriser la collaboration auprès des autres équipes.

Vous devez aider tous les collaborateurs à comprendre l'importance de la sécurité dans le cycle de vie DevOps et la manière de la mettre en œuvre. La sécurité ne doit jamais passer au second plan, y compris lorsqu'il est question de gérer le contrôle des sources, choisir des images de base pour le développement des conteneurs, protéger les données en développement et en production, etc. Aidez-les à comprendre que la collaboration ne leur permettra pas seulement de détecter les failles de sécurité au cours du développement, mais qu'elle ouvrira également la voie à des réponses plus efficaces en matière de sécurité. Une sécurité renforcée, plus visible et intégrée plus tôt dans le cycle a des répercussions positives sur l'exploitation : moins d'incidents et des problèmes corrigés plus rapidement.

Par exemple, les équipes d'exploitation ne se rendent pas toujours compte qu'un problème peut potentiellement constituer une faille de sécurité. Elles cherchent les erreurs de configuration logicielle ou matérielle ou encore des problèmes au niveau de l'infrastructure. Les équipes de sécurité, en revanche, traquent immédiatement les failles. Il est donc essentiel que ces deux équipes collaborent pour analyser simultanément les deux types de problèmes, sachant que l'un peut avoir provoqué ou rendu possible l'apparition de l'autre.

Intéressons-nous maintenant à vos pratiques de codage sécurisé. « Comment ça ? Le code, c'est de la technologie, pas de la culture, non ? » Non.

Dans le cadre d'une approche DevSecOps, il est préférable d'évaluer et de mettre à jour vos pratiques de codage au début du projet. Bien que vous ne puissiez pas attendre de vos développeurs qu'ils deviennent des spécialistes de la sécurité, vous devez vous assurer qu'ils se forment aux pratiques de codage sécurisé, en y consacrant le temps et le budget nécessaires. Ils doivent comprendre l'importance de produire un code sécurisé. La mise en place et l'application de normes de codage permettent de renforcer la cohérence des pratiques et aident les développeurs à créer du code propre. Toutefois, la réussite de cette approche dépend en majeure partie de la culture de votre entreprise.

« Très bien, c'est clair. Et la technologie dans tout cas ? »

Encore un peu de patience.

Les processus avant tout

Ai-je parlé des processus ? Et oui… Eux aussi sont importants. Il n'y a pas si longtemps, on développait encore les applications sans se soucier du déploiement, de l'exploitation et de la maintenance. Ces questions, on ne se les posait qu'après. Les déploiements et mises à jour d'applications restaient rares, car ils impliquaient de longs cycles de test et potentiellement des temps d'arrêt. L'arrivée du DevOps a tout changé. Cette méthode a permis d'accélérer le développement, d'augmenter la fréquence des déploiements, d'en améliorer la qualité et de supprimer de nombreux écueils rencontrés durant l'exploitation. C'était LA solution idéale !

Pas tout à fait… 

Avec l'approche DevOps, nous avons réduit la durée des cycles de test, qui permettaient d'éliminer de nombreux bogues et failles de sécurité. Nous avons également nettement augmenté la fréquence des mises à jour, et par conséquent le nombre de bogues et de failles de sécurité potentiels. En outre, la résolution des problèmes s'est complexifiée, car plusieurs versions d'une même application peuvent désormais être exécutées simultanément.

Pour concrétiser une stratégie efficace, vous devez mettre en place une équipe DevSecOps unique ou former une équipe virtuelle pluridisciplinaire.Quel que soit votre choix, ces équipes doivent gérer différentes tâches dans un certain ordre en utilisant plusieurs outils. Imaginez que votre solution DevSecOps soit constituée d'un grand environnement qui compte une dizaine d'outils. Vous pouvez comprendre pourquoi la standardisation, la documentation et l'automatisation du workflow jouent un rôle essentiel. En concevant et en exécutant des processus réfléchis et validés, vous améliorerez l'efficacité et la sécurité tout au long du cycle de vie.

Voilà, maintenant nous pouvons parler de la technologie.

Le DevSecOps, ou l'art d'intégrer la sécurité

Une fois que vous maîtrisez l'aspect culturel du DevSecOps, vous pouvez vous pencher sur la technologie. Enfin !

Intéressez-vous aux plateformes, outils et processus que vous utilisez pour le développement des applications, le déploiement et l'exploitation. Votre objectif consiste à les transformer en un système unique et cohérent, le DevSecOps. Ces différents outils sont-ils adaptés pour former un unique système cohérent qui garantira le fonctionnement optimal de votre entreprise ? Il n'existe aucune solution clé en main, alors vous devrez créer la vôtre. Je vous recommande quand même de vous adresser à des spécialistes.

Pour commencer, vous devez trouver le moyen d'assembler vos outils et processus en une solution optimale pour votre environnement.Si l'intégration de la sécurité tout au long du cycle de vie est assez facile à imaginer, sa mise en pratique n'est pas forcément évidente.

Cette question mériterait plusieurs pages de discussion, mais nous allons nous limiter à deux points principaux. Vous devez identifier en parallèle, et de manière itérative, les besoins en automatisation et les outils nécessaires afin de garantir que ces derniers seront optimisés pour le processus que vous avez conçu.

Que vous partiez de zéro ou que vous cherchiez à réutiliser ce que vous avez déjà, déterminez les capacités dont vous aurez besoin à chaque étape du cycle de vie. Vérifiez que les fonctions et fonctionnalités des outils sélectionnés permettent bien de résoudre les problèmes dans votre environnement spécifique. Attention : les outils qui permettent de résoudre des problèmes similaires aux vôtres ne sont pas tous adaptés à votre environnement. Identifiez les capacités manquantes, documentez-les et assurez-vous que tout le monde en soit informé. Cherchez ensuite à les combler aussi vite que possible. Vous aurez peut-être besoin d'autres outils, de plus d'automatisation ou d'étoffer vos équipes.

Voici un exemple de framework qui illustre un cycle de vie de base et les méthodes de sécurité utilisables dans chaque secteur. Vous pouvez vous en inspirer pour sélectionner les éléments dont vous avez besoin pour votre environnement et y répertorier ceux dont vous disposez déjà ainsi que leur emplacement.

Il ne manquerait pas quelque chose dans ce diagramme ? Vous aussi vous avez remarqué ? J'ai évoqué l'automatisation des outils et des processus à de nombreuses reprises, mais elle n'apparaît pas ici. Pourquoi ? Parce qu'elle intervient à différents endroits selon les outils que vous choisissez et vos besoins en matière d'automatisation. L'automatisation est souvent considérée comme un moyen d'effectuer plus de tâches, plus rapidement, avec des équipes réduites. Mais en réalité, l'automatisation offre bien d'autres possibilités.

C'est là que la boucle de rétroaction et d'optimisation prend toute son importance. Il est essentiel de déterminer si les outils fonctionnent correctement ensemble et de quelle manière. Si vous ne parvenez pas à intégrer et/ou automatiser un outil donné dans le système, alors vous devez revenir à vos outils et les évaluer à nouveau.

Vos outils et technologies fonctionnent-ils conjointement de manière native ou requièrent-ils des outils tiers ou personnalisés ad hoc (souvent créés en interne) ? Automatisez autant que possible : analyse, conformité, gestion de configuration, application des politiques, etc. Automatisez tous les processus reproductibles et cohérents qui ne nécessitent aucune intervention humaine, donc pas une simple arborescence. En effet, l'automatisation des systèmes vous permet d'améliorer les processus et de réduire le nombre d'erreurs humaines susceptibles de causer des problèmes ou de créer des failles de sécurité.

De l'importance de l'écosystème

Que pensez-vous des points abordés jusqu'à présent ? Cette approche vous semble facile ?  Si oui, félicitations, vous êtes un expert ! Vous pouvez arrêter votre lecture ici et sauter directement à la partie pratique.

Sinon… restez avec moi et poursuivez votre lecture.

Pour la plupart des entreprises, se lancer seul s'avère intimidant et potentiellement dangereux. Il est important de choisir des outils et des fournisseurs qui collaborent étroitement et qui vous aideront à concevoir un système DevSecOps unique et cohérent. Vous devez éviter de créer une solution qui effrayera les fournisseurs ou dont l'utilisation les interpellera, car si tel est le cas, votre système DevSecOps n'est qu'un assemblage d'éléments disparates, et non une solution parfaitement intégrée.

L'écosystème joue un rôle essentiel. Vous ne pouvez pas vous contenter d'obtenir une certification pour une plateforme, vous devez également vous soucier de la manière dont les éléments de votre système fonctionnent ensemble. Est-ce que vos solutions forment un système en étoile au centre duquel votre entreprise représente le hub qui vous connecte aux différents éléments ? Est-ce vous qui contrôlez tous les points de connexion et qui servez d'intermédiaire unique entre vos solutions ? Ou est-ce que vous avez fait appel à un fournisseur tel que Red Hat afin de bénéficier d'un écosystème de sécurité maillé et de fournisseurs qui collaborent entre eux ainsi qu'avec Red Hat pour garantir que votre entreprise ne se retrouvera pas seule à gérer les problèmes qui pourraient se présenter ? Et comment envisagez-vous les mises à jour des principaux composants, tels que la plateforme cloud, l'organisateur de conteneurs ou encore les progiciels des principaux éditeurs ?

Maintenant que vous vous êtes posé toutes ces questions, vous pourrez comprendre comment Red Hat tire parti de son écosystème de partenaires pour assurer la sécurité du cycle de vie des conteneurs et le DevSecOps. Ce diagramme vous donne un aperçu de ce que devrait être un écosystème selon Red Hat :

Pour entamer votre parcours vers le DevSecOps, nous vous invitons à participer à nos webinars et ateliers. Red Hat, ainsi que CyberArk, Palo Alto, Synopsys et Sysdig y présentent le framework DevSecOps de Red Hat et les principales technologies de sécurité à intégrer à votre environnement.


À propos de l'auteur

Aaron Levey is Head of Red Hat's Global Security Partner Ecosystem and Strategic Partners. Over 23 years, he has held positions at Microsoft, Dell, HPE, Equinix and consulting for American Express, Wells Fargo and others. When not working, his family is exploring the outdoors in Colorado, adventuring in the kitchen, or enjoying down-time watching a movie or playing games.

Read full bio