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
• Les cyberattaques contre les fournisseurs de logiciel libre ont augmenté de 650 % en un an

Ces résultats sont particulièrement inquiétants car le rapport révèle que « l’application moderne moyenne comporte 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

Donc, 33 % de 200 signifie que l’entreprise typique possède en moyenne 66 applications modernes dans son portefeuille. En se basant sur la moyenne des dépendances open source de Sonatype, cela implique que l’entreprise peut devoir sécuriser 8 448 dépendances open source différentes. Il y a très certainement des recouvrements entre les applications. Les applications natives des conteneurs partagent presque toujours le même environnement d’orchestration de conteneurs (Kubernetes domine actuellement les environnements de cloud ouverts), réduisant ainsi le nombre de dépendances spécifiques, mais cela ne change pas que chaque instance doit être mise à jour en cas de vulnérabilité.

Sans entrer dans les calculs, convenons que sécuriser la chaîne d'approvisionnement logicielle aujourd’hui représente un défi important, compte tenu de la taille des portefeuilles d’applications et de l’intégration 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

Je souligne le problème de la chaîne d'approvisionnement logicielle actuelle parce qu'il va clairement s’aggraver au fur et à mesure que vous modernisez vos opérations avec les méthodes SRE. En effet, les pratiques SRE reposent sur l’automatisation qui, comme vous le savez, s’appuie sur des logiciels et des scripts, dont beaucoup sont — tenez-vous bien — des logiciels libres.

Il n'est en fait pas étonnant que de nombreux outils open source utilisés par les DevOps le soient aussi par les SRE. Pour simplifier les rôles et les liens, considérez les SRE comme des DevOps dédiés à la production. Tandis que les DevOps se concentrent généralement sur la chaîne de construction et de déploiement des logiciels, les SRE gèrent la chaîne des opérations logicielles. Ils prennent en charge non seulement les applications, mais aussi la sécurité et la livraison des applications, ainsi que les plateformes et environnements comme le cœur de réseau, le cloud et le edge computing. Les SRE couvrent l’ensemble de la pile informatique, ce qui rend leur mission bien plus complexe pour assurer la sécurité de la chaîne d’approvisionnement logicielle.

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 datent de plusieurs décennies, construites sur des cadres conçus avec l’idée que les ressources étaient fixes et rigides, et que le centre de données restait au centre de l’activité.

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.