30 ter. La supply chain logicielle : savoir ce que l'on livre et pouvoir le croire
Pourquoi ce chapitre existe
Un logiciel livré n'est pas seulement le code écrit dans le dépôt. Il contient des dépendances, outils de build, actions d'automatisation, images, configurations, secrets et artefacts intermédiaires. Une faiblesse, une substitution ou une provenance inconnue dans cette chaîne peut contourner les pratiques de revue et de test appliquées au code applicatif. La supply chain logicielle consiste à rendre cette chaîne visible, protégée et récupérable.
Les idées essentielles
- Chaque artefact livré doit être traçable vers sa source, sa construction, ses dépendances et son environnement de promotion.
- Les dépendances sont des engagements de sécurité et de maintenance, pas seulement des imports pratiques.
- Les environnements de build et de CI sont des actifs sensibles : leurs droits, secrets et mises à jour doivent être gouvernés.
- Inventaire, provenance, vérification et réponse aux vulnérabilités forment une boucle continue, non une analyse ponctuelle.
Rendre la chaîne explicite
Pour un artefact de production, l'équipe doit pouvoir répondre : de quel commit provient-il ? quelles dépendances et versions contient-il ? quel pipeline l'a construit ? quels contrôles ont été exécutés ? qui peut le promouvoir ? Ces réponses réduisent le temps d'investigation d'une vulnérabilité et empêchent qu'un build local ou un artefact non vérifié devienne la source réelle de production.
| Maillon | Risque | Contrôle proportionné |
|---|---|---|
| Dépendance | Vulnérabilité ou abandon | Inventaire, mises à jour, politique d'exception |
| Build | Substitution ou secret exposé | Environnement durci, droits minimaux, logs d'audit |
| Artefact | Origine ou contenu inconnu | Version immuable, provenance, signature si nécessaire |
| Promotion | Déploiement non autorisé | Séparation des rôles, traçabilité, même artefact promu |
| Incident | Impact non identifié | Inventaire interrogeable et procédure de correction |
Répondre à une vulnérabilité par le contexte
Une alerte de dépendance n'a pas toutes les mêmes conséquences. L'équipe doit savoir si le composant est réellement utilisé, exposé dans le chemin concerné, compensé par un contrôle ou absent de l'artefact final. Cette analyse ne justifie pas l'inaction : elle permet de prioriser, de documenter une exception temporaire et de vérifier que la correction est effectivement livrée.
Un SBOM ou une liste de dépendances accélère la réponse ; il ne prouve ni la sûreté d'un composant, ni l'absence de vulnérabilité dans le code ou la configuration. Il doit s'intégrer à une stratégie de sécurité plus large, incluant contrôle d'accès, revue de menace et observabilité.
Anti-patterns
Installer ou exécuter des dépendances non verrouillées en CI
Un build qui varie selon le moment où il est lancé n'est pas pleinement reproductible et augmente le risque de substitution. Verrouiller les versions, vérifier les sources et mettre à jour de façon contrôlée rendent le changement visible et testable.
Donner des privilèges de production à tout le pipeline
Une CI compromise ne devrait pas pouvoir lire tous les secrets ou modifier toute la production. Limiter les droits par étape et séparer construction, signature et promotion réduit le rayon d'action d'un incident.
Fermer une alerte sans conserver la décision
Un faux positif, une exposition inexistante ou une correction impossible immédiatement peut justifier une exception. Sans propriétaire, date de revue et protection compensatoire, la dette de sécurité devient invisible.
Bonnes pratiques
Promouvoir le même artefact avec une provenance lisible
Construire une fois, attacher version et métadonnées, puis promouvoir cet artefact vérifié dans les environnements évite les divergences silencieuses. Les différences de configuration restent explicites et contrôlées séparément.
Exercicer la réponse de chaîne
Choisir périodiquement une dépendance vulnérable simulée et vérifier qu'il est possible d'identifier les artefacts affectés, de prioriser les services exposés, de déployer une correction et de prouver son adoption. Cet exercice teste autant l'inventaire que la capacité humaine de réponse.
Checklist — Peut-on faire confiance à l'artefact livré ?
- Peut-on relier l'artefact au commit, pipeline, dépendances et contrôles qui l'ont produit ?
- Les versions, sources et accès de build sont-ils reproductibles et protégés ?
- Qui peut construire, signer ou promouvoir, avec quels privilèges minimaux ?
- L'inventaire permet-il d'identifier rapidement les services affectés par une dépendance ?
- Les exceptions de vulnérabilité sont-elles justifiées, datées et compensées ?
- Le même artefact vérifié est-il promu, et la réponse à une compromission a-t-elle été exercée ?
À retenir
La supply chain logicielle rend la confiance dans un artefact vérifiable. Connaître ses composants, protéger sa construction et pouvoir répondre à une vulnérabilité transforme la sécurité de livraison d'une supposition en capacité opérationnelle.