Gestion des risques de la chaîne d'approvisionnement logicielle

Gestion des risques vs sécurité

La sécurité de la chaîne d'approvisionnement logicielle désigne l'ensemble des contrôles techniques : SBOM, dépendances épinglées, builds restreints. La gestion des risques se situe au-dessus. Elle demande de quels fournisseurs et composants votre activité dépend, ce qui se passe si l'un d'eux défaille, et si vous avez investi vos efforts au bon endroit.

Quels sont les risques ?

Risque	Exemple	Contrôle principal
Composants vulnérables	Une faille dans une bibliothèque largement utilisée	SBOM et surveillance continue
Composants malveillants	Un paquet détourné, ou du typosquatting	Vérification, adoption différée, limites du trafic sortant
Projets abandonnés	Une dépendance dont l'unique mainteneur est passé à autre chose	Contrôles de santé et plan de remplacement
Risque de licence	Un composant copyleft dans un produit propriétaire	Politique de licences
Compromission du build	Une GitHub Action détournée atteint vos secrets	Épinglage, isolation, moindre privilège
Risque fournisseur	Le produit ou la mise à jour d'un fournisseur est compromis	Évaluation, contrats, SBOM des fournisseurs
Risque réglementaire	Un client ou une loi exige des preuves que vous ne pouvez pas produire	Enregistrements conservés par release

Un processus en six étapes

1. Établissez l'inventaire. Listez les produits que vous fabriquez et les logiciels que vous achetez. Pour ce que vous construisez, conservez une SBOM par release. Vous ne pouvez pas évaluer ce que vous ne voyez pas.
2. Classez selon ce qui compte. Une bibliothèque dans votre service de paiement n'équivaut pas à une bibliothèque dans un outil interne. Notez les produits selon leur exposition, leurs données et leur impact métier.
3. Évaluez les risques. Examinez les vulnérabilités, la santé des projets, les licences et la façon dont chaque fournisseur traite la sécurité. Faites-le en profondeur pour le niveau le plus élevé et plus légèrement pour le reste.
4. Traitez-les. Pour chaque risque, décidez de corriger, de remplacer, d'ajouter un contrôle ou d'accepter. Un risque accepté a besoin d'un responsable et d'une date de revue.
5. Surveillez en continu. Le risque évolue sans le moindre changement de votre côté, par exemple quand un avis de sécurité est publié ou qu'un mainteneur s'en va. Les revues annuelles passent à côté.
6. Rendez compte. Donnez à la direction une vue courte : principaux risques, exposition dans le temps et ce qui a été accepté. Les clients et les auditeurs demanderont le détail.

Évaluer les fournisseurs

Les questionnaires seuls vous disent ce qu'un fournisseur affirme. Demandez ce qui montre ce qu'il fait :

• Une SBOM du produit, avec un format indiqué et un moyen d'obtenir les mises à jour
• La façon dont il traite les vulnérabilités, et la rapidité avec laquelle il en informe ses clients
• Un contact sécurité et une politique de divulgation
• La façon dont il construit ses releases, et s'il peut montrer d'où vient une release
• La durée pendant laquelle une version reçoit des correctifs de sécurité
• Des certifications et des rapports d'audit qui couvrent le produit que vous achetez

Inscrivez vos attentes dans les contrats. Il est bien plus facile d'exiger une SBOM ou un délai de notification à la signature qu'après un incident.

Les cadres à suivre

• NIST SP 800-161 est la principale référence pour la gestion des risques cyber de la chaîne d'approvisionnement, ou C-SCRM. Il s'applique à tous les niveaux d'une organisation et intègre le risque de la chaîne d'approvisionnement à la gestion globale des risques.
• Le NIST SSDF couvre les pratiques de développement sécurisé, ce qui en fait une bonne base pour ce que vous demandez à vos fournisseurs, et à vous-même.
• SLSA vous donne un langage commun pour exprimer le degré de fiabilité d'un build.
• ISO/IEC 27001:2022 comprend des mesures pour la sécurité de la chaîne d'approvisionnement TIC (annexe A 5.21) et les vulnérabilités techniques (8.8). Elle n'exige pas de SBOM, mais les SBOM constituent de bonnes preuves pour ces mesures.
• NIS2 cite la sécurité de la chaîne d'approvisionnement comme mesure obligatoire pour les entités concernées, à l'article 21(2)(d).

Comment la mesurer

Choisissez quelques indicateurs qui mènent à des décisions :

• Part des produits dotés d'une SBOM pour la release actuelle
• Temps nécessaire pour répondre à « sommes-nous touchés ? » face à une nouvelle vulnérabilité critique
• Fenêtre d'exposition : durée pendant laquelle une version vulnérable a été en production
• Part des fournisseurs de premier niveau évalués au cours de la dernière année
• Nombre de risques acceptés dont la date de revue est dépassée

Comment CRACI vous aide

CRACI donne à un programme de gestion des risques les données qui lui manquent généralement sur les logiciels que vous construisez. Il enregistre ce que chaque build GitHub Actions a récupéré, licences déclarées comprises, dans des SBOM que vous pouvez conserver par release et partager en CycloneDX ou SPDX. Il surveille ce qui a été livré, montre quels builds contenaient un paquet vulnérable pour que vous voyiez la période pendant laquelle vous avez été touché, et peut appliquer une politique de licences et bloquer des builds grâce aux gates de politique. Consultez la sécurité de la chaîne d'approvisionnement logicielle avec CRACI et le comparatif des outils.

L'évaluation des fournisseurs et votre registre des risques restent du ressort de vos outils de gouvernance et de votre équipe.

Gestion des risques de la chaîne logicielle : questions fréquentes

Qu'est-ce que la gestion des risques de la chaîne d'approvisionnement logicielle ?

C'est la façon dont une organisation identifie, évalue et réduit le risque lié aux logiciels qu'elle n'a pas écrits, notamment les paquets open source, les produits commerciaux, les fournisseurs SaaS et les outils de build.

Qu'est-ce que le C-SCRM ?

C-SCRM signifie cybersecurity supply chain risk management, le terme utilisé par le NIST pour la gestion des risques cyber de la chaîne d'approvisionnement. NIST SP 800-161 en est le principal guide : il explique comment repérer, évaluer et réduire les risques cyber sur toute la chaîne d'approvisionnement, à tous les niveaux d'une organisation.

Quels sont les plus grands risques de la chaîne d'approvisionnement logicielle ?

Les composants open source vulnérables et malveillants, les systèmes de build et outils CI compromis, les projets abandonnés, les problèmes de licence et les fournisseurs victimes d'une intrusion.

En quoi est-ce différent de la gestion des risques tiers ?

La gestion des risques tiers examine généralement les fournisseurs en tant qu'entreprises. La gestion des risques de la chaîne d'approvisionnement logicielle descend jusqu'aux composants et aux processus de build, y compris les projets open source sans éditeur derrière eux.

Qui en est responsable ?

En général, la direction de la sécurité ou des risques définit le programme, la sécurité produit prend en charge ce que l'entreprise construit, et les achats ou la gestion des fournisseurs ce qu'elle achète. Les équipes d'ingénierie corrigent ce qui est détecté.