Sonatype dévoile sa solution complète de gestion de la chaîne logistique logicielle | Communiqué de presse

2021

État de la chaîne logistique logicielle

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.

banner-right

1

Offre, demande et sécurité open source

L'offre open source se développe de façon exponentielle.

Aujourd'hui, les quatre plus grands écosystèmes open source rassemblent un total combiné de 37 451 682 composants et paquets. L'an dernier, ces mêmes communautés ont publié en tout 6 302 733 versions de composants ou paquets et introduit pas moins de 723 570 nouveaux projets en collaboration avec 27 millions de développeurs aux quatre coins du monde.

Offre open source disponible

Java

0 1 million 2 millions 3 millions 4 millions 5 millions 6 millions 7 millions 8 millions Versions Projets Nouveau en 2021 Disponibles avant 2021 430 995 7,3 MILLIONS

Javascript

0 1 million 2 millions 3 millions 4 millions 5 millions 6 millions 7 millions 8 millions Versions Projets Nouveau en 2021 Disponibles avant 2021 21 MILLIONS 1,8 MILLION

Python

0 1 million 2 millions 3 millions 4 millions 5 millions 6 millions 7 millions 8 millions Versions Projets Nouveau en 2021 Disponibles avant 2021 3 MILLIONS 336 402

.Net

0 1 million 2 millions 3 millions 4 millions 5 millions 6 millions 7 millions 8 millions Versions Projets Nouveau en 2021 Disponibles avant 2021 5,6 MILLIONS 338 423
La demande d'open source continue à exploser.
Augmentation des téléchargements en un an
2020 - 2021
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % ,NET Python JavaScript Java 71 % d'augmentation 267 À 457 MILLIARDS Augmentation de 50 % 1 000 À 1 500 MILLIARDS Augmentation de 78 % 44 À 78 MILLIARDS d'augmentationen glissement annuel Pourcentage augmentation de 92 % 66 À 127 MILLIARDS
La demande d'open source continue à exploser.

En 2021, les développeurs du monde entier demanderont plus de 2 200 milliards de paquets open source, ce qui représente une hausse de 73 % des téléchargements de composants open source par des développeurs en un an. Malgré le volume croissant de téléchargements, le pourcentage de composants disponibles utilisés dans les applications de production est incroyablement faible.

Les vulnérabilités sont plus courantes dans les projets populaires.

Si on considère les versions de projet OSS qui figurent parmi les 10 % les plus populaires, on s'aperçoit que, en moyenne, 29 % contiennent des vulnérabilités connues. À l'inverse, sur les 90 % restants, seulement 6,5 % contiennent des vulnérabilités connues. Ces statistiques combinées indiquent que la grande majorité des recherches en matière de sécurité (whitehat et blackhat) se concentre sur la recherche et la résolution (ou l'exploitation) de vulnérabilités dans les projets les plus utilisés.

Comparaison entre la densité de déploiements vulnérables et la popularité

Java (Maven)

0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Vulnérables Non vulnérables Pourcentage de versions vulnérables par Groupe de popularité x % Popularité 10 % supérieurs 10 % inférieurs 7 % 7 % 3 % 4 % 6 % 2 % 3 % 6 % 3 % 26 %

JavaScript (npm)

0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Vulnérable Non vulnérable Popularité 10 % supérieurs 10 % inférieurs 39 % 17 % 9 % 8 % 6 % 6 % 7 % 7 % 7 % 4 %

Python (pypi)

0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Vulnérables Non vulnérables Popularité 10 % supérieurs 10 % inférieurs 38 % 14 % 12 % 3 % 6 % 5 % 11 % 9 % 7 % 5 %

.NET (Nuget)

Vulnérables Non vulnérables 0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Popularité 10 % supérieurs 10 % inférieurs 16 % 6 % 6 % 6 % 6 % 6 % 8 % 7 % 5 % 4 %
Statistiques relatives à la chaîne logistique logicielle en 2021
Écosystème
Total
des projets
Total des
versions de projets
Demandes
de téléchargement
Augmentation du nombre de téléchargements d'une année sur l'autre
Utilisation des
projets de l'écosystème
Densité de vulnérabilités pour les versions utilisées :
10 % les plus populaires
Densité de vulnérabilités pour les versions utilisées :
90 % les moins populaires
Java
JavaScript
Python
.Net
Totaux/moyennes
431K
1.9M
336K
338K
3M
7.3M
21M
3M
5.6M
37M
457B
1.5T
127B
78B
2.2T
71%
50%
92%
78%
73%
15%
2%
4%
2%
6%
23%
39%
38%
15%
29%
4%
8%
8%
6%
6.5%
Attaques médiatisées contre les chaînes logistiques logicielles
Déc. 2020 - Juil. 2021
DÉCEMBRE 2020
SolarWinds

Des pirates ont eu accès à l'infrastructure de développement de SolarWinds et ont injecté du code malveillant dans les binaires de mise à jour d'Orion. 18 000 clients ont automatiquement téléchargé des mises à jour contaminées, ce qui a eu pour effet d'installer des portes dérobées dans leur système et de permettre aux pirates d'exploiter des réseaux privés à leur guise.

FÉVRIER 2021
Namespace Confusion

Trois jours après l'annonce du piratage de 35 grandes entreprises technologiques par un chercheur éthique dans le cadre d'une attaque inédite de la chaîne logistique, plus de 300 attaques malveillantes d'imitateurs ont été observées. En un mois, plus de 10 000 imitateurs ont ainsi infiltré plusieurs écosystèmes, dont le npm, grâce à une attaque de confusion de l'espace de noms.

AVRIL 2021
Codecov

Un pirate a réussi à obtenir un identifiant grâce à une erreur dans la façon dont Codecov créait des images Docker. Cet identifiant a permis de modifier le script bash de téléchargement de Codecov, qui a été utilisé soit directement par ses clients, soit via les autres téléchargeurs de Codecov, comme leur Action GitHub. Le pirate a utilisé ce script modifié pour voler des identifiants dans les environnements CI de clients qui l'utilisent.

MAI 2021
Microsoft's WinGet

Le week-end suivant son lancement, le registre de logiciels de Winget a été inondé de pull requests pour des applications qui étaient soit en double, soit malformées. Des paquets en double récemment ajoutés étaient corrompus et ont écrasé les paquets existants, soulevant de grandes inquiétudes concernant l'intégrité de l'écosystème Winget.

JUILLET 2021
Kaseya

Un groupe de ransomware a découvert et exploité une vulnérabilité zero day dans une plateforme de surveillance et de gestion à distance utilisée par des dizaines de fournisseurs de services de sécurité gérés. Étant donné que ces derniers ont des milliers de clients en aval, les pirates ont pu lancer une attaque de ransomware qui a fait 1 500 victimes.

Les attaques contre les chaînes logistiques logicielles ont augmenté de 650 %

Les membres de la communauté open source mondiale doivent faire face à une menace inédite et en pleine expansion provenant non pas de malfaiteurs à l'affût de vulnérabilités connues, mais de pirates virulents qui altèrent intentionnellement les projets open source pour infiltrer la chaîne logistique commerciale.

Entre février 2015 et juin 2019, 216 attaques ciblant les chaînes logistiques logicielles ont ainsi été enregistrées. Au cours des mois qui ont suivi cette période, entre juillet 2019 et mai 2020, le nombre d'attaques est cette fois passé à 929. Pire encore, au cours de l'année passée seulement, le nombre de ces attaques a été porté à 12 000, ce qui représente une augmentation de 650 %.

Attaques de nouvelle génération contre les chaînes logistiques logicielles (2015-2020)

Confusion de dépendances, typosquattage et injection de code malveillant

2020 2019 2018 2017 2015 2021 0 2 000 4 000 6 000 8 000 10 000 12 000 AUGMENTATION DE 650 % EN GLISSEMENTANNUEL
Attaques médiatisées contre les chaînes logistiques logicielles
Déc. 2020 - Juil. 2021
DÉCEMBRE 2020
SolarWinds

Des pirates ont eu accès à l'infrastructure de développement de SolarWinds et ont injecté du code malveillant dans les binaires de mise à jour d'Orion. 18 000 clients ont automatiquement téléchargé des mises à jour contaminées, ce qui a eu pour effet d'installer des portes dérobées dans leur système et de permettre aux pirates d'exploiter des réseaux privés à leur guise.

FÉVRIER 2021
Namespace Confusion

Trois jours après l'annonce du piratage de 35 grandes entreprises technologiques par un chercheur éthique dans le cadre d'une attaque inédite de la chaîne logistique, plus de 300 attaques malveillantes d'imitateurs ont été observées. En un mois, plus de 10 000 imitateurs ont ainsi infiltré plusieurs écosystèmes, dont le npm, grâce à une attaque de confusion de l'espace de noms.

AVRIL 2021
Codecov

Un pirate a réussi à obtenir un identifiant grâce à une erreur dans la façon dont Codecov créait des images Docker. Cet identifiant a permis de modifier le script bash de téléchargement de Codecov, qui a été utilisé soit directement par ses clients, soit via les autres téléchargeurs de Codecov, comme leur Action GitHub. Le pirate a utilisé ce script modifié pour voler des identifiants dans les environnements CI de clients qui l'utilisent.

MAI 2021
Microsoft's WinGet

Le week-end suivant son lancement, le registre de logiciels de Winget a été inondé de pull requests pour des applications qui étaient soit en double, soit malformées. Des paquets en double récemment ajoutés étaient corrompus et ont écrasé les paquets existants, soulevant de grandes inquiétudes concernant l'intégrité de l'écosystème Winget.

JUILLET 2021
Kaseya

Un groupe de ransomware a découvert et exploité une vulnérabilité zero day dans une plateforme de surveillance et de gestion à distance utilisée par des dizaines de fournisseurs de services de sécurité gérés. Étant donné que ces derniers ont des milliers de clients en aval, les pirates ont pu lancer une attaque de ransomware qui a fait 1 500 victimes.

Recommandation pratique

Pour accélérer le rythme de l'innovation numérique sans sacrifier la qualité ou la sécurité, les responsables de l'ingénierie et de la gestion des risques doivent comprendre la dynamique de l'offre, de la demande et des risques associés aux écosystèmes open source tiers. De plus, ils doivent définir des politiques open source et les appliquer automatiquement à toutes les phases de la chaîne logistique logicielle.

2

Comprendre la notion de référence pour les projets open source

Certains projets open source sont sans aucun doute meilleurs que d'autres. Mais comment le savoir ? Cette année, nous avons étudié trois méthodes différentes pour identifier ces projets open source de référence : le délai moyen de mise à jour Sonatype (MTTU), la criticité OpenSSF et le Sourcerank de Libraries.io. Nous avons constaté que le MTTU combiné à la criticité OpenSSF est fortement associé à des résultats de projet de référence en matière de sécurité et de productivité de développement.

Indicateurs à utiliser pour évaluer la qualité relative d'un projet OSS
  • MTTU Sonatype
  • Criticité OpenSSF
  • Sourcerank Libraries.io

Le délai moyen de mise à jour Sonatype offre une indication de la qualité d'un projet sur la base de sa réactivité aux mises à jour de dépendances. Plus le délai est faible, mieux c'est. Les composants qui réagissent systématiquement et rapidement aux mises à jour des dépendances ont un MTTU plus 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é.

La criticité OpenSSF mesure la communauté, l'utilisation et l'activité d'un projet. Cette information est représentée par un score qui vise à mesurer le degré de criticité du projet dans l'écosystème open source.

Le Sourcerank de Libraries.IO vise à mesurer la qualité des logiciels, en prenant principalement en compte la documentation, la maturité et la communauté du projet. Cet indicateur est calculé à travers un certain nombre de réponses oui/non, telles que « Le projet a-t-il plus de six mois ? » et un ensemble de questions numériques, telles que « Combien d'étoiles le projet possède-t-il ? » Ces réponses sont rassemblées dans un score unique, les questions oui/non ajoutant ou soustrayant un nombre fixe de « points » et les questions numériques étant converties en points à l'aide d'une formule, par ex. « log(num_stars)/2 ». Actuellement, le nombre maximal de points est d'environ 30.

Plus le MTTU est faible, mieux c'est.

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.

Développer pour en savoir plus.
MTTU-update-2
Les MTTU s'améliorent au fil du temps.

Outre la hausse du nombre de projets, nous pouvons observer une tendance marquée vers l'accélération des MTTU. En 2011, le MTTU moyen à l'échelle de tous les projets était de 371 jours. En 2014, il avait été réduit à 302 jours puis, en 2018, à 158 jours. En 2021, au 1er août, le MTTU moyen était de 28 jours, soit moins de la moitié des 73 jours constatés en 2020.

Densité Délai moyen de mise à jour (en jours) 10 − 2 10 − 1 10 0 10 1 10 2 10 3 10 4 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 (projection) 2021 2020 2019 2017 2016 2018 2015 2014 2013 2012 2011 0.00 0.02 0.04 0.06 0.08 0.10 0.12 0.14
Le MTTU est fortement corrélé au MTTR.
MTTU_MTTRchart

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.

Développer pour en savoir plus.
Le MTTU est fortement corrélé au MTTR.

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.

Recommandations pratiques

Le choix de projets open source de grande qualité devrait être considéré comme une importante décision stratégique pour les entreprises de développement logiciel.

Afin d'éviter les dépendances obsolètes et de minimiser les risques de sécurité liés à l'open source tiers, les équipes d'ingénierie logicielle doivent activement opter pour des projets qui présentent systématiquement un faible délai moyen de mise à jour et des scores de criticité OpenSSF élevés.

3

Comment vos pairs gèrent-ils les dépendances open source ?

Cette année, nous avons passé en revue 4 millions de décisions de gestion des dépendances issues du monde réel, à l'échelle de 100 000 applications. Les enseignements que nous avons pu en tirer et qui sont présentés ci-dessous sont très instructifs.

Malgré le volume croissant de téléchargements, le pourcentage de composants disponibles observés dans les applications de production est incroyablement faible.

En moyenne, les applications Java de production en entreprise utilisent 10 % des composants open source disponibles et les équipes d'ingénierie commerciale mettent à jour activement seulement 25 % des composants utilisés.

Projets actifs dans Maven Central Repository
430 000 projets dans Maven projets présents dans 100 000 applications 40 000 dans 100 000 applications projets ont été activement mis à jour au cours de l'année précédente 10 000
69 % des décisions de gestion des dépendances ne sont pas optimales.
5 groupes de décisions de migration
Décisions optimales Version optimale choisie 31 % Décisions imparfaites Version subjectivement déficiente choisie 64 % Décisions dangereuses Version objectivement déficiente choisie 3 % Décisions risquées Version préliminaire choisie 1 % Impasses Aucun bon choix disponible 1 %
69 % des décisions de gestion des dépendances ne sont pas optimales.

Actuellement, une application contient en moyenne 128 dépendances open source, et le projet open source moyen publie 10 versions par an. Cette réalité, associée au fait que quelques projets particulièrement actifs publient plus de 8 000 versions par an, crée une situation dans laquelle les développeurs doivent constamment décider quand mettre à jour les dépendances tierces au sein de leurs applications, mais aussi quand ne pas le faire. Compte tenu de ces circonstances, les chercheurs de Sonatype ont entrepris de répondre à la question suivante : les développeurs prennent-ils des décisions efficaces en matière de gestion des dépendances ? Nous avons étudié 100 000 applications et analysé plus de 4 000 000 migrations de composants (mises à niveau) et avons constaté que 69 % de ces décisions n'étaient pas optimales.

Malgré ces prises de décision non structurées, toutes ces actions ne sont pas dénuées de sagesse.

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.

Comportements de migration associés à org.springframework:spring-core9 août 2020 – 1er août 2021
1

La version la plus récente de spring-core (5.3.x) sort environ toutes les 4 semaines.

2

Le projet gère activement ces 2 versions. Une teinte plus foncée indique que la majorité de la communauté utilise ces versions.

3

Le projet ne prend plus activement en charge ces versions. Les équipes devraient éviter ces versions obsolètes.

4

Les retardataires continuent à effectuer des mises à jour avec des versions plus anciennes, non prises en charge, voire vulnérables.

5

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.

6

La communauté évite généralement les versions 0 et préliminaires.

8 règles pour une mise à niveau vers la version optimale
Éviter les choix objectivement mauvais
Vector

Ne choisissez pas une version alpha, bêta, jalon, candidat à la publication, etc.

Vector (1)

Ne faites pas de mise à niveau vers une version vulnérable.

Vector (2)

Passez à une version moins risquée si la version que vous utilisez est vulnérable.

Vector (3)

Lorsqu'un composant est publié deux fois en très peu de temps, choisissez la version ultérieure.

Éviter les choix subjectivement mauvais
Vector (4)

Choose a migration path (from version to version) others have chosen.

Vector (5)

Choisissez une version qui minimise les modifications de code avec rupture.

Vector (6)

Choisissez la version utilisée par la majorité de la population.

Vector (7)

Si aucune de ces options ne s'applique, choisissez la version la plus récente.

Le respect de ces règles entraîne des mises à niveau optimales.
Gagnez du temps et de l'argent.

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.

Les avantages d'une automatisation intelligente des équipes de développement
Stratégies pour une gestion optimale des dépendances : un pas derrière l'avant-garde.

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.

Stratégies de gestion des dépendances
Équipes dans la confusion

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.

Lire la suite VOIR MOINS
Équipes positionnées un pas derrière l'avant-garde

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é.

Lire la suite VOIR MOINS
Équipes à l'avant-garde

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.

Lire la suite VOIR MOINS
Recommandations pratiques

Les équipes d'ingénierie logicielle doivent s'efforcer d'homogénéiser les décisions relatives à la gestion des dépendances.

Les responsables de l'ingénierie doivent optimiser les informations mises à la disposition des développeurs pour gagner du temps et de l'argent.

Ils doivent adopter des outils pour automatiser les décisions intelligentes en matière de gestion des dépendances.

4

Enquête de maturité de la chaîne logistique logicielle

Pour le rapport de cette année, nous avons interrogé 702 professionnels de l'ingénierie sur leurs pratiques de gestion de la chaîne logistique logicielle. Les questions portaient notamment sur les approches et les philosophies d'utilisation des composants open source, le design organisationnel, la gouvernance, les processus d'approbation et les outils utilisés.

Maturité de la chaîne logistique logicielle : entre perception et réalité

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.

Score de maturité de la chaîne logistique logicielle par thème
5e, 50e et 95e centile
1
La majorité des participants ont une approche « Ad Hoc » de la gestion de la chaîne logistique logicielle.
2
Les deux seuls thèmes pour lesquels les sondés ont démontré un haut niveau de maturité sont l'inventaire et la correction.
3
En comparant les réponses à l'enquête à l'analyse objective effectuée, nous constatons un décalage entre ce qui se passe réellement et ce que les gens pensent : 70 % des mesures correctives pourraient en fait être plus optimales.
Recommandation pratique

L'enquête laisse penser que les participants se sont eux-mêmes convaincus qu'ils faisaient du bon travail dans des domaines où, objectivement, ce n'était pas le cas. Ce constat doit servir de rappel et invite à être plus attentif à la situation perçue de votre entreprise et ce qui se passe réellement, pour comparer en continu les performances de votre flux de travail et vos systèmes aux résultats souhaités.

5

Émergence de réglementations et de normes relatives aux chaînes logistiques logicielles

Suite à plusieurs attaques en 2020 ciblant des infrastructures cruciales, les gouvernements du monde entier ont commencé à respecter les réglementations et normes visant à améliorer la sécurité et la santé de la chaîne logistique logicielle.

American Flag
The United States

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.

UK Flag
The United Kingdom

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.

Germany Flag
Allemagne

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 ».

European Union Flag
European Union

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.

Recommandation pratique

Alors que les gouvernements reconnaissent enfin les risques associés aux chaînes logistiques logicielles non gérées, ils s'efforcent maintenant d'aligner le secteur des logiciels avec les autres secteurs de fabrication. Soyez attentif à ce qui se passe sur le plan législatif au sein de votre marché, participez aux débats publics et soyez prêt à modifier vos pratiques de développement en conséquence.

Approfondir et télécharger le rapport complet

Les ingénieurs sont amenés à prendre toutes sortes de décisions numériques à chaque phase de la chaîne de valeur DevSecOps, décisions auxquelles ils n'avaient pas à réfléchir il y a un an. Comprendre comment optimiser ces décisions et comment elles affectent la chaîne logistique logicielle à plus grande échelle est primordial pour la réussite d'une entreprise.

Consultez le rapport complet pour obtenir plus d'informations, d'analyses et de conseils sur le développement de chaînes logistiques logicielles optimales.