La plupart des entreprises sont mues par le désir d’innover plus vite que leurs concurrents et de gagner des parts de marché. La plupart d’entre elles commencent à comprendre que gagner la course à l’innovation implique de mettre les bouchées doubles sur la qualité, la sécurité et la maintenabilité.
En outre, la multiplication des réglementations gouvernementales, l’évolution des normes sectorielles et la part croissante accordée aux licences open source transforment la façon de penser le développement logiciel. Dans cette section, nous allons aborder point par point certains de ces facteurs externes qui affectent la gestion de la chaîne logistique logicielle.
Il y a près de 9 ans, le monde était témoin de la première vulnérabilité Apache Struts majeure. Apache avait alors pris ses responsabilités et rendu publique la vulnérabilité tout en fournissant une nouvelle version pour résoudre le problème. Bien qu’Apache ait fait de son mieux pour alerter le public et empêcher les attaques de se produire, la plupart des organisations ne prêtaient aucune attention à ces avertissements ou ne réagissaient pas assez vite, ce qui a laissé le champ libre à de nombreuses attaques. Pour le dire sans ambages, les pirates informatiques profitent grassement de l’inattention des entreprises et de leur incapacité à réagir rapidement quand des vulnérabilités sont divulguées.
Depuis, la communauté a vu se produire Shellshock, Heartbleed, Commons Collection et, plus récemment, l’attaque de Log4j et de Spring4Shell. Tous ces événements ont suivi le même schéma : une attaque généralisée qui survient après la divulgation.
En réalité, ces attaques ne sont pas chose rare, et il faut rappeler que 29 % des composants open source couramment utilisés contiennent une vulnérabilité connue.
Source : Rapport de Sonatype sur l’état de la chaîne logistique logicielle en 2021Pour parler de la situation actuelle, de nombreux acteurs malveillants créent maintenant leurs propres opportunités d’attaque.
Cette nouvelle forme d’attaque sur nos chaînes logistiques logicielles, dans laquelle les identifiants de projets open source sont compromis et des segments de code malveillant sont volontairement injectés dans les bibliothèques open source, permet aux pirates d’empoisonner ce qui se trouve à la source de la chaîne. Le code vulnérable est téléchargé de manière continue par des millions de développeurs qui, à leur tour, « polluent » involontairement leurs applications au bénéfice direct de ces acteurs malveillants.
Ces types d’attaques de chaînes logistiques logicielles se développent à un rythme alarmant : 2021 a connu une augmentation de 650 % du nombre de cyberattaques visant des fournisseurs open source. Dans ses analyses proactives, Sonatype a constaté plus de 63 000 tentatives de modification de composants.
Source :Rapport de Sonatype sur l’état de la chaîne logistique logicielle en 2021Trois aspects rendent ces attaques uniques dans cet espace :
Traditionnellement, les attaques de logiciels se concentrent soit sur les utilisateurs soit sur leur destination. Parmi les tactiques courantes des acteurs malveillants, on trouve le fait d’inciter les utilisateurs à ouvrir des logiciels malveillants ou à partager leurs identifiants, ou le fait d’utiliser les vulnérabilités logicielles publiées pour attaquer les serveurs qui n’ont pas été mis à jour avec un correctif. Ces tactiques sont la plupart du temps considérées comme agissant « en aval » dans la chaîne logistique logicielle, car elles ne sont pas liées au processus de développement.
Plus récemment cependant, des attaques sophistiquées, comme l’incident SolarWinds de 2019 , agissaient « en amont », au niveau du développement logiciel. Ces efforts visent à s’immiscer dans des projets open source collaboratifs pour polluer le code source avec des logiciels malveillants, qui sont ensuite distribués en tant que composants des logiciels que nous utilisons quotidiennement.
Comme exemples d’attaques courantes de la chaîne logistique logicielle, citons notamment :
Toutes ces attaques peuvent entraîner une perte de données, l’installation de cryptomineurs ou pire encore. En outre, plus un paquet est compromis tôt dans la chaîne logistique logicielle, plus nombreuses sont les cibles qu’il peut atteindre.
Si la cadence globale de développement des logiciels a augmenté, les attaques ont malheureusement suivi la tendance. Il y a dix ans, les entreprises disposaient d’environ un mois pour réagir aux vulnérabilités importantes de la chaîne logistique avant qu’une attaque ait lieu, mais ce délai est en train de se contracter. Pour la vulnérabilité Struts de 2017 (qui a notamment entraîné la violation d’Equifax, largement médiatisée), le délai était de 5 jours.
Plus tard, à la fin de l’année 2021, le délai est tombé à deux jours seulement pour Log4j :
D’après « IBM X-Force / Analysis by Gartner Research » (septembre 2016)
Résultat : autrefois avantages concurrentiels, les processus de développement interne accélérés sont devenus un impératif de sécurité. Et la tendance est claire : les entreprises doivent mettre en œuvre des améliorations continues pour réagir de façon efficace aux vulnérabilités.
Il existe de nombreux moyens par lesquels les entreprises peuvent minimiser les dommages causés par une violation, cependant, une mauvaise correction peut mener directement aux tribunaux. À la suite de l’épisode Log4j, les entreprises américaines ont été informées qu’elles seraient dorénavant passibles de poursuites de la Federal Trade Commission s’il était établi qu’elles n’avaient pas fait le nécessaire pour améliorer leurs systèmes.
Tout cela montre qu’une bonne compréhension de la chaîne logistique logicielle ne concerne pas simplement les développeurs : elle est liée à des intérêts économiques et même nationaux.
Les logiciels, qui s’implantent dans un nombre toujours croissant d’industries, n’ont aucune norme unique de conformité capable de garantir l’intégrité de la chaîne logistique logicielle. La plupart des normes et des exigences de conformité sont définies par les acteurs industriels eux-mêmes, et ils ne concernent souvent que leur activité.
Par exemple, la norme PCI-DSS concerne les entreprises qui traitent les paiements par carte de crédit ; le secteur de la santé quant à lui est soumis à la loi HIPPA. Les entreprises implantées en Europe doivent se soumettre au RGPD, tandis que la FISMA audite les sources de données fédérales américaines.
Cette année a vu naître le tout premier mandat fédéral destiné à sécuriser les composants logiciels critiques avec le Cybersecurity Executive Order (en français « Décret présidentiel pour la cybersécurité ») du président Biden. Également évoquées dans l’introduction, ces nouvelles règles concernent directement la chaîne logistique logicielle et la transparence des logiciels. Le gouvernement fédéral américain étant un grand utilisateur de logiciels, ce décret pourrait avoir des effets considérables, mais il ne concerne pour l’instant que ceux qui créent des logiciels destinés à être vendus aux services d’État.
Une bonne compréhension de la chaîne logistique logicielle ne concerne pas simplement les développeurs : elle est liée à des intérêts économiques et même nationaux.
En ce qui concerne les normes de conformité, le logiciel pourrait devenir victime de son propre succès : la diversité des effets qu’ont les logiciels sur nos vies est exacerbée par la législation au niveau de l’État, des territoires, fédéral et international. Ce faisant, le développement lui-même continue d’évoluer. Et nous ne pouvons que recommander de poursuivre les recherches dans votre propre secteur afin de trouver des formations continues, des bonnes pratiques, des politiques efficaces et des techniques de suivi des processus.
Prêt à essayer les produits Nexus ?
