Faire de la sécurité une priorité dès le début, c’est une question de culture, pas seulement d’outils

Voici la deuxième partie d’une série en quatre volets consacrée à l’élaboration de votre stratégie AppSec pour Kubernetes. La première partie se trouve ici.

À mesure que les organisations adoptent les pratiques DevOps et transforment leur manière de développer et de maintenir des applications, de nombreux aspects du développement logiciel évoluent.

Dans de nombreuses organisations, l’administration système traditionnelle a évolué avec l’adoption de l’ingénierie de la fiabilité des sites et de la philosophie « vous le construisez, vous l’exploitez ». Les réseaux sont de plus en plus décrits sous forme logicielle, notamment avec l’essor du service mesh. Les discussions sur la supervision ne visent plus à résoudre les inconnues connues, mais se concentrent sur l’observabilité et les inconnues inconnues. La tendance est claire : les développeurs prennent en charge un nombre croissant d’aspects liés à l’exploitation des applications. En matière de sécurité, cette évolution ne fait que commencer. Pour réussir cette transition, nous devons choisir les bons outils et bâtir une culture adaptée.

Les conteneurs comme unité logicielle

Prenons les conteneurs pour explorer les questions des outils et de la culture. Comme nous l’avons indiqué dans l’article précédent, les conteneurs deviennent de plus en plus l’unité logicielle standard. Nous créons des images, en discutons entre équipes, formulons des affirmations à leur sujet et les utilisons généralement pour nous abstraire des formats de packaging propres aux plateformes ou aux langages.

L’idée d’un format de package unique, d’un dépôt de packages et d’un mécanisme permettant d’installer ces packages en production n’est pas nouvelle. Les packages et dépôts RPM, ainsi que des outils comme Yum, correspondent sans doute à ce modèle. Mais les conteneurs présentent deux différences importantes, davantage organisationnelles que techniques :

1. La gestion du packaging des systèmes d’exploitation était souvent confiée à une équipe distincte au sein de l’organisation des opérations.

2. Peu d’organisations n’utilisent qu’un seul format de packaging. Chaque système d’exploitation et chaque langage de programmation dispose de sa propre chaîne d’outils de packaging.

La nouveauté des images de conteneurs, c’est que la responsabilité du packaging revient presque toujours aux développeurs et aux équipes de développement. C’est pourquoi on trouve, par exemple, plus de 2 millions de fichiers Dockerfile publics sur GitHub. Les outils de test et de sécurité conçus pour l’ancienne génération de packaging et les anciennes pratiques organisationnelles s’intègrent mal aux workflows et aux chaînes d’outils des développeurs modernes. Ainsi, les correctifs consistent de plus en plus à reconstruire et redéployer des artefacts immuables plutôt qu’à apporter directement des modifications en production.

La gestion des vulnérabilités des conteneurs vous intéresse ? Découvrez comment Snyk peut vous aider à sécuriser vos conteneurs.

Des outils conçus pour les développeurs

La standardisation des images nous offre de nombreuses possibilités de créer des outils véritablement conçus pour les développeurs et adaptés à cette évolution. Quelles sont les caractéristiques de cette nouvelle génération d’outils ?

• Utilisables en local : la plupart des développeurs écrivent et lisent du code sur leur machine. Les outils qui fonctionnent en local leur permettent de se familiariser avec un nouveau domaine.

• Intégrés aux IDE : lorsque les développeurs utilisent des environnements de développement intégrés, les outils qu’ils utilisent doivent y être intégrés.

• Interagir directement avec les systèmes de gestion du code source : les systèmes de gestion du code source, de plus en plus basés sur Git, rythment le travail quotidien des développeurs. Les outils destinés aux développeurs doivent s’intégrer à leur équipe, d’autant plus que les approches comme GitOps gagnent du terrain.

• Configurables dans les pipelines CI/CD : l’intégration continue est indispensable à une livraison logicielle efficace. C’est aussi l’endroit idéal pour intégrer des contrôles qualité, tant que la boucle de rétroaction des développeurs reste courte.

L’un des avantages des outils couvrant l’ensemble du cycle de développement logiciel (SDLC), c’est qu’ils aident les développeurs à mieux comprendre l’application et évitent le fameux « ça marche sur ma machine ».

Une culture DevOps fondée sur le partage

La qualité et la sécurité ne relèvent pas uniquement des développeurs : les spécialistes de l’exploitation et de la sécurité restent indispensables à la réussite. Leur expertise est nécessaire pour guider et sensibiliser les équipes à l’intégration de la sécurité dès le début, à mesure que les responsabilités sont confiées aux équipes de développement. Tout comme les équipes d’ingénierie de la fiabilité des sites (SRE) aident les développeurs à mieux exploiter leurs applications, les équipes de sécurité doivent adopter la même approche.

Les outils qui favorisent le partage entre différentes disciplines, souvent au-delà des frontières organisationnelles, sont indispensables, et non simplement souhaitables. Les autres options ne suffisent pas : des fonctions séparées dotées d’outils concurrents, ou un groupe relégué à une expérience de second ordre. Si les équipes d’exploitation utilisent un ensemble d’outils et les développeurs un autre, cela ne fera que créer des silos organisationnels. Cela ne signifie pas qu’il faut un outil unique pour tout faire. Les outils modernes destinés aux développeurs se concentrent sur les applications et les retours intégrés au processus de développement. Ils doivent bien s’intégrer aux outils d’exploitation, capables d’effectuer des investigations détaillées et de produire des rapports dans la durée, tout en prenant en charge les abstractions utilisées par les différents rôles.

Conclusion

Les discussions sur l’« intégration de la sécurité dès le début » portent souvent sur le transfert des responsabilités des fonctions informatiques traditionnelles vers les équipes de développement, afin d’accélérer la boucle de rétroaction. Mais transformer en profondeur nos méthodes de travail sans faire évoluer aussi les outils fonctionne rarement. Le développement de logiciels complexes est en soi un système sociotechnique complexe. À mesure que les développeurs prennent davantage en charge les enjeux de sécurité, nous devons aussi reconnaître que les outils dont ils ont besoin diffèrent de ceux de la génération précédente, conçus pour les équipes d’exploitation.