Le rapport de Sonatype sur l'état de la chaîne logistique logicielle en 2021 associe un large éventail de données publiques et privées afin de présenter des conclusions importantes sur l'open source et son rôle croissant dans l'innovation numérique.
Les composants qui réagissent systématiquement et rapidement aux mises à jour des dépendances ont un MTTU faible. À l'inverse, les composants pour lesquels ce délai est plus long ou sujet à des variations importantes sont caractérisés par un MTTU plus élevé.
Imaginons ainsi que notre projet comporte un composant A avec les dépendances B et C, toutes deux à la version 1.2. Supposons maintenant qu'une nouvelle version soit publiée pour chacune (1.3), puis, quelques temps après, qu'une nouvelle version soit cette fois publiée pour le composant A, ce qui entraîne la mise à jour de B et C vers la version 1.3. Le temps écoulé entre la publication de B version 1.3 et de A version 1.3 correspond au délai de mise à jour (TTU) associé à la migration de A vers la version 1.3 de B (il en va de même pour l'adoption de C version 1.3). En calculant la moyenne de ces délais de mise à jour, on obtient ainsi le MTTU.
Supposons qu'un projet A inclut une dépendance B et que B contienne une vulnérabilité divulguée à la date D1. A met à jour la version utilisée de B à la date D2. Le délai de correction (TTR) correspond alors au nombre de jours écoulés entre D1 et D2. Le MTTR désigne quant à lui le TTR moyen d'un projet pour toutes les vulnérabilités de sécurité rendues publiques.
Si le MTTU n'est pas un indicateur direct de la vitesse de correction des vulnérabilités rendues publiques, il est corrélé au délai moyen de correction (MTTR) d'un projet, lequel correspond au temps nécessaire pour mettre à jour les dépendances associées à des vulnérabilités publiques. C'est pourquoi nous considérons le MTTU comme le meilleur indicateur disponible pour déterminer l'impact d'un composant sur la sécurité des projets qui l'intègrent.
Le graphique ci-dessous fournit un résumé visuel des migrations réalisées pour spring-core, un composant unique du très populaire spring-framework, au cours de l'année écoulée. L'axe y montre les 52 dernières semaines d'activité de mise à niveau. La première ligne représente les décisions de migration prises il y a un an. La dernière ligne représente les décisions de migration prises au cours de la dernière semaine. L'axe x représente les 150 versions les plus récentes avec les versions antérieures à gauche et les versions plus récentes à droite. Consultez les observations clés en cliquant sur les points ci-dessous.
La version la plus récente de spring-core (5.3.x) sort environ toutes les 4 semaines.
Le projet gère activement ces 2 versions. Une teinte plus foncée indique que la majorité de la communauté utilise ces versions.
Le projet ne prend plus activement en charge ces versions. Les équipes devraient éviter ces versions obsolètes.
Les retardataires continuent à effectuer des mises à jour avec des versions plus anciennes, non prises en charge, voire vulnérables.
Les anciennes versions sont vulnérables, et les versions actuellement non vulnérables (4.3.15+) seront tôt ou tard sujettes à de nouvelles vulnérabilités.
La communauté évite généralement les versions 0 et préliminaires.
Ne choisissez pas une version alpha, bêta, jalon, candidat à la publication, etc.
.png?width=68&height=88&name=Vector%20(1).png)
Ne faites pas de mise à niveau vers une version vulnérable.
.png?width=71&height=46&name=Vector%20(2).png){kind=small}
Passez à une version moins risquée si la version que vous utilisez est vulnérable.
.png?width=83&height=61&name=Vector%20(3).png)
Lorsqu'un composant est publié deux fois en très peu de temps, choisissez la version ultérieure.
.png?width=71&height=96&name=Vector%20(4).png)
Choose a migration path (from version to version) others have chosen.
.png?width=69&height=82&name=Vector%20(5).png)
Choisissez une version qui minimise les modifications de code avec rupture.
.png?width=79&height=74&name=Vector%20(6).png)
Choisissez la version utilisée par la majorité de la population.
.png?width=80&height=80&name=Vector%20(7).png)
Si aucune de ces options ne s'applique, choisissez la version la plus récente.
Une automatisation intelligente qui standardise les équipes d'ingénieurs travaillant sur des projets open source de référence pourrait éliminer 1,6 million d'heures et 240 millions de dollars de gaspillage concret sur notre échantillon de 100 000 applications de production. Extrapolées à l'ensemble du secteur du logiciel, ces économies se compteraient en milliards.
L'avant-garde est dangereuse. La position optimale se trouve juste derrière. En analysant les comportements de migration autour des pratiques de gestion des dépendances, nous avons observé trois modèles distincts de comportement d'équipe : les équipes qui fonctionnent dans la confusion, les équipes qui fonctionnent sur le fil et les équipes qui fonctionnent au plus près du fil.
Les développeurs qui travaillent dans ces équipes ne disposent pas de conseils automatisés. Ils mettent rarement à jour les dépendances. Quand ils le font, ils se fient à leur intuition et prennent généralement des décisions non optimales. Cette approche de la gestion des dépendances est très réactive, non évolutive et conduit à des logiciels obsolètes et un risque de sécurité accru.
Les développeurs qui travaillent dans ces équipes bénéficient d'une automatisation intelligente et contextuelle. Les dépendances sont automatiquement recommandées pour la mise à jour, mais seulement lorsqu'elles sont optimales. Ce type d'automatisation intelligente permet de maintenir les logiciels à jour, sans gaspiller les ressources ni accroître les risques de sécurité. Cette approche est proactive, évolutive et optimale en matière de rentabilité et de qualité.
Les développeurs qui travaillent dans ces équipes bénéficient d'une automatisation simple, mais non contextuelle. Les dépendances sont automatiquement mises à jour vers la dernière version, que celle-ci soit optimale ou non. Ce genre d'automatisation permet de maintenir les logiciels à jour, mais elle peut, par inadvertance, entraîner une augmentation des risques de sécurité et des coûts liés aux mises à jour inutiles et aux échecs de builds. Cette approche est proactive et évolutive, mais non optimale en matière de coûts ou de résultats.
De façon subjective, les participants de l'enquête pensent corriger les composants défectueux efficacement et affirment comprendre où se trouvent les risques. Cependant, des recherches objectives ont montré que les équipes de développement manquent de consignes structurées et prennent souvent des décisions contestables en ce qui concerne la gestion des chaînes logistiques logicielles.
Nous avons comparé toutes les réponses à l'enquête aux cinq étapes de maturité de la chaîne logistique logicielle et nous avons constaté que la majorité des participants ont obtenu une note inférieure au niveau « Contrôle », qui est considéré comme le point auquel une entreprise passe de la phase de « découverte » à un niveau minimal de maturité permettant d'obtenir des résultats de haute qualité.
Cliquez sur les points à droite pour obtenir des informations supplémentaires.
En mai 2021, le président Biden a signé l'ordre exécutif d'amélioration de la cybersécurité de la Nation, présenté comme une étape importante pour le gouvernement américain à une époque où cyberespionnage et attaques ciblant des infrastructures cruciales atteignent des proportions critiques.
Le gouvernement du Royaume-Uni a annoncé être à la recherche de conseils sur la défense contre les attaques numériques visant les chaînes logistiques pour les entreprises qui consomment des services informatiques ou les fournisseurs de services de sécurité gérés qui fournissent des logiciels et des services.
.png)
L'Allemagne a adopté la loi sur la sécurité des technologies de l'information 2.0 pour mettre à jour la première loi et ainsi « renforcer la sécurité du numérique et de l'information afin de répondre aux cyberattaques de plus en plus fréquentes et complexes, mais aussi à la numérisation constante de la vie quotidienne ».
.png)
En juillet 2021, l'Agence de l'Union européenne pour la cybersécurité (ENISA) a publié un rapport intitulé « Comprendre l'augmentation du nombre d'attaques contre les chaînes logistiques logicielles ». Ce rapport portait sur 24 attaques contre des chaînes logistiques logicielles et partageait des recommandations destinées à aider les entreprises à se protéger contre les attaques.
