Gérer les risques tiers et la chaîne logicielle

Une dépendance logicielle, un fournisseur de service ou une image de conteneur deviennent une partie du système de sécurité dès leur admission. Le compromis central est brutal : accélérer l’adoption de composants externes réduit le coût de développement, mais transfère aussi du risque hors du périmètre de contrôle direct. La bonne position consiste à accepter ce transfert seulement quand la provenance, l’exploitabilité et la révocation restent vérifiables.

→ Lire l’explication complète de la marmotte

Cartographie des tiers et dépendances critiques

Un tiers ne se limite pas au prestataire qui signe un contrat. Une bibliothèque installée par un gestionnaire de paquets, une action d’intégration continue, un registre d’images, un fournisseur d’identité ou un service de télémétrie sont des tiers. Chacun peut introduire du code, accéder à des données, héberger des secrets ou interrompre une chaîne de livraison.

La première exigence est un inventaire relié aux actifs, pas une liste de fournisseurs tenue par les achats dans un tableur fossilisé. Pour chaque dépendance, conserver au minimum : propriétaire métier et technique, version exacte, origine de téléchargement, empreinte cryptographique, droits accordés, données accessibles, criticité métier, chemin de mise à jour et solution de repli.

Une nomenclature des composants logiciels, ou SBOM (Software Bill of Materials), documente les composants inclus dans un livrable. Elle devient exploitable seulement si elle est produite à chaque build, attachée à l’artefact et corrélée à l’environnement déployé. Une SBOM générée une fois par trimestre décrit surtout l’archéologie applicative. Elle ne permet pas de répondre à une compromission de dépendance.

Le modèle de criticité doit distinguer trois dimensions :

Impact : capacité d’un tiers à lire, modifier ou bloquer une fonction métier.
Exposition : accessibilité depuis Internet, présence dans un environnement de production ou privilèges détenus.
Substituabilité : possibilité réaliste de retirer ou remplacer le composant sans reconstruire l’architecture.

Une bibliothèque de journalisation sans accès réseau n’a pas le même traitement qu’un fournisseur d’identité fédérée. À l’inverse, une dépendance minuscule exécutée au build avec un jeton de déploiement mérite une attention disproportionnée. Le code le plus court peut ouvrir la porte la plus longue.

La gouvernance de sécurité doit imposer un propriétaire par dépendance critique. Une responsabilité collective sans nom devient rapidement une responsabilité fantôme, très populaire dans les présentations et absente lors de la révocation.

Admission des composants et preuves de provenance

L’admission doit reposer sur une politique exécutable. Autoriser un registre public, puis espérer que les équipes lisent la politique de sécurité du paquet avant installation, revient à placer un panneau “terrain glissant” au fond d’une piscine.

La politique doit contrôler quatre propriétés distinctes :

Identité de l’émetteur : le composant provient d’un compte, d’une organisation ou d’une chaîne de build identifiée.
Intégrité : l’empreinte du composant téléchargé correspond à celle déclarée ou signée.
Provenance : une attestation indique quel dépôt source, quel commit, quel pipeline et quels paramètres ont produit l’artefact.
Éligibilité : la version respecte les règles internes de licence, de vulnérabilités, de maintenance et de support.

SLSA (Supply-chain Levels for Software Artifacts) fournit un cadre de maturité pour la provenance des artefacts. Son intérêt n’est pas d’obtenir un badge de plus dans une slide. Il force à séparer le dépôt de code, la plateforme de build et la publication des artefacts, afin qu’un vol de compte développeur ne suffise pas à publier un binaire arbitraire.

Une signature d’artefact prouve qu’une clé a signé un contenu. Elle ne prouve ni que le code est sûr, ni que le signataire est légitime, ni que la clé n’a pas été volée. La vérification doit donc lier la signature à une identité attendue, à un dépôt précis et à une politique de publication. Une signature sans politique est un tampon dont personne ne vérifie la date.

Pour les images de conteneurs, interdire les références flottantes telles que latest. Déployer par digest, c’est-à-dire par empreinte immuable du contenu. Un tag est un pointeur modifiable ; le digest identifie le contenu réel. Cette contrainte casse certains processus de promotion improvisés, ce qui est précisément son métier.

La chaîne de développement doit aussi isoler les secrets de publication. Un jeton de registre ne doit jamais être disponible à une étape qui exécute du code non fiable, par exemple une contribution externe ou une génération de documentation avec extensions téléchargées. Les plateformes d’intégration continue adorent mélanger build, test et publication dans un même jeton omnipotent. Les attaquants apprécient également cette ergonomie.

Exemple de vérification d’une image signée

L’exemple suivant utilise Cosign pour vérifier une image de conteneur avant admission. Il exige Cosign 2.x, une identité OpenID Connect, ou OIDC (OpenID Connect), configurée chez l’émetteur, et un registre accessible depuis l’environnement de vérification. L’image est référencée par digest afin d’interdire toute substitution par déplacement de tag.

# Installer cosign 2.x depuis la distribution validée par l'organisation.
# La variable IMAGE contient un digest immuable, jamais un tag mutable.
IMAGE="registry.example.net/paiement/api@sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

# Vérifier la signature et contraindre l'identité du workflow de publication.
# Le certificat doit provenir de l'émetteur OIDC attendu et du dépôt autorisé.
cosign verify \
  --certificate-identity-regexp='https://github\.com/exemple/paiement/\.github/workflows/release\.yml@refs/tags/v[0-9].*' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  "$IMAGE"

# Refuser le déploiement si la commande échoue.
# Le code de retour doit être testé par le pipeline, pas seulement affiché.
test $? -eq 0

Cette vérification ne remplace pas le contrôle de vulnérabilités. Elle répond à une autre question : « qui a produit ce contenu et par quel processus ? ». Une analyse de vulnérabilités répond plutôt : « que connaît-on des défauts publiés de ses composants ? ». Confondre les deux produit un contrôle incomplet avec un tableau de bord très coloré.

Surface d’attaque de la chaîne d’approvisionnement

L’attaque la plus rentable vise souvent le point de distribution plutôt que chaque cible finale. Un compte de mainteneur compromis, un paquet homonyme, une dépendance transitive abandonnée ou une action de pipeline altérée peuvent propager du code malveillant avec la légitimité de la mise à jour ordinaire.

Le typosquatting exploite les erreurs de nommage, par exemple un paquet dont le nom ressemble à une dépendance connue. La contre-mesure n’est pas la vigilance humaine, qui reste une ressource rare et périssable. Il faut déclarer des registres autorisés, verrouiller les versions et empreintes dans les fichiers de verrouillage, puis bloquer les sources non approuvées au niveau du proxy de paquets.

La substitution de version exploite les dépendances ouvertes, telles que ^1.2.0 ou >=1.2. Ces plages facilitent les mises à jour, mais permettent aussi l’introduction silencieuse d’une version inattendue. En production, retenir des versions exactes et promouvoir un artefact déjà validé entre environnements. Le compromis est assumé : plus de discipline de mise à jour, moins de surprises durant un incident.

La compromission du pipeline vise les secrets et les permissions. Un attaquant qui modifie un script de build peut exfiltrer un jeton, signer un artefact ou injecter une porte dérobée. Séparer les identités de lecture, build, signature et déploiement limite le mouvement latéral. Les jetons doivent être à durée de vie courte, liés à une charge de travail et limités à une audience précise. Un secret statique dans une variable de pipeline est une dette avec accès administrateur.

Une vulnérabilité connue, identifiée par un CVE (Common Vulnerabilities and Exposures), ne justifie pas automatiquement un arrêt de production. Évaluer l’exploitabilité réelle : composant chargé ou non, fonction vulnérable accessible ou non, configuration concernée, privilèges nécessaires et présence de mesures compensatoires. Un VEX (Vulnerability Exploitability eXchange) peut consigner cette analyse, mais ne doit pas servir de permis de fermeture des yeux.

Exploitation, révocation et reprise fournisseur

La sécurité de chaîne logicielle échoue si la réaction à l’incident dépend d’une recherche manuelle dans les journaux. Conserver les attestations, SBOM, signatures, journaux de build et décisions d’admission pendant une durée cohérente avec la durée de vie des livrables. Sans cette rétention, il devient impossible d’établir quels systèmes exécutent un composant compromis.

La rotation des clés de signature doit accepter la coexistence temporaire de plusieurs clés approuvées. Retirer une clé compromise exige ensuite trois opérations séparées : bloquer toute nouvelle signature, révoquer son identité dans la politique et identifier les artefacts déjà admis. La révocation n’efface pas les images déjà téléchargées ni les charges déjà lancées. Les plateformes promettent parfois ce miracle avec assez de mots anglais ; la physique du cache reste moins coopérative.

La supervision doit produire des alertes sur les événements suivants : publication depuis une identité inhabituelle, échec de vérification de signature, téléchargement depuis un registre non autorisé, modification de politique, dépendance sans mainteneur actif et expiration prochaine d’un certificat de signature. Les alertes sans procédure de confinement associée deviennent une collection d’alarmes décoratives.

Un fournisseur critique doit avoir un scénario de sortie testé : export des données, formats réutilisables, remplacement de l’authentification, délais de bascule, dépendances contractuelles et responsabilités de notification. Ce n’est pas du conseil juridique ; c’est une exigence d’architecture. Le risque tiers ne disparaît pas dans un contrat, il change seulement d’étagère.

🐝 Ce qui arrive si on s’en passe

Sans admission contrôlée ni inventaire lié aux artefacts déployés, la question « cette version est-elle concernée ? » n’a plus de réponse tenable : chaque annonce de faille impose un recensement manuel, et le délai de confinement se mesure en jours plutôt qu’en minutes. L’absence d’attestation de provenance rend indécidable la distinction entre une mise à jour légitime et une republication sous une identité volée ; le déploiement continue alors sans obstacle. Faute de versions figées et de digests, deux environnements réputés identiques exécutent des contenus différents, ce qui invalide les tests de non-régression comme les preuves d’audit. Enfin, sans rétention des journaux de build et des signatures, la reprise se limite à tout reconstruire à l’aveugle, sans pouvoir démontrer que le composant compromis a réellement disparu du parc.

🦫 Explication de la marmotte 🍫

Un logiciel moderne contient souvent du code écrit par d’autres personnes ou fourni par des entreprises extérieures. Il peut aussi être fabriqué et distribué par des services en ligne. Chaque élément externe peut contenir une erreur, être modifié par un pirate ou devenir indisponible.

Pour réduire ce risque, il faut d’abord tenir une liste des éléments utilisés dans chaque version du logiciel. Cette liste indique leur origine, leur version et leur rôle. Quand une faille est annoncée, elle permet de retrouver les logiciels concernés au lieu de chercher au hasard.

Avant d’accepter un nouveau composant, le système vérifie son origine et son contenu. Une preuve de fabrication indique quel code a servi, quel outil a fabriqué le résultat et quelle identité l’a publié. Une signature numérique permet de détecter une modification après publication, mais elle ne garantit pas que le contenu est sans défaut.

Les programmes doivent être téléchargés depuis des sources autorisées et avec une version précise. Les droits donnés aux outils de fabrication doivent être limités : un outil qui teste du code ne doit pas pouvoir publier une nouvelle version officielle.

Quand une clé de signature, un compte ou un fournisseur est compromis, il faut bloquer les nouvelles publications, retrouver les versions déjà utilisées, retirer celles qui sont dangereuses et les remplacer. Des journaux conservés et des alertes permettent de savoir quoi arrêter et quoi corriger.

Pages voisines

La citent

Gérer les risques tiers et la chaîne logicielle

Elle cite

Gérer les risques tiers et la chaîne logicielle

Gérer les risques tiers et la chaîne logicielle

Cartographie des tiers et dépendances critiques

Admission des composants et preuves de provenance

Exemple de vérification d’une image signée

Surface d’attaque de la chaîne d’approvisionnement

Exploitation, révocation et reprise fournisseur

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines