Attaques de la chaîne d'approvisionnement
Une chaîne d'approvisionnement logicielle consiste en l'ensemble des logiciels et outils utilisés pour créer et maintenir un produit logiciel. Cela inclut non seulement les logiciels développés pour le produit lui-même, mais aussi tous les logiciels et outils utilisés dans sa production.
Dans une attaque de la chaîne d'approvisionnement (supply chain attack en anglais), l'attaquant·e cible une partie de la chaîne d'approvisionnement du produit afin de compromettre le produit lui-même.
L'exemple le plus évident est une bibliothèque tierce. Si vous utilisez, par exemple, un paquet npm (angl.) développé par un tiers, il peut compromettre votre site. Cela peut se faire délibérément, s'il est malveillant, ou accidentellement, s'il contient des vulnérabilités involontaires. Essentiellement, vous devez faire confiance à vos dépendances tierces autant qu'à votre propre code.
De manière moins évidente, le même principe s'applique à tous les outils que vous utilisez pour créer votre logiciel, y compris les éditeurs de code, les plugins d'éditeur, les systèmes de contrôle de version, les outils de compilation, et ainsi de suite. Chacun de ces outils peut insérer du code malveillant ou vulnérable dans votre produit logiciel final, au cours des transformations qu'il applique.
Dans ce document, nous allons présenter les pratiques à suivre pour sécuriser votre chaîne d'approvisionnement logicielle. Il est organisé en deux sections principales :
- Sécuriser votre environnement de développement : pratiques pour s'assurer que votre propre code n'est pas compromis.
- Gérer les dépendances tierces : pratiques pour s'assurer que vos dépendances ne sont pas compromises.
Sécuriser votre environnement de développement
Une voie pour une attaque de la chaîne d'approvisionnement consiste à ce qu'un·e attaquant·e introduise des vulnérabilités ou du code malveillant directement dans votre propre produit. En général, un·e attaquant·e fait cela en compromettant le compte d'un·e mainteneur·euse de projet, ou en exploitant des faiblesses dans les outils de développement utilisés par les mainteneur·euse·s.
Notre guide sur la sécurité opérationnelle décrit les pratiques pour contrer ces menaces, notamment :
Gérer les dépendances tierces
Les dépendances tierces incluent non seulement les bibliothèques et cadriciels que votre code utilise, mais également tous les outils tiers impliqués dans le processus de développement, y compris les éditeurs, les IDE, les systèmes de contrôle de version, les gestionnaires de paquets et les outils de compilation.
Les attaquant·e·s peuvent compromettre votre projet en exploitant les faiblesses de ces dépendances. Notre guide sur la sécurité opérationnelle décrit les pratiques pour contrer ces menaces, notamment :
- Évaluer les nouvelles dépendances
- Mettre à jour les dépendances existantes
- Maintenir une liste des composants logiciels (SBOM)
De plus, les projets doivent utiliser l'intégrité des ressources externes pour les scripts et les feuilles de style hébergés par un site tiers.
Utiliser l'intégrité des ressources externes
De nombreux sites Web incluent des scripts hébergés à l'extérieur : notamment, mais pas exclusivement, des scripts servis depuis un Content Delivery Network (CDN) :
<script src="https://cdn.example.org/library.js"></script>
Cela représente un risque pour votre chaîne d'approvisionnement : si un·e attaquant·e parvient à prendre le contrôle du domaine cdn.example.org, il ou elle peut remplacer le script par un script malveillant et ainsi compromettre votre site.
Les scripts externes, comme les autres dépendances logicielles, doivent faire partie de votre SBOM, mais une défense supplémentaire consiste à définir l'attribut integrity du script :
<script
src="https://cdn.example.org/library.js"
integrity="sha256-d5f450f7ce715d827de27ca569e183f819d33c1e7601875fd61eccbc98f56c5b"></script>
La valeur de cet attribut contient un hachage cryptographique du contenu du script. Si le script a été modifié par un·e attaquant·e, le navigateur refuse de le charger, et vous êtes protégé·e.
Cela ajoute effectivement une charge de maintenance supplémentaire : chaque fois que la source change (par exemple, à chaque nouvelle version publiée), vous devez mettre à jour la valeur de l'attribut dans votre code.
L'élément HTML <link> prend également en charge l'attribut integrity, vous pouvez donc (et devez) l'utiliser pour les feuilles de style CSS ainsi que pour les scripts.
Voir l'intégrité des ressources externes pour plus de détails.
Liste de contrôle récapitulative de la défense
- Suivre les pratiques de sécurité opérationnelle pour :
- Utiliser l'intégrité des ressources externes pour les scripts et les feuilles de style référencés de manière externe.