Chapitre 12.3 — SRI, provenance & SBOM

⏱️ TL;DR — Trois outils pour renforcer l’intégrité et la traçabilité de la supply chain. SRI (Subresource Integrity) : si tu charges un script/style depuis un CDN externe, l’attribut integrity="sha384-..." fait vérifier l’empreinte par le navigateur — un fichier CDN altéré (CDN compromis) est rejeté. Provenance : prouver d’où vient un artefact (qui l’a construit, depuis quel code) via des attestations signées — pour ne pas exécuter un binaire dont on ignore l’origine. SBOM (Software Bill of Materials) : l’inventaire complet des composants de ton logiciel (chaque dépendance et version) — indispensable pour savoir, quand une CVE tombe, si tu es concerné et où. Ensemble : vérifier ce qu’on charge, savoir d’où ça vient, savoir ce qu’on embarque.

🎯 Objectifs

Utiliser SRI pour vérifier l’intégrité des ressources chargées depuis un CDN.
Comprendre la provenance (attestations signées) et son rôle anti-supply-chain.
Comprendre le SBOM et pourquoi l’inventaire des composants est crucial en cas de CVE.
Situer ces outils dans une stratégie globale de sécurité des dépendances.

SRI : vérifier ce que charge le navigateur

Beaucoup de sites chargent des scripts ou styles depuis un CDN externe (<script src="https://cdn.example/lib.js">). Problème : si le CDN est compromis (ou l’URL détournée), le fichier servi peut être remplacé par du code malveillant — qui s’exécute alors dans ton origine (XSS à l’échelle, vol de données). Tu n’as aucun contrôle sur ce que le CDN sert au moment du chargement.

SRI (Subresource Integrity) résout ça : tu déclares l’empreinte cryptographique attendue du fichier dans l’attribut integrity. Le navigateur calcule l’empreinte du fichier reçu et le rejette s’il ne correspond pas.


<!-- Le navigateur verifie l'empreinte ; si le fichier CDN est altere, il est REJETE -->
<script
  src="https://cdn.example/lib@1.2.3/lib.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Si le contenu ne produit pas exactement l’empreinte sha384-... déclarée, le navigateur n’exécute pas le fichier. Un CDN piraté servant un script modifié est donc neutralisé. SRI s’applique aux ressources <script> et <link rel="stylesheet"> chargées en cross-origin.

💡 Réflexe — Pour toute ressource critique chargée depuis un domaine que tu ne contrôles pas (CDN de librairie), ajoute un integrity (SRI). Mieux encore quand c’est possible : héberge toi-même les dépendances front (les bundler dans ton build plutôt que de dépendre d’un CDN tiers) — tu supprimes la dépendance à l’intégrité et à la disponibilité d’un tiers, et c’est cohérent avec une CSP stricte (Partie 7). SRI est la parade quand tu dois charger depuis un CDN.

Provenance : d’où vient cet artefact ?

La provenance répond à la question « qui a construit cet artefact, à partir de quel code source, par quel pipeline ? ». C’est une réponse à un maillon faible de la supply chain : on installe des paquets/binaires pré-construits sans preuve qu’ils correspondent au code source public annoncé (un attaquant pourrait publier un binaire piégé ne correspondant pas au dépôt).

Les mécanismes de provenance produisent des attestations signées liant un artefact à sa source et à son build (par ex. « ce paquet a été construit par tel pipeline CI, depuis tel commit du dépôt officiel »). Des initiatives et cadres (signatures de paquets, attestations de build, référentiels comme SLSA) visent à rendre cette chaîne vérifiable. Concrètement pour un dev :

Privilégier les paquets/artefacts qui publient une provenance vérifiable.
Signer ses propres artefacts et releases (pour que tes consommateurs vérifient).
Vérifier les signatures quand elles existent (paquets signés, images de conteneurs signées — Partie 14).

C’est un domaine en maturation ; le principe à retenir : ne pas exécuter un artefact dont on ne peut pas relier l’origine au code source de confiance.

SBOM : l’inventaire de ce que tu embarques

Un SBOM (Software Bill of Materials) est la liste complète des composants qui composent ton logiciel : chaque dépendance (directe et transitive), sa version, sa licence, parfois son empreinte. C’est l’équivalent d’une « liste d’ingrédients » du logiciel.

Pourquoi c’est crucial pour la sécurité : quand une nouvelle CVE est publiée sur un composant (« la version X de la lib Y est vulnérable »), la première question est « suis-je concerné, et où ? ». Sans inventaire, y répondre sur des dizaines de services et des centaines de dépendances transitives est un cauchemar. Avec un SBOM à jour, on interroge l’inventaire et on sait immédiatement quels de tes systèmes embarquent le composant vulnérable — donc quoi patcher, en priorité.


# Generer un SBOM (exemples d'outils) : format standard (CycloneDX, SPDX)
# des outils dedies scannent le projet et produisent l'inventaire des composants

Générer un SBOM (formats standard : CycloneDX, SPDX) dans le pipeline de build, à jour à chaque release.
Le conserver et pouvoir le requêter (quel service utilise quelle version de quoi ?).
L’utiliser lors d’une CVE ou d’un incident supply chain pour évaluer l’exposition rapidement.

🎯 Côté attaquant — L’attaquant supply chain exploite le manque de visibilité : il sait que beaucoup d’organisations ignorent ce qu’elles embarquent précisément (dépendances transitives), ne vérifient pas l’intégrité des ressources CDN, et ne peuvent pas dire rapidement si elles sont touchées par une nouvelle CVE. Un CDN compromis servant un script piégé (sans SRI), un artefact sans provenance, une organisation sans SBOM qui met des semaines à savoir si elle est concernée : autant de fenêtres d’exploitation. La visibilité (SBOM), l’intégrité (SRI) et la provenance referment ces fenêtres.

🧭 Sur FormaCampus — FormaCampus limite sa dépendance aux CDN externes (elle bundle ses libs front dans son build, cohérent avec sa CSP stricte — Partie 7) et, pour les rares ressources CDN, ajoute SRI (integrity). Son pipeline CI génère un SBOM (CycloneDX) à chaque release, conservé et requêtable : quand une CVE est publiée, l’équipe sait en minutes quels services embarquent le composant vulnérable. Les images de conteneurs sont signées (provenance — Partie 14), et l’équipe privilégie les dépendances offrant une provenance vérifiable. Intégrité (SRI), origine (provenance) et inventaire (SBOM) complètent l’audit (12.1) et le verrouillage (12.2) pour une supply chain maîtrisée.

✏️ Exercices

Exercice 1 — Ajoute SRI (ou mieux). Un site charge une librairie de graphiques depuis un CDN public : <script src="https://cdn.example/chart.js"></script>. Quel est le risque, et quelles deux améliorations proposes-tu ?

✅ Solution

Risque : si le CDN est compromis (ou l’URL détournée), le fichier servi peut être remplacé par du code malveillant qui s’exécute dans ton origine (vol de données, XSS massif) — tu n’as aucun contrôle sur ce que le CDN sert au chargement. Améliorations : (1) Ajouter SRI — un attribut integrity="sha384-..." (+ crossorigin) avec l’empreinte attendue du fichier ; le navigateur rejette tout fichier altéré. (2) Mieux : héberger la librairie toi-même (la bundler dans ton build), ce qui supprime la dépendance à l’intégrité et à la disponibilité du CDN tiers, et s’aligne avec une CSP stricte (Partie 7 — script-src 'self'). SRI est la parade quand on doit charger depuis un CDN ; l’auto-hébergement est encore plus robuste.

Exercice 2 — L’utilité du SBOM. Une CVE critique est publiée sur une version d’une bibliothèque de logs très répandue. Pourquoi une organisation avec un SBOM à jour répond-elle bien plus vite qu’une sans ?

✅ Solution

Avec un SBOM à jour (inventaire de tous les composants et versions, y compris transitifs, de chaque service), l’organisation interroge son inventaire et sait immédiatement quels systèmes embarquent la version vulnérable — même en dépendance transitive profonde qu’elle n’a pas choisie directement. Elle peut donc prioriser et patcher rapidement, précisément là où c’est nécessaire. Sans SBOM, il faut inspecter manuellement des dizaines de services et des centaines de dépendances transitives pour déterminer l’exposition — un travail long et incertain, pendant lequel la fenêtre d’exploitation reste ouverte (l’incident réel d’une célèbre lib de logs a illustré ce cauchemar). Le SBOM transforme « on ne sait pas si on est touchés » en « voici exactement où, patchons ». C’est la visibilité qui permet la vitesse de réaction.

🧠 Quiz de révision

1. Que fait SRI et contre quoi protège-t-il ?

SRI (integrity="sha384-...") fait vérifier par le navigateur l’empreinte d’une ressource chargée depuis un CDN externe : si le fichier est altéré (CDN compromis, URL détournée), il est rejeté (non exécuté). Il protège contre l’exécution d’un script/style tiers modifié dans ton origine.

2. Quelle alternative est encore plus robuste que SRI pour les libs front ?

Héberger soi-même les dépendances (les bundler dans son build) plutôt que de dépendre d’un CDN tiers : cela supprime la dépendance à l’intégrité et à la disponibilité du tiers, et s’aligne avec une CSP stricte (script-src 'self'). SRI reste la parade quand on doit charger depuis un CDN.

3. Qu’est-ce que la provenance dans la supply chain ?

La preuve d’où vient un artefact : qui l’a construit, depuis quel code source, par quel pipeline, via des attestations signées. Elle répond au risque d’installer un binaire pré-construit ne correspondant pas au code source annoncé. Principe : ne pas exécuter un artefact qu’on ne peut pas relier à une source de confiance.

4. Qu’est-ce qu’un SBOM et à quoi sert-il ?

Un SBOM (Software Bill of Materials) est l’inventaire complet des composants d’un logiciel (chaque dépendance directe et transitive, avec version). Il sert à répondre rapidement, quand une CVE tombe, à « suis-je concerné et où ? » — donc à prioriser le patching. Formats standard : CycloneDX, SPDX.

5. Comment SRI, provenance et SBOM se complètent-ils ?

Ils couvrent trois questions distinctes : SRI = « ce que je charge est-il intègre ? » (empreinte vérifiée) ; provenance = « d’où vient cet artefact ? » (attestations signées liant l’artefact à sa source/son build) ; SBOM = « qu’est-ce que j’embarque ? » (inventaire des composants, pour évaluer l’exposition à une CVE). Vérifier, tracer, inventorier — ensemble, ils referment les fenêtres qu’exploite l’attaquant supply chain, en complément de l’audit (12.1) et du verrouillage (12.2).

Fin de la Partie 12. La supply chain est maîtrisée : audit des CVE, verrouillage et vigilance anti-typosquatting, intégrité (SRI), provenance et inventaire (SBOM). On passe à un autre actif transversal à protéger : la Partie 13 — Secrets & données sensibles.