Trois tendances qui façonnent aujourd’hui la sécurité de la chaîne logistique logicielle

La création de logiciels ressemble toujours à une chaîne de montage : les développeurs puisent des ressources sur le Web pour créer des applications. Si les ressources tierces jouent depuis longtemps un rôle essentiel dans le développement logiciel, la manière dont les équipes de développement utilisent ces composants externes a changé. Les développeurs intègrent à leurs projets une plus grande variété de ressources tierces et, grâce aux assistants de codage IA, ils peuvent le faire beaucoup plus rapidement, directement dans leur code propriétaire.

Face à ces évolutions du développement logiciel, les organismes de réglementation comme les entreprises prennent conscience des risques liés à bon nombre de ces pratiques de chaîne logistique logicielle et continuent de réclamer une réglementation des logiciels tiers.

Quelles conséquences ces réalités ont-elles pour les organisations de développement logiciel ? Plus que jamais, les entreprises qui développent des applications doivent miser sur des pratiques de sécurité proactives : créer des nomenclatures logicielles (SBOM) pouvant être testées, renforcer la sécurité du code en amont pour tenir compte du code généré par l’IA, fournir aux développeurs des outils concrets pour les aider à choisir des composants tiers sécurisés et s’appuyer sur le contexte métier pour hiérarchiser correctement les risques liés à la chaîne logistique.

Pour mieux comprendre ces pratiques proactives, examinons trois grandes tendances de la chaîne logistique et leurs effets sur le développement logiciel :

Des réglementations de plus en plus strictes concernant les SBOM

Les SBOM sont au cœur de nombreuses exigences de conformité et de nombreux contrats fournisseurs récents. Les organismes des secteurs public et privé renforcent leurs exigences en matière de SBOM, car les inquiétudes grandissent face aux composants et dépendances vulnérables ou malveillants. Beaucoup de ces réglementations soulignent l’importance de mettre régulièrement à jour les SBOM à mesure que de nouvelles ressources tierces intègrent votre écosystème logiciel.

Ce que ces réglementations impliquent pour les équipes aujourd’hui

La mise à jour régulière des SBOM deviendra bientôt un facteur déterminant de la réussite de votre entreprise. Comme de plus en plus de contrats publics et privés les exigent, vous devrez produire une SBOM qui puisse être testée à nouveau pour votre entreprise, afin de prendre en compte les nouvelles menaces et les changements qui surviennent au fil du temps dans votre écosystème. Les SBOM sont également importantes pour la consommation de logiciels, car elles assurent la transparence des logiciels des services que vous utilisez.

Code généré par l’IA

Les assistants de codage IA sont rapidement devenus la norme pour les équipes de développement logiciel. Cependant, l’introduction de code propriétaire généré par l’IA a plusieurs conséquences pour la sécurité de la chaîne logistique logicielle. Les équipes de sécurité doivent renforcer les mesures fondamentales de sécurité du code (par exemple, les tests statiques de sécurité des applications) et adapter leurs pratiques et outils existants à la vitesse à laquelle le code généré par l’IA est ajouté aux dépôts.

Ce que la popularité des assistants de codage IA implique pour les équipes

Les assistants de codage IA renforcent les attentes en matière de rapidité et d’efficacité dans toutes les équipes de développement. Les développeurs font généralement davantage confiance au code généré par l’IA qu’au code écrit par des humains et espèrent aller encore plus vite, ce qui laisse peu de place aux pratiques de sécurité chronophages. Par conséquent, les équipes de sécurité qui s’en tenaient à des pratiques de sécurité du code traditionnelles — comme tester le code propriétaire plus tard dans le cycle de développement logiciel ou obliger les développeurs à passer d’un outil à l’autre pour tester et sécuriser leur code — ne peuvent plus se le permettre. Elles doivent envisager de renforcer la sécurité en amont en intégrant des outils de sécurité aux workflows de développement.

Une menace en constante évolution

Parallèlement, le paysage des menaces a considérablement évolué ces dernières années, les menaces liées à l’IA faisant peser de nouveaux risques sur les entreprises d’aujourd’hui. En fait, le projet OWASP Machine Learning Security Top Ten classe les attaques contre la chaîne logistique de l’IA parmi les menaces majeures pour les LLM. En compromettant des projets entiers de machine learning, les attaquants peuvent démultiplier leurs efforts et accéder à davantage d’actifs que s’ils compromettaient une bibliothèque statique.

Ce que l’évolution du paysage des menaces implique pour les équipes

Les équipes doivent trouver comment choisir dès le départ les ressources tierces les plus sûres. Elles doivent ensuite vérifier régulièrement les bibliothèques existantes afin de s’assurer qu’aucune n’a été compromise. Il est également essentiel de hiérarchiser les vulnérabilités tierces selon leur criticité métier. Votre équipe peut ainsi se concentrer en priorité sur la correction des failles touchant les actifs critiques pour l’entreprise, puis poursuivre avec les autres.

Répondre aux tendances en matière de sécurité de la chaîne logistique

Pour suivre l’évolution de ces tendances, il faut avant tout adopter une approche proactive. L’objectif est d’anticiper les risques possibles — pour votre entreprise ou pour le processus de sécurité lui-même — et d’y remédier le plus tôt possible. Voici quelques questions pour amorcer cette transition vers une approche proactive :

• Si un acteur malveillant parvenait à s’introduire dans une application, quels domaines métier, applications ou bibliothèques serait-il le plus grave de voir compromis ? Lesquels seraient moins préoccupants ? Ces questions de contexte peuvent vous aider à déterminer quels domaines critiques pour l’entreprise protéger en priorité et lesquels, moins risqués, peuvent être relégués en bas de votre liste. Pour obtenir une vision aussi détaillée des risques, il faut aller plus loin que le simple tri des vulnérabilités selon leur score CVSS ou leur accessibilité.

• Combien de changements de contexte demandez-vous à vos équipes de développement lorsqu’elles sécurisent du code propriétaire ou des composants tiers ? Doivent-elles quitter leur environnement de codage pour corriger les problèmes ? Si c’est le cas, vous leur en demandez sans doute trop, surtout qu’elles vont plus vite grâce aux assistants de codage IA.

• Quels garde-fous automatisés avez-vous mis en place pour empêcher dès le départ l’intégration de composants tiers non sécurisés ou de problèmes de licences dans vos dépôts ? Il est judicieux de constituer des listes de ressources tierces sûres pour vos développeurs, qu’il s’agisse d’une base de données de recommandations d’images de base ou d’un moyen de sélectionner des packages de qualité adaptés à des besoins spécifiques. Vous pouvez aussi intégrer l’application de vos directives aux processus et pipelines de création et de livraison logicielle.

Pour approfondir les défis actuels de la sécurité de la chaîne logistique et découvrir d’autres conseils pratiques, consultez notre ebook « Sécuriser les chaînes logistiques logicielles d’aujourd’hui ».