Support technique
Documentation
Connexion
Nous contacter
Les risques d'une chaîne d'approvisionnement en logiciels libres
Artem Karasev
13 juin 2023 - Responsable marketing produit
Les logiciels libres sont devenus un élément essentiel de l'écosystème du développement logiciel. Ils ont été largement adoptés par les développeurs du monde entier, en raison de leurs avantages, tels que la rentabilité, l'adaptabilité et le soutien de la communauté.
L'accès à des composants logiciels préexistants permet aux entreprises d'accélérer leurs processus de développement et de mettre leurs produits sur le marché beaucoup plus rapidement. Toutefois, l'utilisation croissante de logiciels libres dans le développement d'applications pose des problèmes de sécurité de plus en plus importants. Cet article de blog traite des défis liés à la sécurisation d'une chaîne d'approvisionnement en logiciels libres et de la manière de les relever.
L'endroit idéal pour les attaquants
Alors que l'utilisation des logiciels libres ne cesse de croître, les groupes de menace ont la possibilité d'exploiter la chaîne d'approvisionnement en logiciels pour accéder à un large éventail de cibles qui en dépendent.
Les cybercriminels savent que de nombreuses organisations ne sont pas conscientes des logiciels libres utilisés dans leurs systèmes et des vulnérabilités présentes dans ces composants. Au lieu de passer beaucoup de temps à essayer de pirater le code personnalisé d'une organisation, les pirates utilisent des exploits accessibles au public pour cibler un large éventail d'organisations et trouver des systèmes avec des composants open-source vulnérables à exploiter.
En outre, l'une des principales raisons pour lesquelles les attaques contre les chaînes d'approvisionnement en logiciels libres sont si fructueuses est l'immense complexité des graphes de dépendance.
L'effet Jenga
Chaque paquetage open-source a sa propre chaîne d'approvisionnement et peut s'appuyer sur plusieurs bibliothèques open-source de tiers. Ces bibliothèques tierces dépendent souvent d'autres bibliothèques, ce qui crée une chaîne d'interdépendances extrêmement complexe.
Étant donné que les bibliothèques populaires sont largement utilisées par de nombreux logiciels libres, une seule vulnérabilité dans l'une d'entre elles peut faire des ravages dans l'ensemble de l'écosystème. Nous l'avons déjà constaté à maintes reprises : d'une vulnérabilité dans la bibliothèque de journalisation gratuite Log4j, une bibliothèque de journalisation libre à l'un des cas les plus récents, lorsqu'un développeur open-source a introduit un code de rupture dans son paquetage npm très populaire couleurs.
Source : https://xkcd.com/2347/
On ne peut pas protéger ce que l'on ne voit pas
Dans un scénario parfait, les équipes d'ingénieurs tiendraient à jour une documentation complète sur les logiciels libres utilisés au sein de l'organisation - également connue sous le nom de nomenclature logicielle. Elles mettraient à jour cette documentation chaque fois qu'une nouvelle dépendance serait ajoutée, ce qui permettrait d'identifier facilement où et si une bibliothèque particulière, telle que log4j, est utilisée.
Cette documentation permettrait également de découvrir à temps les paquets non maintenus, car ils peuvent présenter des risques supplémentaires pour la sécurité. Cependant, il faut beaucoup de travail aux développeurs pour s'entraîner à documenter les composants logiciels de manière cohérente. Dans le même temps, les équipes de sécurité de nombreuses organisations ont besoin de plus de visibilité sur les dépendances utilisées par leur entreprise.
Rater sa mise sur le marché
Compte tenu de la complexité des chaînes de dépendance des logiciels libres, il est pratiquement impossible de se tenir au courant des dernières corrections de vulnérabilités et de stimuler l'innovation en même temps.
Pour garantir la sécurité et la conformité légale, les entreprises ont commencé à mettre en œuvre des processus d'approbation formels pour l'introduction de nouveaux composants open-source. Dans certains cas, l'approbation de nouveaux composants peut prendre jusqu'à un mois ou plus.
Dans le même temps, les responsables de produits, qui doivent soigneusement équilibrer leurs ressources de développement pour rester compétitifs, s'efforcent de donner la priorité aux nouvelles fonctionnalités par rapport au nombre croissant de vulnérabilités affectant leurs applications. Tout cela peut entraîner un retard important dans le développement et, par conséquent, dans le délai de mise sur le marché, qui peut s'avérer critique et conduire à des pertes d'opportunités dans le meilleur des cas.
La voie à suivre
L'une des solutions potentielles aux problèmes que rencontrent les organisations en matière de sécurité de la chaîne d'approvisionnement des logiciels libres est la gestion centralisée d'un référentiel de composants libres pré-approuvés et sécurisés en permanence. Vous pouvez l'établir vous-même ou vous associer à un fournisseur de confiance qui l'établira et le gérera pour vous.
L'accès à un tel référentiel vous permettra de :
- Réduire les risques de sécurité en s'assurant que vos dépendances sont exemptes de vulnérabilités et de codes malveillants.
- Maîtrisez votre graphe de dépendance grâce à la nomenclature logicielle fournie pour chaque paquet.
- Respectez votre politique de correctifs et les exigences réglementaires en établissant des accords de niveau de service fiables pour les correctifs de sécurité.
- Accélérer la mise sur le marché en éliminant les processus d'approbation excessifs et en réduisant la dette technique
Un référentiel unique et fiable de paquets open-source approuvés vous permettra de continuer à innover tout en maintenant automatiquement la sécurité de vos applications. Si vous souhaitez sécuriser votre chaîne d'approvisionnement Java, accédez dès maintenant à notre référentiel Java gratuit.
