Sécurité de la chaîne d'approvisionnement : dépendances, packages et intégration tierce

La chaîne d'approvisionnement logicielle englobe tout ce qui compose un logiciel au-delà du code de l'équipe de développement : dépendances open source, outils de build et de CI/CD, images de conteneurs, plugins d'IDE, intégrations tierces. Une compromission à n'importe quel maillon de cette chaîne peut introduire du code malveillant dans des logiciels qui n'ont eux-mêmes aucune vulnérabilité. Les attaques contre la chaîne d'approvisionnement sont particulièrement difficiles à détecter car elles passent par des canaux de confiance.

Dépendances compromises

Les incidents de dépendances compromises sont devenus fréquents. event-stream (npm, 2018) : un mainteneur transfère le package à un attaquant qui ajoute du code malveillant ciblant des portefeuilles Bitcoin. XZ Utils (2024) : un contributeur infiltre le projet pendant deux ans avant d'introduire une backdoor dans le démon SSH via une dépendance de compression. polyfill.io (2024) : un CDN populaire est racheté et commence à distribuer du code malveillant à des millions de sites. Colors et faker.js (2022) : un mainteneur sabote délibérément ses propres packages.

Typosquatting de packages

Le typosquatting consiste à publier un package malveillant avec un nom similaire à un package légitime populaire. Un développeur qui fait une faute de frappe en installant une dépendance peut installer le package malveillant. Des exemples réels : lodash vs lo-dash, cross-env vs crossenv, express vs expres. Ces packages malveillants exécutent généralement du code lors de l'installation (postinstall dans package.json).

Dependency confusion

La dependency confusion exploite la façon dont les gestionnaires de packages résolvent les dépendances entre registres publics et privés. Si une organisation utilise un registre privé (Artifactory, Azure Artifacts) avec des packages internes, et qu'un attaquant publie un package du même nom sur le registre public npm/PyPI/NuGet avec un numéro de version plus élevé, certains gestionnaires de packages peuvent privilégier le package public. Le chercheur Alex Birsan a démontré cette attaque en 2021 contre des dizaines d'entreprises.

SBOM et gestion des vulnérabilités de dépendances

Un SBOM (Software Bill of Materials) est un inventaire exhaustif de toutes les composantes d'un logiciel. Il permet de savoir rapidement si une vulnérabilité CVE publiée affecte l'un des composants utilisés. Les outils d'analyse de composition logicielle (SCA) comme Dependabot (GitHub), Snyk ou OWASP Dependency-Check automatisent la détection des dépendances vulnérables.

Audit des dépendances vulnérables

# npm : audit des vulnérabilités
npm audit
npm audit fix  # Corriger automatiquement

# Python
pip-audit

# Générer un SBOM (CycloneDX)
cyclonedx-py requirements requirements.txt

# Verrouiller les versions exactes
npm ci  # Utilise package-lock.json (versions exactes)
# Au lieu de npm install (peut installer des versions différentes)

Intégrations tierces

Les scripts tiers chargés depuis des CDN externes (analytics, chat, cartes) représentent un risque de chaîne d'approvisionnement. Un script tiers compromis s'exécute avec tous les droits de la page hôte : il peut lire le DOM, envoyer des formulaires, accéder aux cookies (si non HttpOnly) et exfiltrer des données. La protection : utiliser Subresource Integrity (SRI) pour les scripts externes, héberger les scripts critiques soi-même, et utiliser une CSP stricte.

Subresource Integrity (SRI) pour les scripts externes

<!-- Le navigateur vérifie que le hash du script téléchargé correspond -->
<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

<!-- Si le hash ne correspond pas (script modifié), le navigateur bloque l'exécution -->