Le code que vous n'écrivez pas, vous l'achetez ou vous l'importez : c'est du risque que vous ne contrôlez pas directement. Le domaine Fournisseurs & composants tiers (FRN) traite ce risque importé, qu'il vienne d'un éditeur commercial, d'un prestataire ou d'un composant tiers.
Vous héritez de la sécurité de chaque tiers dont vous dépendez : son cycle de développement, son hygiène open source, sa capacité à notifier un incident. Sans tiering par criticité, vous traitez un composant critique comme un gadget ; sans clauses contractuelles, vous n'avez aucun levier quand l'incident survient ; sans SBOM ni attestation, vous ne savez pas ce que vous déployez. La parade se décline tout au long du cycle de vie, en six familles : le tiering et l'évaluation initiale, le contrat (clauses de sécurité, droit d'audit, notification d'incident, conformité CRA/NIS2), le développement sécurisé du fournisseur (référentiel SSDF), la provenance et l'intégrité des livrables (SBOM par livraison, signature, vérification à la réception), la continuité (support, fin de vie annoncée, réversibilité) et la souveraineté (localisation des données, qualification SecNumCloud).
Concrètement, ces exigences parent : le fournisseur compromis qui ne vous prévient pas faute de clause, le livrable substitué non vérifié à la réception, la dépendance OSS piégée, le produit en fin de vie sans correctifs, et la perte de souveraineté sur des données hébergées hors UE. Cette page couvre les 24 exigences SOCLE du domaine, des fondamentales (R1) aux souveraines (R3).
Le risque importé : un fournisseur compromis devient votre compromission (cf. SolarWinds).
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Les exigences essentielles
Section intitulée « Les exigences essentielles »Quatre exigences forment la base : tiering des fournisseurs par criticité, évaluation de sécurité proportionnée des critiques, SBOM et attestations exigés, et clauses contractuelles de sécurité et de notification d'incident.
tiering des fournisseurs et composants tiers par criticité.#
On ne peut pas surveiller tous ses fournisseurs avec la même intensité : sans tiering par criticité, l'effort se disperse et le prestataire vraiment critique reçoit la même attention qu'un outil marketing. Classer par criticité concentre les exigences (audit, SBOM, notification) là où une défaillance ferait le plus mal.
- Preuve attendue
- Tiering des fournisseurs et composants tiers par criticité.
Correspondances & menaces parées 2 standards · 3 menaces
Une personne disposant légitimement du droit de publier (mainteneur, éditeur) introduit volontairement une modification nuisible dans le code ou l'artefact. L'attaque vient de l'intérieur de la chaîne de confiance : ni la revue ni la signature ne la détectent, puisque l'auteur est autorisé. Cas typiques : rachat de paquet, compte de mainteneur revendu, contributeur de longue date devenu hostile SLSA (A) CNCF Malicious Maintainer. Le mainteneur saborde délibérément son propre composant pour des raisons idéologiques ou politiques (protestware) : code destructeur, messages, ou comportements ciblant certains utilisateurs. La confiance accordée au paquet se retourne contre ses consommateurs lors d'une simple mise à jour (cas node-ipc) CNCF Malicious Maintainer SoK. Une dépendance est retirée ou dépubliée (unpublish, yank), cassant les builds et poussant à des substitutions hâtives, parfois vers un remplacement malveillant. La disponibilité de la chaîne est attaquée (cas left-pad) SLSA (disponibilité).
évaluation de sécurité proportionnée des fournisseurs critiques.#
Intégrer un fournisseur critique sans l'évaluer, c'est hériter de ses failles à l'aveugle : sa dette de sécurité devient la vôtre. Une évaluation proportionnée (questionnaire, preuves, certifications) avant l'engagement révèle les écarts pendant qu'on peut encore négocier ou renoncer, pas une fois captif.
- Preuve attendue
- Dossiers d'évaluation de sécurité des fournisseurs critiques.
Correspondances & menaces parées 3 standards · 2 menaces
Une personne disposant légitimement du droit de publier (mainteneur, éditeur) introduit volontairement une modification nuisible dans le code ou l'artefact. L'attaque vient de l'intérieur de la chaîne de confiance : ni la revue ni la signature ne la détectent, puisque l'auteur est autorisé. Cas typiques : rachat de paquet, compte de mainteneur revendu, contributeur de longue date devenu hostile SLSA (A) CNCF Malicious Maintainer. Une application OAuth ou intégration SaaS de confiance, au-delà du SCM/CI (CRM, support, observabilité), est compromise ou abusée : consentement OAuth détourné, jetons volés, contournement MFA, pour persister et exfiltrer des données (ex. campagne Salesloft/Drift 2025). La confiance accordée à une intégration tierce devient un accès latéral au SI ATT&CK T1671 OWASP CICD-SEC-8.
SBOM et attestations exigés des fournisseurs critiques.#
Sans SBOM fourni, vous ignorez ce que contient le composant tiers déployé : une faille comme Log4Shell vous laisse incapable de répondre à « suis-je exposé ? ». Exiger le SBOM et les attestations des fournisseurs critiques déplace cette visibilité dans le contrat, avant l'incident.
- Preuve attendue
- SBOM et attestations obtenus des fournisseurs critiques.
Correspondances & menaces parées 3 standards · 2 menaces
La charge malveillante n'est pas dans la dépendance directe mais dans une dépendance de dépendance, invisible sans analyse du graphe complet. La profondeur de l'arbre de dépendances masque l'origine du risque SLSA (dépendances). Le canal par lequel le logiciel est distribué (site de téléchargement, CDN, miroir, mise à jour) est compromis pour livrer une version trojanisée aux utilisateurs finaux. La compromission frappe en aval de la production, au plus près des victimes SLSA (G).
clauses contractuelles de sécurité et de notification d'incident.#
Si rien n'est écrit au contrat, le fournisseur n'a aucune obligation de vous prévenir quand il est compromis, et vous l'apprenez par la presse. Des clauses de sécurité et un devoir de notification transforment des attentes implicites en engagements opposables, alignés sur CRA et NIS2.
- Preuve attendue
- Clauses contractuelles de sécurité et de notification d'incident.
Correspondances & menaces parées 3 standards · 1 menace
Le canal par lequel le logiciel est distribué (site de téléchargement, CDN, miroir, mise à jour) est compromis pour livrer une version trojanisée aux utilisateurs finaux. La compromission frappe en aval de la production, au plus près des victimes SLSA (G).
gouvernance des autorisations OAuth des applications SaaS tierces (CRM, support, marketing) au-delà du SCM/CI : consentements au moindre privilège, inventaire des octrois à l'échelle du tenant, révocation et rotation des jetons de rafraîchissement.#
Une application SaaS tierce (CRM, support) dotée d'un jeton OAuth à portée large devient un angle mort : compromise, elle atteint vos données sans toucher à votre SCM. Inventorier les octrois à l'échelle du tenant, imposer le moindre privilège et savoir révoquer ferme cette porte latérale (CICD-SEC-8).
- Preuve attendue
- Inventaire des applications OAuth autorisées au niveau tenant (portées, propriétaire) ; procédure de révocation testée ; rotation des refresh tokens.
- Outillage
- ScoutSuite Prowler
Correspondances & menaces parées 3 standards · 1 menace
Une application OAuth ou intégration SaaS de confiance, au-delà du SCM/CI (CRM, support, observabilité), est compromise ou abusée : consentement OAuth détourné, jetons volés, contournement MFA, pour persister et exfiltrer des données (ex. campagne Salesloft/Drift 2025). La confiance accordée à une intégration tierce devient un accès latéral au SI ATT&CK T1671 OWASP CICD-SEC-8.
Les familles de ce domaine
Section intitulée « Les familles de ce domaine »Le détail est organisé par famille de contrôle. Chaque famille a sa page dédiée.
À retenir
Section intitulée « À retenir »- Vous héritez de la sécurité de chaque fournisseur : son risque devient le vôtre.
- Les essentielles : tiering par criticité, évaluation, SBOM/attestations, clauses contractuelles.
- Le contrat est un outil de sécurité : audit, notification, conformité CRA/NIS2.
- Exigez les mêmes preuves d'un fournisseur que vous produisez vous-même (SBOM, signatures, provenance).
- Anticipez la fin : support, réponse à incident, réversibilité et sortie.