Ressources · 16
Sécuriser la chaîne d’approvisionnement logicielle
Relier composants, provenance, construction, vulnérabilités et mises à jour à chaque version réellement déployée.
· 18 min
Ce que ce guide permet
- Connaître les dépendances réellement livrées
- Vérifier l’origine des artefacts
- Prioriser les failles selon le contexte
- Tester un remplacement et un retour arrière
Contrôle express
- La nomenclature correspond-elle exactement à la version déployée ?
- Les dépendances transitives sont-elles incluses ?
- Qui peut signer une version ?
- Une vulnérabilité est-elle exploitable dans votre usage ?
- Un composant critique peut-il être retiré sans improviser ?
Méthode pas à pas
- 01
Cartographier les versions livrées
Identifiez dépôts, dépendances directes et transitives, outils de compilation, images, services externes et propriétaires. Associez le tout à une version vérifiable.
Livrable : carte produit, composant, version et propriétaire.
- 02
Produire une nomenclature exploitable
Générez une SBOM pour chaque version, puis confrontez-la aux artefacts réellement publiés. Prévoyez correction des noms, versions absentes et composants internes.
Livrable : SBOM datée et vérifiée.
- 03
Protéger la construction
Limitez les droits de publication, isolez les étapes sensibles et conservez provenance, empreintes et signatures. Vérifiez ces preuves avant déploiement.
Livrable : dossier de construction et règle de vérification.
- 04
Trier les alertes
Reliez chaque avis de vulnérabilité au composant, à la version, à l’exposition et à l’usage réel. Fixez responsable, échéance, décision et preuve de fermeture.
Livrable : file de triage contextualisée.
- 05
Exercer le changement
Remplacez en environnement de test un composant critique, contrôlez les parcours métier et répétez le retour arrière. Mesurez les dépendances qui bloquent.
Livrable : compte rendu de remplacement et de repli.
- 06
Maintenir les preuves
Réexaminez les composants et les fournisseurs à chaque version majeure et après incident. Gardez une durée de conservation adaptée aux besoins de correction.
Livrable : calendrier de revue et historique des versions.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Couverture SBOM | Versions livrées avec nomenclature vérifiée | Corriger les écarts avant publication |
| Provenance vérifiée | Artefacts contrôlés avant déploiement | Bloquer les versions sans preuve attendue |
| Délai de triage | Temps entre avis pertinent et décision documentée | Escalader les composants exposés |
| Réversibilité | Remplacements critiques testés avec retour arrière | Lever les dépendances bloquantes |
Erreurs fréquentes
- Confondre inventaire du dépôt et composants déployés
- Conserver une SBOM sans l’actualiser
- Classer une faille uniquement par score
- Signer un artefact sans vérifier la provenance de sa construction
Questions fréquentes
Une SBOM suffit-elle ?
Non. Elle facilite l’identification des composants, mais il faut également vérifier la provenance, l’intégrité, l’exposition et la capacité de mise à jour.
Faut-il bloquer toute vulnérabilité ?
La décision dépend du composant effectivement utilisé, de son exposition, des compensations et de la criticité métier ; elle doit rester documentée.
Quel cadre de référence utiliser ?
Le Secure Software Development Framework du NIST fournit des pratiques de développement sécurisé et de protection des logiciels adaptées au cycle de vie.
Références officielles
Pour aller plus loin
Analyses associées
