Utiliser un SBOM pour prendre de meilleures décisions de sécurité logicielle

Temps de lectures : 8 minutes 

Les attaques contre la chaîne d'approvisionnement de logiciels sont en augmentation. De nombreux articles de presse sur la cybersécurité, comme l'attaque de SolarWinds et la vulnérabilité d'Apache Log4j, montrent que les attaquants exploitent les vulnérabilités et les faiblesses de la chaîne d'approvisionnement de logiciels. Le mode opératoire peut aller d'exploitations assez simples de vulnérabilités connues comme  Log4Shell  à des attaques très sophistiquées, sponsorisées par des acteurs de la menace étatique, comme l'attaque de la chaîne d'approvisionnement de SolarWinds  .

Les dépenses annuelles consacrées aux logiciels d’entreprise (également appelés logiciels commerciaux prêts à l’emploi ou COTS) approchent aujourd’hui  les 600 milliards de dollars, avec un taux de croissance de 11,5 % . Pourtant, compte tenu de l’ampleur de cet investissement, combien dépense-t-on pour garantir la sécurité de tous ces logiciels COTS ? En termes relatifs, les entreprises dépensent une somme dérisoire pour sécuriser leur chaîne d’approvisionnement en logiciels par rapport à leur investissement dans des applications logicielles pour soutenir leurs opérations. C’est pourquoi les logiciels COTS vulnérables sont si dangereux, car les vulnérabilités peuvent être « cachées » dans des composants open source (Log4j) au sein des produits, et les clients se retrouvent avec un faux sentiment de sécurité.

Dans un rapport de Forrester de 2021 sur l'état de la sécurité des applications , une enquête menée auprès d'entreprises a montré que les vulnérabilités logicielles de leurs applications constituaient la voie la plus probable d'une cyberattaque. Les logiciels open source jouent un rôle clé dans la prévalence de ces vulnérabilités. Leur utilisation augmente d'année en année et le nombre de vulnérabilités augmente encore plus rapidement.

De plus, un rapport de recherche Osterman de 2021  a révélé que 100 % des logiciels COTS largement utilisés analysés par  CodeSecure CodeSentry  (sans accès au code source) contenaient des composants open source vulnérables. Un nombre inquiétant de 85 % des applications analysées présentaient des vulnérabilités critiques avec un score du système commun de notation des vulnérabilités ( CVSS ) de 10,0. Les applications les plus vulnérables étaient les applications de messagerie quotidienne et de réunion en ligne. Toutes les applications sont des applications largement utilisées et la présence de ces vulnérabilités critiques présente un risque sérieux de cybersécurité pour les organisations, car la probabilité et l'impact d'une cyberattaque réussie sont très élevés. Le résultat de cette recherche montre clairement qu’il reste encore beaucoup à faire pour sécuriser la chaîne d’approvisionnement en logiciels.

Cela soulève donc la question de savoir ce que les entreprises peuvent faire pour améliorer cette situation ?

Cet article explique :

• Comment les entreprises peuvent-elles améliorer leur posture de sécurité COTS ?
• Que faire des résultats SBOM ?

L'approche traditionnelle consiste à faire confiance à chacun de vos fournisseurs et à supposer qu'ils ont fait preuve de la diligence requise lors du développement de leur logiciel. Formellement, cela signifierait demander au fournisseur d'attester de ses bonnes pratiques d'ingénierie logicielle lors du processus d'achat et de divulguer les pratiques de sécurité pour la prise en charge de son logiciel. Les clients, quant à eux, sont libres d'enquêter sur la sécurité des produits qu'ils utilisent par le biais d'associations ou de groupes d'utilisateurs afin de partager des informations sur les risques liés aux fournisseurs et la sécurité des logiciels.

Ces approches ne sont clairement pas suffisantes, comme le montre la vulnérabilité Apache Log4j. Malgré les meilleures intentions des éditeurs de logiciels, de trop nombreuses vulnérabilités de sécurité se cachent dans les composants tiers et open source des logiciels COTS. Cela représente un angle mort en matière de sécurité logicielle dont les éditeurs eux-mêmes ne sont peut-être même pas conscients. L'artefact clé nécessaire pour faire la lumière sur cet angle mort est la nomenclature logicielle (SBOM).

Le SBOM est un rapport d'inventaire des composants logiciels qui composent un produit logiciel. Tout comme les étiquettes sur les produits alimentaires, une liste d'ingrédients et d'informations nutritionnelles. Le SBOM est la même chose : une divulgation complète de tous les composants intégrés dans un produit. Cependant, tout comme les organisations ont du mal à recevoir un SBOM de leur fournisseur, elles ont également du mal à savoir quoi faire avec un SBOM une fois qu'elles l'ont reçu. Que se passe-t-il si le logiciel que vous avez acheté présente des vulnérabilités critiques ? Comment gérez-vous ces informations et comment traitez-vous avec vos fournisseurs ?

Automatisation de la génération SBOM et de la détection des vulnérabilités
Les résultats du rapport Osterman indiquent que toutes les applications d'entreprise utilisent des composants open source et que la plupart d'entre elles contenaient des vulnérabilités critiques exploitables. Il est évident que les approches de sécurité périmétrique existantes ne suffiront pas à défendre les organisations contre les menaces liées à ces vulnérabilités logicielles. L'objectif de l'automatisation de la sécurité de la chaîne d'approvisionnement logicielle est d'obtenir une visibilité approfondie sur les produits que vous achetez et que vous avez déployés pour prendre en charge les fonctions critiques de l'entreprise. Le SBOM ainsi que des informations détaillées sur les vulnérabilités sont nécessaires pour vraiment comprendre le risque de sécurité du logiciel au sein de votre organisation. Grâce à une nouvelle technologie qui analyse les applications binaires sans avoir besoin d'accéder au code source, les équipes de sécurité de l'entreprise peuvent désormais produire leurs propres SBOM détaillés ainsi que des tableaux de bord de haut niveau pour faciliter l'analyse et la synthèse des résultats. De plus, un rapport sur les vulnérabilités logicielles est essentiel pour cataloguer les vulnérabilités connues (jour N et jour zéro) dans les composants logiciels décrits dans le SBOM. Un exemple de tableau de bord de résumé CodeSentry est présenté ci-dessous :

Le SBOM généré doit être lisible par l'homme et par la machine pour pouvoir être exporté et divulgué/partagé avec d'autres organisations et s'intégrer à d'autres solutions de sécurité et de gestion des risques. Les formats lisibles par l'homme doivent permettre une navigation aisée entre les composants et les vulnérabilités signalées. Les sorties lisibles par la machine telles que CycloneDX, SPDX et autres doivent être conformes aux normes du secteur pour prendre en charge les échanges ouverts. Un exemple de rapport SBOM de CodeSentry est présenté ci-dessous.

En examinant l'exemple d'application ci-dessus, il est clair qu'il existe de graves vulnérabilités dans le logiciel, des problèmes de sécurité de gravité élevée et critique, qui justifient des inquiétudes quant à l'utilisation de ce logiciel dans un environnement d'entreprise.

Les informations supplémentaires dans le SBOM peuvent inclure les licences. La vérification des informations de licence permet de garantir la conformité et de réduire le risque que le logiciel soit publié ou utilisé avec des composants sans licence. La possession d'informations de licence peut également aider à l'investigation lors de la vérification de la version du composant open source susceptible d'être vulnérable, par exemple la version d'Apache Log4j qui incluait la vulnérabilité critique Zero-day.

Compte tenu de ces informations, quelle est la prochaine étape ?

Avec toutes les données que vous avez obtenues grâce à l'utilisation d'une solution comme CodeSentry pour produire un SBOM, un score de sécurité, un rapport de vulnérabilité, des informations de licence, etc., il semble difficile de déterminer ce que vous en faites et comment gérer les conséquences de la découverte de vulnérabilités critiques. Comme pour la plupart des problèmes de sécurité, il est important d'évaluer les résultats en termes de probabilité et d'impact. La probabilité est une détermination de la possibilité qu'une attaque réussisse en utilisant la vulnérabilité découverte. L'impact est le dommage possible causé par une attaque réussie. Cet impact doit prendre en compte non seulement les dommages ou l'exposition immédiats, mais également l'impact à long terme sur votre marque, vos résultats et l'expérience client. Sachant qu'en moyenne aux États-Unis,  les entreprises ont payé 6,53 millions de dollars par violation de données , il faut prendre au sérieux l'évaluation de l'impact potentiel.

Une bonne façon d'évaluer les vulnérabilités critiques open source trouvées dans les logiciels COTS est d'utiliser le quadrant de risque illustré ci-dessous. Par exemple, un logiciel présentant certaines vulnérabilités, dont l'exploitation est peu probable avec un faible impact, pourrait être approuvé pour un achat, un renouvellement ou un contrat de maintenance en acceptant simplement le niveau de risque faible. Évidemment, les logiciels à fort impact et à forte probabilité de vulnérabilités d'attaque devront peut-être être rejetés (plus d'informations à ce sujet ci-dessous).

La prise de décision est plus subtile puisqu’il n’est souvent pas possible de simplement rejeter un logiciel essentiel à votre entreprise. Cela ajoute une autre dimension à la prise de décision et à l’approche adoptée avec l’éditeur de logiciels. L'utilisation des SBOM dans le processus d'approvisionnement COTS est un territoire relativement nouveau, mais l'hypothèse ici est que le client (vous) et le fournisseur agiront de bonne foi dans le but d'améliorer la sécurité du produit et de réduire le risque de sécurité. temps. Vous pouvez également appliquer cette réflexion aux logiciels que vous avez déjà déployés aujourd'hui en analysant ce qui est le plus critique pour votre entreprise et en prenant des décisions de sécurité plus intelligentes. L'illustration ci-dessous montre un processus de décision plus nuancé à suivre une fois les résultats du SBOM en main.

• Approuver/Rejeter

Commençons par les décisions les plus claires (en haut à gauche du diagramme ci-dessus). Si le SBOM et le rapport de vulnérabilité indiquent un nombre inacceptable de vulnérabilités de gravité élevée et que le risque est tout simplement trop élevé pour être utilisé tel quel, le produit doit être rejeté. De même, si le produit n'indique que des problèmes mineurs, il peut être accepté, avec la prudence habituelle qui doit accompagner les nouveaux produits.

• Approuver sous condition

Dans le cas où les produits présentent des problèmes de sécurité (voir en haut à droite ci-dessus) mais que les risques dépassent les besoins commerciaux du logiciel, le produit peut être approuvé sous condition. Dans ces cas, l'équipe de sécurité des informations de l'entreprise peut mettre en œuvre  des contrôles de sécurité compensatoires  pour le déploiement du produit en surveillant les activités de menace potentielles ciblant les vulnérabilités connues. De plus, il est essentiel de travailler avec le fournisseur pour remédier au risque, car il peut ignorer ces vulnérabilités. La divulgation et la coopération sont essentielles.

• Rejeter sous conditions

Si le produit logiciel est essentiel à l'entreprise mais que le risque de sécurité est trop élevé (voir la partie inférieure ci-dessus), le produit peut être rejeté sous certaines conditions. Dans de tels cas, la décision de procéder au déploiement dépendra de l'importance du logiciel pour l'entreprise. Dans le cas où l'importance de la sécurité est trop élevée, vous pouvez insister pour que les problèmes soient résolus avant le déploiement, point final (en bas à droite ci-dessus). Ou êtes-vous prêt à attendre une nouvelle version du logiciel qui résout les problèmes de sécurité les plus critiques avant de l'accepter. Disposer d'outils tels que CodeSentry permet de garantir l'honnêteté des fournisseurs, car vous pouvez vérifier de manière indépendante que les problèmes sont effectivement résolus.

Dans le cas extrême où le logiciel est essentiel à l'entreprise et nécessaire aux opérations quotidiennes, il peut être judicieux de négocier les conditions financières, juridiques et de responsabilité de son utilisation avec le fournisseur (en bas à gauche ci-dessus). Par exemple, une compensation financière pour une violation de données, un montant important qui a un impact à la fois sur l'entreprise et sur la réputation de vous en tant que client. Bien que ce soit un domaine relativement nouveau, c'est la réalité à laquelle les fournisseurs de logiciels doivent s'adapter lorsque les clients commencent à améliorer la sécurité de leur chaîne d'approvisionnement en logiciels. L'époque où l'on faisait aveuglément confiance aux fournisseurs de logiciels est révolue, car le risque est bien trop grand.

Résumé

Les dépenses annuelles en logiciels d’entreprise se chiffrent à des centaines de milliards de dollars. Pourtant, les entreprises dépensent une somme dérisoire pour sécuriser leur chaîne d’approvisionnement en logiciels par rapport à cet investissement. La plupart, sinon la totalité, des produits commerciaux utilisent une forme ou une autre de code open source dans leur composition et 85 % de ces applications présentent des vulnérabilités critiques selon une étude récente. Il est clair qu’il faut faire davantage pour améliorer la sécurité de la chaîne d’approvisionnement en logiciels et garantir une solide posture de sécurité des entreprises.

Traditionnellement, on faisait confiance aux éditeurs de logiciels pour fournir des produits sécurisés. Cependant, l’époque de la confiance aveugle est révolue. Malgré les meilleures intentions des éditeurs de logiciels, trop de failles de sécurité se cachent dans les logiciels COTS. L’artefact clé nécessaire à l’achat de logiciels est la nomenclature logicielle (SBOM).

À mesure que les SBOM gagnent du terrain sur le marché, la prochaine étape logique consiste à utiliser les résultats pour améliorer votre chaîne d'approvisionnement en logiciels, du processus d'approvisionnement à ce qui est déjà déployé aujourd'hui. Grâce à l'effet de levier qu'offre un SBOM, il est désormais possible de tenir les fournisseurs de logiciels responsables. Il est recommandé d'évaluer les logiciels en termes de quadrant de risque avec divers scénarios d'acceptation et de rejet. En fonction des besoins de l'entreprise et du profil de risque, vous pouvez prendre des décisions plus éclairées sur la sécurité de la chaîne d'approvisionnement en logiciels afin de réduire de manière proactive les risques et d'éliminer les menaces dans les logiciels qui gèrent votre entreprise.