La modernisation des opérations va accroître le besoin de sécurité de la chaîne d'approvisionnement en logiciels

Il n’est pas surprenant que les aspects de sécurité de la chaîne d’approvisionnement en logiciels soient menacés de nos jours. Le premier problème de Log4j a fait la une des journaux et a poussé tout le monde à se démener pour atténuer cette vulnérabilité très répandue et problématique dans la chaîne d'approvisionnement des logiciels.

Plus récemment, Spring4Shell est apparu sur notre radar ; une autre vulnérabilité introduite par le framework qui provoque le chaos pour les entreprises qui doivent faire face à la menace.

Il a donc été plutôt agréable de voir GitHub introduire de nouvelles fonctionnalités ciblant la sécurité de la chaîne d’approvisionnement en logiciels. C'était particulièrement agréable après avoir digéré le dernier rapport de Sonatype sur l'état de la chaîne d'approvisionnement logicielle , dans lequel ils ont fourni des statistiques qui devraient effrayer tout technologue soucieux de la sécurité, quel que soit son rôle. À noter :

• Il existe désormais 37 millions de versions de composants OSS disponibles
• 29 % des projets populaires contiennent au moins une vulnérabilité de sécurité connue
• Augmentation de 650 % d'une année sur l'autre des cyberattaques visant les fournisseurs open source

Ces résultats sont particulièrement troublants car le rapport a déterminé que « l’application moderne moyenne contient 128 dépendances open source ».

Bon, vous savez que je ne suis pas fan des maths, mais faisons-en.

Dans l' État de la stratégie d'application 2022 , nous trouvons plusieurs statistiques qui méritent d'être soulignées :

• Les applications modernes (conteneurs natives et mobiles) représentent en moyenne 33 % du portefeuille d'applications d'entreprise
• Les entreprises de tous les secteurs d'activité maintiennent un portefeuille d'applications moyen d'environ 200 applications

Ainsi, 33 % de 200 signifie que l’entreprise type possède en moyenne 66 applications modernes dans son portefeuille. En utilisant la moyenne de dépendance open source de Sonatype, cela signifie que l'entreprise moyenne pourrait avoir la charge de sécuriser 8 448 dépendances open source différentes. Il y a presque certainement un chevauchement entre les applications. Les applications natives de conteneurs partagent presque toujours le même environnement d'orchestration de conteneurs (Kubernetes est le roi du COE en ce moment), et donc la charge est en fait plus faible en termes de dépendances spécifiques, mais pas dans le sens où chacune de ces instances doit être mise à jour en cas de vulnérabilité.

Sans faire plus de calculs, convenons tous simplement que sécuriser la chaîne d’approvisionnement en logiciels est aujourd’hui une tâche importante compte tenu de la taille des portefeuilles d’applications et de l’inclusion de dépendances open source.

La nouvelle fonctionnalité de GitHub permet de résoudre ce problème en « trouvant et en bloquant les vulnérabilités qui ne sont actuellement affichées que dans le diff enrichi d’une demande d’extraction ». En d’autres termes, il s’intègre dans le pipeline CI/CD et analyse, en temps réel, les vulnérabilités connues.

Cool. Ce n’est pas une capacité inhabituelle. DevSecOps est à l’origine de ce type de mouvement de « glissement vers la gauche » de la sécurité depuis des années maintenant. La plupart des pipelines CI/CD, quels que soient les outils, sont capables d'effectuer des analyses de sécurité sur le code. Cependant, tous n’intègrent pas la capacité de rechercher des vulnérabilités connues qui peuvent être profondément cachées dans les dépendances ou le résultat d’une erreur logique qui n’est pas aussi facile à détecter.

Bien entendu, vous devez inclure autant de sécurité que possible dans le pipeline CI/CD pour éliminer les vulnérabilités et les erreurs qui peuvent vous mordre les fesses plus tard. Mais ce n’est pas pour cela que nous avons fait cet exercice.

SRE, logiciels et sécurité de la chaîne d'approvisionnement

La raison pour laquelle je soulève le problème de la chaîne d’approvisionnement en logiciels existante est qu’elle ne fera qu’empirer à mesure que les organisations moderniseront leurs opérations avec des approches SRE. C’est parce qu’à la base, les pratiques SRE reposent sur l’automatisation qui, comme vous le savez certainement, dépend de logiciels et de scripts, dont beaucoup sont – attendez – open source.

En fait, il ne devrait pas être surprenant d’apprendre que bon nombre de ces outils open source utilisés par DevOps seront utilisés par les SRE. Si vous souhaitez simplifier les rôles et les relations, les SRE sont des DevOps pour la production. Alors que les praticiens DevOps se concentrent généralement sur le pipeline de création et de publication de logiciels, les SRE se concentrent sur le pipeline des opérations logicielles. Cela concerne non seulement les applications, mais également les services de sécurité et de distribution des applications, ainsi que les plateformes et les environnements (comme le cœur, le cloud et la périphérie). Le champ d'action du personnel SRE s'étend à l'ensemble de la pile informatique, ce qui rend leur tâche beaucoup plus difficile lorsqu'il s'agit de sécuriser la chaîne d'approvisionnement en logiciels.

Il suffit de dire que la sécurité de la chaîne d’approvisionnement des logiciels doit être une préoccupation pour toutes les organisations, car elle a un impact sur l’ensemble du cycle de vie des applications, du développement à la création, en passant par la publication, le déploiement et l’exploitation.

Et cela devrait être une préoccupation pour les organisations qui espèrent survivre à leur parcours de transformation numérique. Un changement important est en cours dans les entreprises du monde entier, et il impacte le cœur même de l’organisation : l’architecture d’entreprise.

La plupart des architectures d’entreprise ont été établies il y a des décennies, sur la base de cadres développés selon le principe selon lequel les ressources étaient fixes et inflexibles et que le centre de données était au centre de l’univers commercial.

Rien de tout cela n’est plus vrai, et même si c’était le cas, le secteur d’activité a lui aussi changé. Cette activité est désormais de plus en plus numérique, et une entreprise numérique avec des processus pilotés par les données ne peut pas être représentée de manière adéquate par une architecture conçue pour représenter une entreprise physique avec des processus pilotés par l’humain. L’architecture d’entreprise doit être modernisée et, ce faisant, de nouveaux domaines doivent être intégrés, comme celui des opérations SRE.

Et ils le sont. Notre étude de cette année a révélé que 37 % des organisations ont déjà adopté des opérations SRE pour moderniser leurs applications et leurs opérations, et 40 % supplémentaires prévoient de le faire dans les 12 prochains mois. Cela signifie des outils et des scripts, des logiciels et des données, ainsi qu’une pile complète de technologies qui prendront en charge ce nouveau rôle au sein de l’organisation.

Et avec les logiciels, les scripts et les piles viennent les chaînes d’approvisionnement et la sécurité. Et la seule chose que nous avons apprise de DevOps et que vous ne pouvez pas ignorer lorsque vous modernisez vos opérations est que les pratiques SRE entraîneront une grande partie de la même dette technique et des mêmes défis de sécurité.

La bonne nouvelle est que, contrairement à DevOps et aux processus de build, les opérations SRE seront une nouvelle pratique pour les organisations. Et établir de nouvelles pratiques signifie établir de nouvelles façons de fonctionner, y compris en intégrant la sécurité dès le début.