Repenser la supply chain logicielle SBOM SLSA comme risque de production
Pour un directeur technique, la supply chain logicielle SBOM SLSA n’est plus un sujet d’outillage mais un risque industriel à part entière. La chaîne d’approvisionnement logicielle doit être traitée comme une chaîne de production critique, avec des niveaux de contrôle comparables à ceux d’une usine automatisée et une gouvernance de sécurité informatique alignée sur les exigences NIS2. Cette approche impose de cartographier chaque section de la chaîne, depuis le code source jusqu’aux artefacts logiciels déployés en production, en intégrant les dépendances open source et les services cloud.
Les attaques de type code malveillant injecté dans des bibliothèques open source (SolarWinds, Log4Shell, XZ Utils) montrent que la simple revue de code ne suffit plus. La sécurisation de cette chaîne d’approvisionnement exige une traçabilité de la provenance des artefacts, une maîtrise des niveaux de confiance et une capacité à prouver que le binaire correspond bien au code source validé par vos équipes. C’est précisément le rôle combiné d’un SBOM robuste, d’un cadre SLSA bien appliqué et d’un modèle de supply chain logicielle piloté par la preuve plutôt que par la seule conformité documentaire.
Concrètement, vous devez structurer une table des matières opérationnelle de votre chaîne d’approvisionnement logicielle, en identifiant les sections critiques où un attaquant pourrait insérer du code malveillant. Cette cartographie doit couvrir les dépôts GitHub repository internes et externes, les registres comme GHCR GitHub ou Harbor, les pipelines GitHub Actions et les services de build tels que Cloud Build sur Google Cloud. Chaque maillon de la chaîne doit être relié à des contrôles de sécurité explicites, avec des niveaux de sévérité et des niveaux de remédiation associés. Un indicateur simple, par exemple la proportion d’images déployées avec provenance vérifiée, permet de suivre la progression de cette industrialisation, avec des objectifs chiffrés (50 % à six mois, 90 % à un an) intégrés aux tableaux de bord de production.
SBOM : de l’inventaire CycloneDX ou SPDX à la décision de risque
Un SBOM, ou Software Bill of Materials, n’est utile que s’il est relié à vos décisions de risque et à votre stratégie de sécurité informatique. Les formats CycloneDX et SPDX permettent de décrire les composants logiciels, leurs versions, leurs dépendances et parfois la provenance, mais ils ne définissent pas à eux seuls une politique de sécurisation de la supply chain logicielle SBOM SLSA. Le rôle du directeur technique consiste à imposer des sections minimales dans chaque SBOM, adaptées à vos chaînes d’approvisionnement logicielles et à vos exigences de conformité.
Dans un contexte où plus de 90 % des applications contiennent du code open source, un SBOM doit couvrir les dépendances directes et transitives, les artefacts logiciels générés par vos pipelines de build et les bibliothèques issues de dépôts publics comme GitHub. La granularité des niveaux de description doit être suffisante pour relier chaque composant à un risque métier, par exemple une bibliothèque critique exposée sur Internet ou un module cryptographique sensible. Pour un RSSI, l’objectif n’est pas d’accumuler des fichiers SBOM, mais de transformer ces inventaires en décisions de blocage, de mise à jour ou de segmentation d’environnements, avec des règles explicites (par exemple « bloquer toute dépendance critique non corrigée au-delà de 30 jours »).
Pour rendre ces SBOM actionnables, vous pouvez intégrer leur génération dans vos pipelines GitHub Actions ou vos jobs Cloud Build sur Google Cloud, en produisant un artefact SBOM pour chaque build d’application. Ces artefacts logiciels doivent ensuite être stockés dans un registre interne ou un GitHub repository dédié, avec une politique de rétention et de consultation claire pour les équipes de sécurité. Un exemple minimal de SBOM CycloneDX JSON pour une image de conteneur pourrait contenir un composant principal, deux dépendances et un champ de licence, ce qui suffit déjà à déclencher des règles de blocage :
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"components": [
{
"type": "container",
"name": "app-backend",
"version": "1.2.3,
{
"type": "library",
"name": "openssl",
"version": "3.0.13",
"licenses": [{ "license": { "id": "Apache-2.0 }]
},
{
"type": "library",
"name": "log4j",
"version": "2.17.2
]
}Une formation structurée, par exemple une formation avancée à la sécurité informatique orientée CISA, aide les responsables à interpréter ces SBOM et à les relier aux obligations réglementaires.
SLSA : transformer le pipeline CI CD en chaîne de confiance vérifiable
Le cadre SLSA, pour Supply chain Levels for Software Artifacts, fournit une échelle de maturité pour la supply chain logicielle SBOM SLSA. Chaque niveau SLSA définit des exigences sur la provenance, l’intégrité du build, l’isolation des environnements et la vérifiabilité des artefacts logiciels produits. Pour un directeur technique, l’enjeu est de traduire ces niveaux SLSA en exigences concrètes sur les pipelines CI CD existants, sans tomber dans le cargo cult sécuritaire.
Au niveau SLSA 1, vous exigez simplement que chaque build soit scripté et reproductible, ce qui élimine déjà une partie des risques liés aux builds manuels. Les niveaux SLSA 2 et 3 imposent une automatisation complète du build, une gestion stricte des identités de service et une traçabilité de la provenance des artefacts, par exemple via des attestations signées générées par Cloud Build ou GitHub Actions. Le niveau SLSA 4, plus ambitieux, requiert une isolation forte des environnements de build, une revue de code systématique et des contrôles renforcés sur les dépendances et la chaîne d’approvisionnement logicielle, tels que définis dans les spécifications publiques du projet SLSA.
Dans la pratique, vous pouvez définir des niveaux de sécurité par type d’application, en alignant les niveaux de chaîne SLSA sur la criticité métier et les risques de code malveillant. Les pipelines de build pour les services exposés sur Internet ou manipulant des données sensibles doivent viser au moins un niveau SLSA 3, avec une provenance SLSA vérifiable et des attestations stockées dans un registre interne. Une checklist synthétique par niveau (par exemple « build scripté », « identité de service dédiée », « attestation signée stockée dans le registre ») facilite l’évaluation de chaque pipeline. Un pack cyber adapté à votre entreprise peut servir de cadre pour prioriser les investissements nécessaires sur les chaînes d’approvisionnement logicielles les plus critiques.
Provenance, signatures et registres internes : verrouiller les artefacts de bout en bout
La provenance logicielle consiste à prouver qu’un artefact déployé en production provient bien du code source attendu, construit par un pipeline de build approuvé. Dans une supply chain logicielle SBOM SLSA, cette provenance doit être matérialisée par des attestations signées, liant le code source, la configuration de build, les dépendances et les artefacts logiciels finaux. Les solutions comme Sigstore, avec cosign, fulcio et rekor, permettent de signer ces artefacts sans gérer directement des clés privées à long terme, ce qui réduit la surface d’attaque opérationnelle.
Pour un directeur technique, la priorité est de faire du registre interne le point de contrôle central de la chaîne d’approvisionnement logicielle. Qu’il s’agisse d’un registre Docker comme Harbor, d’une solution Artifactory ou d’un registre GHCR GitHub, aucun artefact ne doit être déployé s’il n’est pas signé et associé à une provenance SLSA vérifiable. Les politiques de sécurité doivent refuser les images ou paquets dont la provenance est inconnue, même s’ils proviennent d’un dépôt GitHub repository réputé ou d’un fournisseur cloud comme Google Cloud.
Cette approche impose de revoir la chaîne d’approvisionnement des logiciels tiers, y compris les images de base et les dépendances open source intégrées dans vos builds. Les équipes doivent définir des sections de confiance, par exemple une chaîne d’approvisionnement logicielle interne pour les images validées, et une chaîne d’approvisionnement logicielle externe soumise à des contrôles renforcés. Un jeu de commandes cosign intégré dans les pipelines (signature à la sortie du build, vérification à l’entrée du registre) permet de mesurer rapidement la couverture, par exemple le pourcentage d’artefacts signés en production :
# Signature d'une image à la fin du build
cosign sign --key cosign.key registry.example.com/app-backend:1.2.3
# Publication de la preuve dans le journal de transparence rekor
cosign sign --key cosign.key --rekor-url https://rekor.sigstore.dev \
registry.example.com/app-backend:1.2.3
# Vérification côté déploiement
cosign verify --key cosign.pub registry.example.com/app-backend:1.2.3Pour arbitrer ces investissements face à la dette technique, un cadre comme celui présenté dans l’analyse sur la mesure de la dette technique et les frameworks de décision permet de relier directement les niveaux de chaîne SLSA au risque financier, en chiffrant par exemple le coût moyen d’un incident de supply chain par rapport au budget de sécurisation des pipelines.
Cas pratique : sécuriser une pipeline GitHub Actions avec SBOM, SLSA et contrôles de dépendances
Considérons une application critique construite à partir de code open source hébergé dans un GitHub repository, déployée sur un cluster Kubernetes et stockant ses images dans GHCR GitHub. La supply chain logicielle SBOM SLSA doit couvrir l’ensemble de cette chaîne, depuis la récupération des dépendances jusqu’au déploiement final, en intégrant des contrôles de sécurité à chaque niveau. L’objectif est de transformer une simple chaîne d’approvisionnement logicielle en une chaîne de confiance mesurable, avec des niveaux de chaîne clairement définis.
Dans la section de build, la pipeline GitHub Actions doit utiliser des runners durcis, des identités de service dédiées et des workflows signés, tout en générant un SBOM pour chaque artefact logiciel produit. Les dépendances open source doivent être verrouillées par version, analysées par des scanners de vulnérabilités et, lorsque c’est possible, remplacées par des composants issus d’une chaîne d’approvisionnement logicielle interne validée. Chaque build doit produire une provenance SLSA signée, liant le code source, les scripts de build, les dépendances et les artefacts logiciels finaux stockés dans GHCR GitHub ou un registre interne. Un exemple d’attestation SLSA minimale au format JSON peut inclure l’identifiant du commit, le pipeline utilisé et le digest de l’image générée.
Au moment du déploiement, le cluster Kubernetes doit vérifier les signatures des images et refuser tout artefact dont la provenance ne correspond pas aux politiques définies par le RSSI. Cette vérification peut s’appuyer sur des outils compatibles Sigstore, intégrés dans la chaîne d’approvisionnement des logiciels et orchestrés par des contrôleurs d’admission. En procédant ainsi, vous transformez chaque déploiement en un contrôle de conformité automatisé, où la sécurité n’est plus un audit ponctuel mais une propriété continue de la chaîne logicielle. Dans les organisations ayant mis en place ce type de contrôle, le temps moyen de correction d’une dépendance vulnérable diminue souvent de plusieurs jours, car l’impact est immédiatement visible dans les pipelines et les tableaux de bord de production.
Gouvernance, compétences et arbitrages : ce que le RSSI doit imposer
La sécurisation de la supply chain logicielle SBOM SLSA n’est pas qu’un sujet d’outils, c’est d’abord une question de gouvernance et de compétences. Le RSSI et le directeur technique doivent définir des niveaux de sécurité cibles pour chaque famille d’applications, en alignant les niveaux SLSA, les exigences de SBOM et les contrôles de provenance sur la criticité métier. Cette gouvernance doit être formalisée dans des politiques de sécurité informatique claires, intégrant la chaîne d’approvisionnement logicielle dans les comités d’architecture et les revues de risques.
Sur le plan opérationnel, les équipes doivent être formées à la lecture des SBOM, à l’analyse des dépendances et à la compréhension des attestations de provenance SLSA. Les responsables de produit et les équipes de développement doivent intégrer ces contraintes dès la conception, en considérant la chaîne d’approvisionnement des logiciels comme un paramètre de design au même titre que la performance ou la résilience. Les arbitrages entre time to market et sécurité doivent être documentés, avec des niveaux de chaîne explicites et des plans de remédiation lorsque les exigences SLSA ne peuvent pas être atteintes immédiatement, par exemple via des feuilles de route trimestrielles de montée en maturité.
Enfin, la collaboration avec les fournisseurs cloud comme Google Cloud et les plateformes de développement comme GitHub doit être structurée autour de contrats de sécurité précis, couvrant la gestion des artefacts logiciels, la sécurisation des pipelines de build et la maîtrise des chaînes d’approvisionnement logicielles. Les indicateurs de performance doivent mesurer non seulement la vitesse de build, mais aussi la proportion d’artefacts avec provenance vérifiée, la réduction des dépendances non maîtrisées et la baisse des incidents liés à du code malveillant. Cette approche transforme la supply chain logicielle en un levier stratégique, où la sécurité devient un avantage compétitif plutôt qu’une contrainte subie, avec des gains mesurables sur la disponibilité, la conformité et la confiance des clients.
FAQ sur la supply chain logicielle SBOM SLSA
Quelle est la différence entre un SBOM et le cadre SLSA pour une chaîne logicielle ?
Un SBOM décrit la composition des logiciels et de leurs dépendances, tandis que le cadre SLSA définit des niveaux de sécurité pour le processus de build et la provenance des artefacts. Le SBOM répond à la question « que contient mon logiciel », alors que SLSA répond à « comment ce logiciel a été construit et par qui ». Les deux sont complémentaires pour sécuriser une supply chain logicielle SBOM SLSA de bout en bout.
Comment prioriser les applications à migrer vers des niveaux SLSA plus élevés ?
La priorisation doit se faire en fonction de la criticité métier, de l’exposition sur Internet et de la sensibilité des données traitées. Les services en frontal, les composants manipulant des secrets ou des données personnelles et les briques partagées entre plusieurs produits doivent viser en priorité des niveaux SLSA élevés. Cette approche permet d’aligner les investissements de sécurité sur le risque réel plutôt que sur une couverture uniforme irréaliste, en concentrant les efforts sur les 10 à 20 % d’applications qui concentrent la majorité du risque.
Faut il imposer un SBOM pour tous les logiciels tiers utilisés dans l’entreprise ?
Imposer un SBOM pour tous les logiciels tiers est idéal, mais peut être difficile à obtenir pour certains fournisseurs. Il est pertinent de cibler d’abord les logiciels critiques, les composants de sécurité et les briques exposées, en exigeant des SBOM dans les contrats et appels d’offres. Progressivement, cette exigence peut être étendue à l’ensemble de la chaîne d’approvisionnement logicielle pour renforcer la visibilité globale, en fixant par exemple un objectif de couverture SBOM de 80 % sur le parc applicatif en deux ans.
Comment intégrer Sigstore et les signatures d’artefacts dans un environnement existant ?
L’intégration de Sigstore peut commencer par la signature des images de conteneurs produites par vos pipelines de build, en utilisant cosign et un registre compatible. Les politiques de déploiement doivent ensuite être mises à jour pour vérifier ces signatures avant d’autoriser l’exécution des artefacts. Cette démarche incrémentale permet de sécuriser progressivement la supply chain logicielle SBOM SLSA sans bloquer les équipes, en commençant par un environnement pilote avant de généraliser les contrôles.
Quel rôle joue le registre interne dans la sécurisation de la chaîne d’approvisionnement logicielle ?
Le registre interne est le point de contrôle central où sont stockés les artefacts logiciels approuvés, leurs signatures et leurs attestations de provenance. En imposant que seuls les artefacts présents dans ce registre puissent être déployés, vous réduisez fortement le risque d’introduction de code malveillant depuis des sources non maîtrisées. Ce registre devient ainsi un composant clé de la gouvernance de la supply chain logicielle SBOM SLSA, avec des métriques de suivi comme le taux d’images non conformes bloquées en pré-production.