Rapport PulseMeter : les chaînes d’approvisionnement logicielles

Les souvenirs encore récents d’incidents de sécurité comme Log4Shell et l’attaque SolarWinds rappellent aux développeurs que les attaques visant la chaîne d’approvisionnement logicielle sont une préoccupation majeure. 

Les organisations peuvent prendre des mesures pour détecter et prévenir les attaques malveillantes contre la chaîne d’approvisionnement, notamment en établissant une nomenclature logicielle (SBOM), récemment rendue obligatoire par le gouvernement fédéral américain. Les SBOM détaillent les composants intégrés au code afin que les utilisateurs de ces applications et packages logiciels puissent repérer les risques d’exposition à des vulnérabilités existantes, mais pas encore découvertes. 

Fin 2022, Techstrong Research a interrogé notre communauté de lecteurs spécialisés en DevOps, cloud natif, cybersécurité et transformation numérique pour prendre le pouls sur les SBOM. Voici les résultats :

• Les attaques contre la chaîne d’approvisionnement logicielle préoccupent tout le monde.

• De nombreuses organisations utilisent déjà des SBOM.

• Les SBOM ne suffisent pas à elles seules.

Les attaques contre la chaîne d’approvisionnement logicielle préoccupent tout le monde

L’étude révèle que plus de 78 % des personnes interrogées sont quelque peu préoccupées par les attaques contre la chaîne d’approvisionnement logicielle, et que 40 % des répondants sont très préoccupés. C’est tout à fait compréhensible : ces actes malveillants font généralement la une et peuvent causer des dégâts considérables. Pourtant, 25 % des personnes interrogées restent passives face aux vulnérabilités de la chaîne d’approvisionnement et n’analysent pas de manière exhaustive le code et les bibliothèques open source tierces qu’elles utilisent.

Interrogés sur les SBOM en général, plus de 55 % des répondants ont indiqué qu’ils en produisaient déjà, et parmi eux, 70 à 90 % les publiaient également.

De nombreuses organisations utilisent déjà des SBOM

Depuis décembre 2022, un décret impose l’utilisation de SBOM pour tous les logiciels achetés par le gouvernement américain. Si les SBOM ne peuvent pas résoudre directement les attaques visant les logiciels, les informations qu’elles fournissent sont utiles pour identifier les logiciels vulnérables et atténuer les vecteurs d’attaque potentiels.

Une nomenclature logicielle fournit des informations détaillées sur les logiciels et les bibliothèques qui composent les applications, et met en évidence des éléments essentiels du code à examiner. Elle améliore la réponse aux vulnérabilités en permettant aux développeurs d’identifier les versions vulnérables des composants et, avec les outils de sécurité pour développeurs appropriés, de sécuriser rapidement les fonctionnalités à risque.

Les avantages de l’utilisation d’une nomenclature logicielle sont les suivants :

• Une meilleure réponse aux vulnérabilités et une sécurité renforcée. Avec une SBOM, vous pouvez vérifier les composants et leurs versions dans les bases de données de vulnérabilités et vous assurer qu’ils ne présentent aucun risque connu.

• Une conformité renforcée. Les SBOM vous permettent d’identifier facilement les composants qui ne sont pas autorisés dans le cadre d’un référentiel de conformité donné.

• Des rapports améliorés. Les SBOM vous aident à comprendre les facteurs historiques qui ont motivé les solutions de sécurité.

Les SBOM ne suffisent pas à elles seules

Après des années de travail en silos, les équipes de sécurité applicative et de développement devront bientôt unir leurs forces pour livrer du code sécurisé et respecter les exigences de l’organisation, comme le montre l’étude.

78 % des répondants à notre étude se disent quelque peu préoccupés par les attaques contre la chaîne d’approvisionnement logicielle : il est temps d’agir. Nous devons sensibiliser les développeurs aux principes de sécurité afin qu’ils puissent choisir des packages moins risqués pendant qu’ils codent, et mettre en place des processus continus pour suivre et corriger les nouvelles vulnérabilités dès leur apparition. 

En outre, l’étude montre que la publication d’une SBOM est nécessaire, mais ne suffit pas à elle seule pour aider les organisations à sécuriser leur code. 

Voyez une SBOM comme une liste d’ingrédients. Elle est générée et, même si tout semble sain au premier abord, vous découvrez bientôt un ingrédient nocif — ou qu’un lot a été compromis. 

Cette découverte vous permettra de prendre des mesures d’atténuation, mais elle ne suffira pas à elle seule à résoudre le problème.

L’open source a besoin de sécurité et d’automatisation

Parmi les personnes interrogées, 25 % ont répondu qu’elles s’appuyaient sur le code open source pour ses fonctionnalités. 

La sécurisation de votre code open source reste largement manuelle. Une première étape essentielle pour renforcer la sécurité de la chaîne d’approvisionnement open source consiste donc à vous doter d’une technologie de génération automatisée de SBOM. L’automatisation de vos SBOM vous permettra d’identifier rapidement les problèmes de sécurité et de conformité. Elle améliorera également le suivi des vulnérabilités dans vos bibliothèques open source. 

La sécurisation de votre chaîne d’approvisionnement logicielle nécessite une approche dynamique, un effort conjoint des équipes de sécurité et de développement, et doit intervenir à chaque étape. 

Que les composants intégrés à votre code représentent une part importante ou faible des logiciels que vous déployez, qu’ils soient importés dans le code en tant que dépendance tierce ou proviennent d’une image de conteneur de base, la sécurité est essentielle.

Découvrez les conclusions du rapport Techstrong PulseMeter.