Sécuriser la supply chain logicielle

devsecops 13 févr. 2023

Pendant longtemps, la sécurité des logiciels se concentrait sur l’application elle-même.
On testait le code, on verrouillait l’infrastructure, on protégait le réseau.

Mais la réalité moderne est différente.
La majorité des applications actuelles ne sont pas construites uniquement avec du code interne.
Elles reposent sur :

des bibliothèques open-source,
des conteneurs préconstruits,
des scripts,
des outils CI CD,
des services cloud,
des pipelines automatisés.

Ce modèle crée une nouvelle surface d’attaque : la supply chain logicielle.

Ce que l’on déploie ne dépend plus seulement de ce que l’on écrit.
Il dépend aussi de ce que l’on importe.

Pourquoi la supply chain logicielle est devenue un enjeu critique

Plusieurs incidents ont révélé le danger de dépendances compromises ou de chaînes de compilation manipulées.

Exemples marquants :

SolarWinds (2020) : compromission d’une mise à jour → impact mondial.
Log4Shell (2021) : vulnérabilité dans une bibliothèque, exploitée massivement.
XZ Utils Backdoor (2024) : attaque ciblée sur un composant critique Linux.

Ces événements montrent que le risque ne vient pas toujours de ce que l’on construit, mais de ce qui construit ce que l’on construit.

Les trois dimensions de la supply chain security

Pour sécuriser la supply chain logicielle, trois axes doivent être maîtrisés.

1. La provenance (d’où vient le code ?)

Comprendre l’origine du code est indispensable avant de l’intégrer.
On vérifie si la dépendance est fiable, si la version est encore maintenue, si la source est légitime et si la distribution n’a pas été altérée.
Pour cela, on s’appuie sur l’analyse de composition logicielle, la validation des éditeurs et des mécanismes cryptographiques qui permettent de confirmer l’authenticité du code.

Élément vérifié	Description
Fiabilité de la dépendance	La dépendance est-elle connue, stable et utilisée dans l’écosystème ?
Version maintenue	Les mises à jour et correctifs sont-ils toujours fournis ?
Source légitime	Le code provient-il d’un éditeur ou d’un dépôt authentifié ?
Intégrité de la distribution	Le paquet n’a-t-il pas été altéré ou compromis ?
SCA (Software Composition Analysis)	Analyse automatisée des dépendances et de leurs risques.
Validation d’éditeur	Vérification de l’identité du fournisseur.
Vérification cryptographique	Contrôle des signatures et hachages.

2. L’intégrité (le code a-t-il été modifié ?)

L’intégrité vise à garantir que le code, les images conteneurs ou les artefacts n’ont subi aucune altération malveillante au cours du développement ou du pipeline.
Les signatures cryptographiques assurent cette continuité : si un artefact n’est pas signé, il ne peut pas être considéré comme fiable, même s’il semble fonctionner correctement.

Élément concerné	Risque couvert	Méthode utilisée
Code source	Modification malveillante	Contrôles d’intégrité, signatures
Image conteneur	Altération ou injection	Signature d’image (cosign, notary, etc.)
Artefacts de build	Corruption ou falsification	Chaîne de confiance signée
Signatures cryptographiques	Preuve d’authenticité	Garantissent la véracité des artefacts

Un artefact non signé n’est pas fiable, même s’il fonctionne.

3. La transparence (que déployons-nous réellement ?)

La transparence consiste à savoir exactement ce que contient l’application déployée. Une SBOM (Software Bill of Materials) offre une vision détaillée des bibliothèques, de leurs versions, de leurs licences et des vulnérabilités connues.
Cette visibilité facilite le travail de correction, d’audit et répond aux exigences réglementaires de plus en plus fréquentes dans les organisations.

Contenu identifié	Utilité
Bibliothèques	Identification des composants réels du logiciel
Versions	Suivi des mises à jour et risques associés
Licences	Conformité juridique
Vulnérabilités connues	Anticipation des risques de sécurité
SBOM	Documentation structurée et exploitable pour audits et remédiations

Les frameworks et normes émergentes

Pour structurer cette sécurité, plusieurs référentiels apparaissent.

📍 SLSA (Supply-chain Levels for Software Artifacts)

SLSA est un cadre proposé par Google pour renforcer la sécurité de la chaîne d’approvisionnement logicielle. Il définit quatre niveaux de maturité, chacun ajoutant des garanties supplémentaires sur la façon dont un logiciel est construit, vérifié et distribué.
Plus on monte dans les niveaux, plus la confiance augmente : on sait d’où vient le code, comment il a été compilé, et surtout qu’aucune modification malveillante n’a pu s'insérer dans la chaîne.

Concrètement, un niveau SLSA élevé signifie que :

la provenance du code est prouvée et traçable,
l’artefact final est sécurisé et signé,
la chaîne CI/CD est verrouillée, isolée et surveillée contre les altérations.

C’est aujourd’hui l’une des références majeures pour mettre en place une chaîne de confiance complète, du code source jusqu’au déploiement.

📍 SSDF (NIST Secure Software Development Framework)

Le SSDF est un cadre du NIST qui définit les pratiques essentielles pour un développement logiciel sécurisé.
Là où SLSA se concentre sur la chaîne d’approvisionnement, le SSDF couvre toute la gouvernance du cycle de vie logiciel, depuis la conception jusqu’à l’exploitation.

Il est utilisé dans de nombreux environnements réglementés (secteur public, banques, santé, industries critiques).
Il encourage notamment :

l’intégration précoce de la sécurité dans les pratiques de développement,
la gestion structurée des vulnérabilités,
la documentation et la conformité,
la responsabilisation des équipes par des processus mesurables.

Le SSDF sert souvent de référentiel organisationnel pour structurer une démarche DevSecOps au niveau entreprise.

📍 CIS Benchmarks / Cloud Security Posture Management (CSPM)

Les CIS Benchmarks sont des recommandations publiées par le Center for Internet Security. Elles définissent les paramètres de sécurité recommandés pour les systèmes, applications et surtout les environnements cloud.

Ils sont essentiels car les plateformes cloud sont rarement sécurisées par défaut :
des accès trop larges, des services publics sans nécessité, des configurations faibles ou des logs inexploités peuvent rapidement devenir des failles critiques.

Le Cloud Security Posture Management (CSPM) vient compléter cela en automatisant :