Votre équipe utilise une nouvelle librairie open source. Le RSSI demande “vous avez évalué le risque fournisseur ?”. Vous répondez “c’est open source, y’a pas de fournisseur”. Sauf que le mainteneur unique vient de passer la main à un inconnu, et le package a 50 millions de téléchargements par mois.
Le TPRM (Third-Party Risk Management) n’est plus un sujet réservé aux achats ou à la GRC. Chaque fois qu’une équipe intègre un SaaS, une API, une librairie ou un prestataire ayant accès à ses systèmes, elle introduit un risque tiers dans son système d’information.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce qu’est le TPRM et pourquoi les équipes techniques sont concernées
- Comment évaluer rapidement un fournisseur ou composant externe
- Les questions techniques essentielles à poser et les preuves à demander
- Comment scorer et prioriser vos fournisseurs selon leur criticité
Prérequis
Section intitulée « Prérequis »- Notions de base sur la supply chain security
- Compréhension des enjeux de sécurité applicative
Qu’est-ce que le TPRM (Third-Party Risk Management) ?
Section intitulée « Qu’est-ce que le TPRM (Third-Party Risk Management) ? »Définition simple
Section intitulée « Définition simple »Le TPRM (Third-Party Risk Management) est l’ensemble des pratiques permettant d’identifier, évaluer et gérer les risques liés aux tiers avec lesquels vous travaillez :
- Fournisseurs SaaS : les services cloud que vous intégrez (Auth0, Stripe, Datadog, etc.)
- Librairies et packages : les dépendances open source ou propriétaires
- Prestataires : infogérants, développeurs externes, ESN
- APIs tierces : services d’enrichissement de données, paiement, notification
Pourquoi les équipes techniques sont concernées
Section intitulée « Pourquoi les équipes techniques sont concernées »Traditionnellement, le TPRM était géré par les équipes achats ou GRC. Mais la réalité a changé :
| Avant | Maintenant |
|---|---|
| L’achat d’un logiciel passe par les achats | Un npm install suffit pour ajouter une dépendance |
| Le contrat cadre le risque | Le code open source n’a pas de contrat |
| On évalue avant d’acheter | On découvre les dépendances transitives après |
| Quelques fournisseurs stratégiques | Des centaines de dépendances par projet |
Le problème : les équipes techniques prennent des décisions d’intégration (SaaS, packages, APIs) sans toujours évaluer le risque fournisseur associé.
Les risques concrets d’une mauvaise gestion des tiers
Section intitulée « Les risques concrets d’une mauvaise gestion des tiers »| Risque | Exemple réel | Impact |
|---|---|---|
| Compromission fournisseur | SolarWinds (2020) | Supply chain attack via mise à jour |
| Abandon de maintenance | left-pad (2016) | Casse de milliers de builds |
| Transfert de propriété | Polyfill.io (2024) | Injection de code malveillant |
| Faille non corrigée | Log4Shell dans une dépendance transitive | Vulnérabilité critique héritée |
| Non-conformité | SaaS non RGPD-compliant | Sanctions réglementaires |
| Rupture de service | Panne d’un SaaS critique | Indisponibilité de votre application |
Approche pratique inspirée du NIST 800-161
Section intitulée « Approche pratique inspirée du NIST 800-161 »Le NIST SP 800-161 Rev. 1 propose un cadre de pratiques de Cyber Supply Chain Risk Management (C-SCRM), orienté principalement vers les agences fédérales américaines. Ce n’est pas un “framework clé en main” directement transposable, mais ses principes restent pertinents pour structurer votre démarche.
Pour les équipes techniques, ces principes se traduisent en 4 actions opérationnelles : inventorier, évaluer, décider, suivre.
Les 4 actions opérationnelles du C-SCRM
Section intitulée « Les 4 actions opérationnelles du C-SCRM »
| Pilier | Ce que vous faites | Fréquence |
|---|---|---|
| Identifier | Lister tous vos tiers (SaaS, packages, prestataires) | Continue |
| Évaluer | Scorer chaque tiers selon des critères de risque | À l’onboarding + périodique |
| Répondre | Décider : accepter, atténuer, ou refuser le risque | Selon évaluation |
| Suivre | Revoir périodiquement, réagir aux incidents | Trimestriel/Annuel |
Étape 1 : Inventorier vos tiers
Section intitulée « Étape 1 : Inventorier vos tiers »Les 5 catégories de tiers à tracker
Section intitulée « Les 5 catégories de tiers à tracker »-
SaaS et services cloud
Les services que vous utilisez directement ou intégrez dans vos applications :
-
APIs tierces
Les services que vous appelez via API :
- Enrichissement de données (Clearbit, FullContact)
- Géolocalisation (Google Maps, HERE)
- Vérification (email, téléphone, identité)
-
Librairies et packages
Vos dépendances directes et transitives :
- Packages npm, PyPI, Maven, Go modules
- SDKs fournisseurs
- Frameworks (React, Django, Spring)
-
Prestataires techniques
Les humains et organisations qui accèdent à vos systèmes :
- ESN et développeurs externes
- Infogérants
- Consultants sécurité
- Support niveau 3 de vos fournisseurs
-
Infrastructure externe
Les composants d’infrastructure que vous ne gérez pas :
- CDN (Cloudflare, Fastly)
- DNS (Route53, Cloudflare DNS)
- Registres de packages (npm, Docker Hub)
- CA (Let’s Encrypt, DigiCert)
Template d’inventaire des tiers
Section intitulée « Template d’inventaire des tiers »Un inventaire efficace doit capturer non seulement les données de base, mais aussi le type d’accès accordé et la capacité à sortir du tiers si nécessaire.
| Nom | Catégorie | Données exposées | Criticité | Type d’accès | Substituable ? | Plan de sortie ? | Propriétaire | Dernière revue |
|---|---|---|---|---|---|---|---|---|
| Auth0 | SaaS Auth | Identifiants utilisateurs | Critique | API + Admin | Non | Oui | Équipe Identity | 2026-01-15 |
| Stripe | SaaS Paiement | Données bancaires | Critique | API | Non | Non | Équipe Billing | 2026-02-01 |
| lodash | Package npm | Aucune | Basse | Code | Oui | N/A | Équipe Frontend | - |
| axios | Package npm | Données transitant | Moyenne | Code | Oui | N/A | Équipe Frontend | - |
| Acme Consulting | Prestataire | Accès prod | Haute | Admin prod | Oui | Non | CTO | 2025-12-01 |
Étape 2 : Évaluer le risque de chaque tiers
Section intitulée « Étape 2 : Évaluer le risque de chaque tiers »Matrice de scoring simplifié
Section intitulée « Matrice de scoring simplifié »Le scoring combine deux dimensions :
- Impact : que se passe-t-il si ce tiers est compromis ?
- Probabilité : quelle est la maturité sécurité du tiers ?
Scoring d’impact (1-4)
Section intitulée « Scoring d’impact (1-4) »| Score | Impact | Critères |
|---|---|---|
| 4 - Critique | Perte de données sensibles, interruption majeure | Accès à des données clients, credentials, prod |
| 3 - Élevé | Dégradation significative | Accès à des données internes, staging |
| 2 - Moyen | Impact limité | Données non sensibles, dév/test |
| 1 - Faible | Négligeable | Pas de données, pas d’accès système |
Scoring de maturité sécurité (1-4)
Section intitulée « Scoring de maturité sécurité (1-4) »| Score | Maturité | Indicateurs |
|---|---|---|
| 4 - Mature | Excellent | SOC 2 Type II, ISO 27001, pentest récent, SBOM fourni |
| 3 - Bon | Satisfaisant | Certifications en cours, pratiques documentées |
| 2 - Basique | Insuffisant | Pas de certification, pratiques opaques |
| 1 - Faible | Préoccupant | Pas de réponse, incidents passés non résolus |
Calcul du score de risque
Section intitulée « Calcul du score de risque »Score de risque = Impact × (5 - Maturité)| Score | Niveau | Action |
|---|---|---|
| 12-16 | 🔴 Critique | Bloquer ou mitiger immédiatement |
| 8-11 | 🟠 Élevé | Plan d’actions sous 30 jours |
| 4-7 | 🟡 Moyen | Surveillance renforcée |
| 1-3 | 🟢 Faible | Suivi standard |
Exemple de scoring
Section intitulée « Exemple de scoring »| Tiers | Impact | Maturité | Score | Niveau |
|---|---|---|---|---|
| Auth0 | 4 | 4 | 4 | 🟢 Faible |
| Nouveau SaaS Analytics | 3 | 2 | 9 | 🟠 Élevé |
| Package npm populaire | 2 | 3 | 4 | 🟡 Moyen |
| Petit prestataire | 4 | 2 | 12 | 🔴 Critique |
Criticité métier et substituabilité
Section intitulée « Criticité métier et substituabilité »Le scoring impact × maturité ne capture pas tout. Deux tiers avec le même score peuvent présenter des profils de risque très différents selon leur criticité métier et leur substituabilité. Un SaaS peu mature mais facilement remplaçable n’a pas le même profil qu’un SaaS mature mais impossible à remplacer rapidement.
| Critère | Question à se poser | Impact sur la décision |
|---|---|---|
| Substituabilité | Peut-on changer de fournisseur en moins de 30 jours ? | Si non → risque accru même si maturité OK |
| Concentration | Ce tiers est-il point unique de défaillance (SPOF) ? | Si oui → prévoir plan de continuité |
| Réversibilité | Les données et configurations sont-elles exportables ? | Si non → lock-in = risque stratégique |
| Couplage technique | L’intégration est-elle profonde ou périphérique ? | Profonde → coût de migration élevé |
Étape 3 : Questionnaire d’évaluation pour tiers critiques
Section intitulée « Étape 3 : Questionnaire d’évaluation pour tiers critiques »Authentification et accès
Section intitulée « Authentification et accès »| # | Question | Preuve attendue |
|---|---|---|
| 1 | Supportez-vous SSO (SAML/OIDC) ? | Documentation technique |
| 2 | L’authentification MFA est-elle disponible/obligatoire ? | Screenshot console admin |
| 3 | Comment gérez-vous les accès API (OAuth, API keys rotatives) ? | Documentation API |
| 4 | Quel est le processus de révocation d’accès ? | Procédure documentée |
Sécurité des données
Section intitulée « Sécurité des données »| # | Question | Preuve attendue |
|---|---|---|
| 5 | Où sont stockées physiquement les données ? | Documentation localisation |
| 6 | Les données sont-elles chiffrées au repos et en transit ? | Attestation technique |
| 7 | Qui a accès aux données clients (support, dev, ops) ? | Politique d’accès |
| 8 | Comment les données sont-elles supprimées à la fin du contrat ? | Procédure de purge |
Développement sécurisé
Section intitulée « Développement sécurisé »| # | Question | Preuve attendue |
|---|---|---|
| 9 | Avez-vous un SDLC sécurisé documenté ? | Documentation processus |
| 10 | Réalisez-vous des tests de sécurité (SAST, DAST, pentest) ? | Rapport anonymisé |
| 11 | Comment gérez-vous les vulnérabilités de vos dépendances ? | Politique SCA |
| 12 | Fournissez-vous un SBOM de vos produits ? | Fichier SBOM |
Gestion des incidents
Section intitulée « Gestion des incidents »| # | Question | Preuve attendue |
|---|---|---|
| 13 | Quel est votre délai de notification en cas d’incident ? | SLA documenté |
| 14 | Avez-vous un plan de réponse aux incidents ? | Extrait du plan |
| 15 | Avez-vous subi des incidents de sécurité ces 24 mois ? | Disclosure si applicable |
| 16 | Comment communiquez-vous les vulnérabilités de vos produits ? | Page security advisories |
Conformité et certifications
Section intitulée « Conformité et certifications »| # | Question | Preuve attendue |
|---|---|---|
| 17 | Avez-vous une certification ISO 27001, SOC 2, ou équivalent ? | Certificat valide |
| 18 | Réalisez-vous des audits de sécurité externes réguliers ? | Attestation d’audit |
| 19 | Comment assurez-vous la conformité RGPD ? | DPA signé |
| 20 | Avez-vous une politique de responsabilité en cas de breach ? | Clause contractuelle |
Questions spécifiques pour les packages open source
Section intitulée « Questions spécifiques pour les packages open source »Pour les dépendances open source, le questionnaire classique ne s’applique pas. Utilisez plutôt ces critères :
| Critère | Comment vérifier | Seuil recommandé |
|---|---|---|
| Mainteneurs actifs | Nombre de contributeurs avec commits récents | > 2 mainteneurs actifs |
| Fréquence de mise à jour | Date du dernier commit/release | < 6 mois |
| Couverture vulnérabilités | CVE ouverts sans correctif | 0 CVE critique ouverte |
| Score OpenSSF | OpenSSF Scorecard | > 7/10 |
| Dépendances transitives | Nombre et qualité des sous-dépendances | Audit récursif |
| Licence | Compatibilité avec votre projet | License approuvée |
| Adoption | Stars, downloads, utilisateurs majeurs | Communauté active |
Questions spécifiques pour les SaaS
Section intitulée « Questions spécifiques pour les SaaS »Pour les services SaaS, ajoutez ces questions :
| Question | Pourquoi c’est important |
|---|---|
| Quel est votre SLA de disponibilité ? | Impact sur votre propre SLA |
| Quelle est votre politique de dépréciation d’API ? | Maintenance de votre intégration |
| Proposez-vous des environnements de test isolés ? | Sécurité de vos tests |
| Comment gérez-vous le multi-tenancy ? | Isolation entre clients |
| Quelle est votre couverture régionale (RGPD, localisation) ? | Conformité |
Étape 4 : Preuves acceptables vs insuffisantes
Section intitulée « Étape 4 : Preuves acceptables vs insuffisantes »La qualité des preuves varie selon le type de tiers. Un SOC 2 Type II est pertinent pour un SaaS, mais n’a pas de sens pour un projet open source maintenu par des bénévoles.
Preuves pour les fournisseurs contractuels (SaaS, prestataires)
Section intitulée « Preuves pour les fournisseurs contractuels (SaaS, prestataires) »| Niveau | Type de preuve | Confiance |
|---|---|---|
| 1 - Vérifiable | Rapport d’audit externe (SOC 2 Type II, ISO 27001) | ⭐⭐⭐⭐⭐ |
| 2 - Documenté | Rapports de pentest, politiques signées, DPA | ⭐⭐⭐⭐ |
| 3 - Déclaratif | Questionnaire rempli, attestation du fournisseur | ⭐⭐⭐ |
| 4 - Indirect | Ratings publics (SecurityScorecard, BitSight) | ⭐⭐ |
| 5 - Aucune | ”Faites-nous confiance” | ⭐ |
| Domaine | ✅ Preuve acceptable | ❌ Preuve insuffisante |
|---|---|---|
| Chiffrement | TLS configuré + cipher suites documentées | ”Oui, on chiffre” |
| Accès | Logs d’audit + politique RBAC | ”Seuls les admins ont accès” |
| Pentest | Rapport anonymisé avec date et scope | ”On fait des tests” |
| Incidents | Page publique de security advisories | ”On n’a jamais eu de problème” |
| MFA | Screenshot de la config obligatoire | ”C’est disponible” |
Preuves pour les composants open source
Section intitulée « Preuves pour les composants open source »Pour l’OSS, les preuves traditionnelles ne s’appliquent pas. Concentrez-vous sur les signaux de maturité du projet :
| Signal | Source | Confiance |
|---|---|---|
| SBOM + provenance signée | Artefact avec signatures SLSA | ⭐⭐⭐⭐⭐ |
| Security policy publique | SECURITY.md, process de disclosure | ⭐⭐⭐⭐ |
| OpenSSF Scorecard > 7 | scorecard.dev, deps.dev | ⭐⭐⭐ |
| Historique de releases | Régularité, changelogs, CVE corrigés rapidement | ⭐⭐⭐ |
| Mainteneurs identifiables | Profils publics, affiliation connue | ⭐⭐ |
| Popularité seule | Stars GitHub, downloads npm | ⭐ |
Étape 5 : Décider et agir
Section intitulée « Étape 5 : Décider et agir »Arbre de décision
Section intitulée « Arbre de décision »Une fois le score calculé, l’arbre ci-dessous guide la décision. Pour les risques élevés (≥8), trois options s’offrent à vous : mitiger le risque par des contrôles compensatoires, le transférer (assurance, clause contractuelle), ou refuser le tiers si aucune mitigation n’est acceptable.
Actions de mitigation typiques
Section intitulée « Actions de mitigation typiques »| Action | Quand l’appliquer | Exemple |
|---|---|---|
| Isolation réseau | Tiers peu de confiance | VPN dédié, réseau séparé |
| Limitation des données | Données sensibles exposées | Pseudonymisation, filtrage |
| Monitoring renforcé | Tout tiers critique | Alertes sur comportements anormaux |
| Backup externe | Dépendance à un seul fournisseur | Mirroring, cache local |
| Clause contractuelle | Risque financier | SLA, pénalités, assurance |
| Plan de sortie | Dépendance forte | Documentation de migration |
Contrôles compensatoires côté équipe
Section intitulée « Contrôles compensatoires côté équipe »Quand un tiers n’est pas parfait (et aucun ne l’est), c’est à vous de réduire le risque par des contrôles compensatoires. Ces mesures ne corrigent pas les faiblesses du tiers, mais limitent votre exposition.
| Contrôle | Ce que vous faites | Exemple concret |
|---|---|---|
| Réduction des privilèges | Limiter les accès accordés au tiers | Scopes OAuth minimaux, compte dédié sans admin |
| Segmentation réseau | Isoler le tiers du reste de l’infra | VPC dédié, egress filtering, proxy sortant |
| Filtrage des données | Ne pas envoyer plus que nécessaire | Pseudonymisation, minimisation, tokenisation |
| Vérification d’intégrité | Contrôler ce qui entre dans votre build | Lockfiles, signatures, attestations SLSA |
| Résilience | Survivre à une défaillance du tiers | Cache local, mirroring, fallback provider |
| Surveillance continue | Détecter les anomalies rapidement | Alertes sur advisories, changements de mainteneur |
Signaux faibles à surveiller sur l’open source
Section intitulée « Signaux faibles à surveiller sur l’open source »Au-delà du score Scorecard, certains signaux doivent déclencher une revue approfondie. L’affaire Polyfill.io (2024) illustre parfaitement ces risques : après un changement de propriétaire, le code a été modifié pour injecter du contenu malveillant sur des millions de sites.
| Signal d’alerte | Comment le détecter | Action recommandée |
|---|---|---|
| Mainteneur principal changé | Historique git, annonces | Revue du nouveau mainteneur |
| Transfert de namespace/repo | npm unpublish + republish, GitHub transfer | Analyse approfondie |
| Baisse d’activité puis release soudaine | Historique des commits | Inspecter le diff de la release |
| Package populaire, peu de mainteneurs | Contributors sur GitHub | Prévoir alternative ou fork |
| postinstall scripts suspects | package.json, npm audit | Bloquer ou auditer |
| Obfuscation, dépendances surprenantes | Inspection du code | Refuser ou isoler |
| Absence de SECURITY.md | Racine du repo | Privilégier alternatives mieux documentées |
Quand l’évaluation technique ne suffit pas
Section intitulée « Quand l’évaluation technique ne suffit pas »L’évaluation technique est nécessaire mais pas suffisante pour les tiers critiques. Certains aspects relèvent du contrat et doivent être négociés avec les équipes achats, juridiques ou le RSSI.
| Besoin | Pourquoi c’est important | Qui négocie |
|---|---|---|
| Clause de notification d’incident | Être informé rapidement en cas de breach | Juridique / RSSI |
| DPA (Data Processing Agreement) | Conformité RGPD pour les données personnelles | DPO / Juridique |
| SLA de disponibilité | Impact sur votre propre engagement client | Achats / Produit |
| Droit d’audit | Pouvoir vérifier les pratiques du fournisseur | RSSI / Conformité |
| Clause de réversibilité | Pouvoir récupérer vos données et migrer | Achats / Tech |
| Engagement de localisation | Savoir où sont traitées les données | DPO / RSSI |
Qualification rapide d’un tiers en 10 minutes
Section intitulée « Qualification rapide d’un tiers en 10 minutes »Vous devez valider rapidement un SaaS ou une librairie ? Voici la procédure express pour une première qualification.
-
Identifier le type de tiers
SaaS, package, API, prestataire ? Cela détermine les preuves à demander.
-
Évaluer l’exposition
Quelles données ou quels accès lui confie-t-on ? Personnel, financier, credentials, admin ?
-
Déterminer la criticité
Est-ce critique pour la prod ou le métier ? Une panne bloque-t-elle les utilisateurs ?
-
Chercher les preuves minimales
- SaaS : SOC 2, ISO 27001, page de sécurité publique ?
- OSS : Scorecard > 7, mainteneurs identifiables, releases régulières ?
-
Évaluer l’isolation possible
Peut-on limiter l’accès, filtrer les données, prévoir un fallback ?
Sortie de la qualification rapide
Section intitulée « Sortie de la qualification rapide »| Résultat | Critères | Action |
|---|---|---|
| Go | Impact faible, preuves OK, substituable | Intégrer sans délai |
| Go avec mitigations | Impact moyen, preuves partielles | Intégrer avec contrôles compensatoires |
| Revue approfondie | Impact élevé, preuves insuffisantes | Questionnaire complet, validation RSSI |
| No go | Impact critique, pas de preuves, pas d’isolation possible | Refuser ou chercher alternative |
Intégrer le TPRM dans vos processus
Section intitulée « Intégrer le TPRM dans vos processus »Dans le cycle de développement
Section intitulée « Dans le cycle de développement »-
Avant d’ajouter une dépendance
- Vérifier le score OpenSSF Scorecard
- Consulter la liste des packages approuvés/interdits
- Pour un nouveau SaaS : déclencher le processus d’évaluation
-
En CI/CD
- Bloquer les packages avec CVE critiques
- Alerter si une dépendance change de mainteneur
- Générer le SBOM à chaque release
-
Périodiquement
- Revoir les tiers critiques (trimestriel)
- Mettre à jour l’inventaire
- Vérifier les nouvelles certifications/incidents
Automatiser avec des outils
Section intitulée « Automatiser avec des outils »| Besoin | Outils |
|---|---|
| Inventaire packages | SBOM (Syft), Dependency-Track |
| Score open source | OpenSSF Scorecard, deps.dev |
| Vulnérabilités | Grype, Trivy, Snyk |
| Inventaire SaaS | CASB, solution TPRM (OneTrust, SecurityScorecard) |
| Questionnaires | Google Forms, Typeform, solutions TPRM |
Cas pratique : évaluer un nouveau SaaS
Section intitulée « Cas pratique : évaluer un nouveau SaaS »Imaginons que votre équipe souhaite intégrer un nouveau service d’envoi d’emails transactionnels : EmailService.
Étape 1 : Qualification rapide (5 minutes)
Section intitulée « Étape 1 : Qualification rapide (5 minutes) »| Question rapide | Réponse | Note |
|---|---|---|
| Données exposées ? | Emails, noms utilisateurs | Données personnelles |
| Criticité ? | Envoi de réinitialisation de MDP | Critique |
| Certifications visibles ? | SOC 2 sur leur site | À vérifier |
Résultat : Tiers critique → évaluation complète nécessaire.
Étape 2 : Questionnaire (envoi + réception)
Section intitulée « Étape 2 : Questionnaire (envoi + réception) »Envoi du questionnaire de 20 questions au commercial/sécurité du fournisseur.
Étape 3 : Analyse des réponses
Section intitulée « Étape 3 : Analyse des réponses »| Critère | Réponse | Évaluation |
|---|---|---|
| SSO/OIDC | Oui avec SAML2 | ✅ OK |
| MFA obligatoire | Disponible mais pas obligatoire | ⚠️ À négocier |
| SOC 2 Type II | Certifié, rapport disponible | ✅ OK |
| RGPD/DPA | DPA standard fourni | ✅ OK |
| SBOM | Non fourni | ⚠️ À suivre |
| Notification breach | 72h contractuel | ✅ OK |
| Pentest récent | Oui, rapport anonymisé fourni | ✅ OK |
Étape 4 : Scoring et décision
Section intitulée « Étape 4 : Scoring et décision »- Impact : 4 (données sensibles, credentials)
- Maturité : 3 (SOC 2, bon mais pas parfait)
- Score : 4 × (5-3) = 8 → 🟠 Élevé
Décision : Accepter avec mitigations :
- Négocier MFA obligatoire pour les admins
- Demander clause de notification breach < 48h
- Planifier revue dans 12 mois
Quand dire non : exemple de refus
Section intitulée « Quand dire non : exemple de refus »À retenir
Section intitulée « À retenir »Les 5 points essentiels de ce guide :
- Le TPRM concerne les équipes techniques — dès qu’on fait
npm install, on intègre un tiers - Inventorier d’abord — vous ne pouvez pas protéger ce que vous ne connaissez pas (SaaS, packages, prestataires)
- Scorer selon impact × maturité — priorisez les efforts sur les tiers critiques et peu matures
- Demander des preuves, pas des déclarations — un rapport SOC 2 vaut mieux qu’un “oui on sécurise”
- Automatiser où possible — SBOM, Scorecard, alertes CVE doivent être dans la CI/CD
Prochaines étapes
Section intitulée « Prochaines étapes »OpenSSF Scorecard
Évaluez automatiquement la sécurité des projets open source Lire le guide Scorecard
SaaSBOM
Documentez vos dépendances SaaS dans un format standard Voir le guide XBOM
NIS2 et fournisseurs
Comprenez les obligations NIS2 sur la gestion des tiers Lire le guide NIS2
Clauses cyber
Les clauses contractuelles minimales pour vos contrats fournisseurs [Guide Clauses à venir]