Audit cyber 2026 : pourquoi je commence par la supply chain

Trois ans à signer des rapports d''audit qui commençaient par les pare-feux et finissaient par l''AD. Aujourd''hui je commence par les fichiers package-lock.json, les workflows GitHub Actions et la liste des paquets pip installés sur les builders. Ce n''est pas une lubie : c''est l''unique endroit où les attaquants gagnent vraiment du terrain en 2026.

Ce que la semaine du 5 au 12 mai 2026 a confirmé

Mini Shai-Hulud sur TanStack le 11 mai. Avant ça, PCPJack sur les clusters Kubernetes exposés. Avant ça, Trellix piraté avec exfiltration de code source. n8n CVSS 10.0, Spring AI trois HIGH, AzuraCast RCE 8.8, OpenCTI takeover non-auth, FastGPT 9.8. Et je ne parle même pas de l''affaire Instructure qui a balayé 275 millions de comptes étudiants. En une semaine.

Le point commun de toutes ces affaires n''est pas le périmètre technique attaqué. C''est le périmètre social. Des bibliothèques tierces, des plateformes d''orchestration auto-hébergées, des frameworks LLM, des outils de threat intelligence : autant de briques qu''aucune équipe sécurité ne maintient elle-même mais que toute organisation moderne consomme massivement. Le ROI de l''attaquant qui compromet une dépendance largement diffusée est d''un ou deux ordres de grandeur supérieur à celui de l''attaquant qui phishe un comptable.

Cette concentration n''est pas une surprise. Elle était annoncée depuis SolarWinds en 2020, depuis Log4Shell en 2021, depuis xz utils en 2024. Ce qui change en 2026, c''est l''industrialisation. TeamPCP a publié 84 versions npm en six minutes le 11 mai. Ce n''est pas un attaquant qui bricole un soir, c''est un harnais d''automatisation prêt à dégainer dès qu''une fenêtre s''ouvre.

Pourquoi mes anciens audits passaient à côté

Quand je commençais une mission audit en 2022, je passais quatre jours sur cinq sur les fondamentaux : politiques de mots de passe, segmentation réseau, durcissement Active Directory, gestion des comptes à privilèges, sauvegarde, plan de reprise. Le cinquième jour, je validais quelques scans Nessus sur les actifs externes et je rédigeais. Le rapport sortait propre, le client signait, le RSSI avait sa to-do list pour l''année.

Ce que je ne couvrais pas, ou très mal, c''était la dette logicielle. La liste des dépendances tirées par les pipelines CI. Les workflows GitHub Actions qui tournaient avec des permissions étendues sans qu''on sache qui les avait écrites. Les images Docker base utilisées par les développeurs sans signature. Les bases vectorielles déployées en quelques heures pour un POC RAG et oubliées en production. Les jetons npm publiés dans des secrets de dépôt par un développeur parti il y a deux ans.

Quand un de mes clients s''est fait toucher en 2024 par une compromission via un paquet npm typo-squatté, j''ai mis trois jours à reconstituer la chaîne d''exposition. Trois jours où le client perdait de l''argent et où j''apprenais sur le tas que mon audit de référence ne couvrait pas 80% du problème réel.

Ma méthode actuelle

Maintenant, je commence systématiquement par trois questions, posées avant même de regarder le réseau ou l''AD :

Première question : qui peut publier sur vos registres internes ? Cela couvre l''Artifactory, le Nexus, le GitLab Container Registry, le PyPI privé, la registry npm interne. La réponse est presque toujours floue. Les plus matures ont une réponse précise sur deux registres et une réponse vague sur les six autres. Cette dispersion est le terreau parfait pour qu''un attaquant publie une dépendance interne piégée et la diffuse via des CI mal configurés.

Deuxième question : combien de vos workflows CI ont des secrets de production exposés en variables d''environnement ? Cela permet d''évaluer la surface de vol par exfiltration silencieuse. Un secret qui n''est exposé qu''à la phase de déploiement, ou qui est récupéré en runtime via un coffre dédié type HashiCorp Vault ou AWS Secrets Manager, est moins exposé qu''un secret AWS_SECRET_ACCESS_KEY balancé en clair dans toutes les jobs CI.

Troisième question : depuis quand n''avez-vous pas tourné les jetons d''accès npm, PyPI, Docker Hub, GitHub PAT utilisés par vos pipelines ? Un jeton qui n''a pas tourné depuis 18 mois est un jeton qui a été observé par tous les développeurs, ex-développeurs, contractuels et stagiaires qui ont travaillé sur le projet pendant cette période. La probabilité qu''il ait fuité est non nulle, et croît avec le temps.

Ce que les RSSI doivent ajouter à leur tableau de bord en 2026

Trois indicateurs minimum, à mon sens, pour une organisation qui consomme du logiciel tiers :

Le délai moyen entre la publication d''une CVE critique sur une dépendance utilisée et son patch effectif en production. Ce délai était mesuré en semaines en 2020. En 2026, il doit se mesurer en heures pour les CVE CVSS supérieures à 9. Si votre organisation met deux semaines à patcher une dépendance critique, vous êtes dans la moyenne historique. Vous êtes aussi exposés à toute campagne moderne qui exploite la fenêtre des 72 premières heures.

Le pourcentage de pipelines CI dont les secrets ont tourné dans les six derniers mois. Cible raisonnable : 100%. Cible observée chez la majorité des PME et ETI françaises : moins de 30%. C''est l''écart le plus criant entre la maturité affichée et la réalité opérationnelle.

Le nombre de dépendances tierces consommées par les applications critiques, et la part qui fait l''objet d''un suivi actif (alerte vulnérabilités, MAJ régulière). Beaucoup d''organisations découvrent qu''elles tirent 1 200 paquets npm en transitif sur une application qui en déclare 40. Sans automation type Dependabot ou Snyk, ces 1 200 dépendances sont des angles morts.

Ce que cela change pour les équipes qui n''ont pas les moyens d''une DevSecOps complète

L''objection que j''entends le plus souvent en PME : "on n''a pas les ressources pour une plateforme SAST/DAST/SCA, on fait avec ce qu''on a". C''est légitime. Mais trois quarts du chemin se font sans plateforme. Configurer Dependabot sur GitHub coûte zéro, alerte sur les CVE des dépendances directes, et fait des PR de mise à jour automatiques. Ajouter une étape pip-audit ou npm audit dans les pipelines coûte cinq lignes de YAML. Forcer le pinning strict des dépendances par lockfile coûte une discipline d''équipe, pas un budget. Activer la double authentification sur les comptes mainteneurs npm coûte deux minutes par compte.

Le seuil d''investissement minimum pour passer d''un état de cécité totale à un état de visibilité raisonnable sur sa supply chain logicielle est très bas en 2026. Ce qui manque, ce n''est presque jamais l''argent : c''est l''arbitrage et la priorité.

Conclusion

Si vous me demandez aujourd''hui de réaliser un audit cyber pour votre organisation, attendez-vous à ce que je passe la première journée non pas dans votre datacenter, mais dans vos dépôts Git, vos pipelines CI, vos registres de paquets internes et vos plateformes d''orchestration. Ce n''est pas un effet de mode lié à mai 2026. C''est un changement de centre de gravité du risque cyber qui s''installe depuis cinq ans et qui s''est définitivement imposé cette semaine. La porte d''entrée principale de votre SI n''est plus votre Active Directory : c''est votre fichier package-lock.json.

Méthodologie d'audit supply chain : de l'inventaire à la notation des risques fournisseurs

L'audit de cybersécurité de la supply chain commence par un inventaire exhaustif. Pour une organisation de taille moyenne, le nombre de fournisseurs ayant un accès quelconque au SI (accès VPN, APIs exposées, partage de fichiers, maintenance à distance) dépasse fréquemment 200 entités. La première phase consiste à croiser trois sources : le registre des fournisseurs de la DAF, les connexions VPN actives identifiées par l'équipe réseau, et les contrats IT listant les accès accordés. Ce croisement révèle systématiquement des fournisseurs "fantômes" — accès accordés il y a plusieurs années et jamais révoqués.

La notation des risques fournisseurs s'appuie sur une matrice combinant criticité de l'accès accordé (lecture seule vs écriture vs accès admin) et maturité sécurité du fournisseur (évaluée via questionnaire CAIQ, rapport SOC 2 Type II, ou résultats de scan externe). Les fournisseurs critiques font l'objet d'un audit approfondi annuel. L'outil de scoring BitSight ou SecurityScorecard permet d'automatiser la surveillance continue de la posture externe des fournisseurs, avec alertes sur dégradation du score.

La contractualisation des exigences cybersécurité avec les fournisseurs est l'aboutissement de l'audit supply chain. Les clauses à intégrer systématiquement dans les contrats de sous-traitance incluent : une obligation de conformité à un référentiel de sécurité reconnu (ISO 27001, SOC 2 Type II minimum), une obligation de notification d'incident dans les 24 heures suivant la découverte d'un incident pouvant affecter les données ou les accès de votre organisation, le droit d'audit annuel sur préavis de 30 jours, et une clause de résiliation pour motif de sécurité permettant de mettre fin au contrat sans pénalité en cas de violation grave des exigences de sécurité.

Le programme de supply chain cybersecurity ne doit pas être perçu comme une contrainte par les fournisseurs mais comme un différentiateur concurrentiel. Les fournisseurs qui investissent dans leur sécurité et peuvent démontrer leur maturité via des certifications obtiennent plus facilement de nouveaux marchés et maintiennent des relations durables avec leurs clients. L'animation d'une communauté de fournisseurs sur les sujets de cybersécurité — partage de ressources de formation, webinaires sur les nouvelles menaces, accompagnement vers la certification — crée une valeur mutuelle et renforce la posture globale de la chaîne d'approvisionnement.

Foire aux questions sur l'audit cyber supply chain en 2026

Par où commencer un audit cybersécurité supply chain quand on ne sait pas où se trouvent toutes ses dépendances tierces ?

La première étape d'un audit supply chain est l'inventaire des flux de données et de confiance, pas l'inventaire technique des systèmes. La question à poser n'est pas "quels serveurs avons-nous ?" mais "qui peut accéder à quoi dans notre SI, et de l'extérieur ?". Concrètement, cela commence par cartographier les VPNs de sous-traitants, les accès API tiers, les comptes de service utilisés par des prestataires, et les webhooks ou connecteurs cloud configurés par des équipes métier. La deuxième étape est l'analyse des données sortantes : quels prestataires reçoivent de la donnée client ou de la donnée sensible, et avec quel niveau de contrôle ? La troisième étape seulement est l'inventaire des logiciels tiers — SBOM, dépendances npm/pip/maven, plugins. Commencer par là sans la cartographie des flux crée un faux sentiment d'exhaustivité : vous aurez un beau tableau de logiciels sans savoir ce qu'ils font avec vos données.

Quels indicateurs utiliser pour évaluer le niveau de risque d'un fournisseur logiciel dans un contexte supply chain ?

L'évaluation du risque fournisseur supply chain repose sur cinq dimensions complémentaires. La criticité d'accès mesure le niveau de privilège accordé : un fournisseur avec accès admin au tenant Azure est infiniment plus risqué qu'un prestataire avec accès lecture à un bucket S3 isolé. L'historique CVE du logiciel fourni (nombre de vulnérabilités critiques, délais de correction, qualité de la communication sécurité) est un proxy fiable de la maturité sécurité de l'éditeur. La concentration du risque évalue combien de vos systèmes critiques dépendent de ce fournisseur — un MSP qui gère 80% de votre parc est un single point of failure. La capacité de réponse à incident du fournisseur — dispose-t-il d'un SOC ? Quelle est son obligation contractuelle de notification en cas de compromission ? — détermine votre exposition en cas d'attaque. Enfin, la maturité de leurs pratiques DevSecOps (SLSA, signature des artefacts, MFA obligatoire) reflète leur posture sécurité réelle au-delà des certifications.

Comment contractualiser les exigences de sécurité supply chain avec des fournisseurs qui résistent aux audits ?

La contractualisation des exigences sécurité supply chain bute souvent sur la résistance des fournisseurs, notamment les éditeurs de logiciels SaaS qui refusent les audits directs. Plusieurs leviers existent. Les questionnaires CAIQ (Consensus Assessment Initiative Questionnaire) de la Cloud Security Alliance sont acceptés comme substitut d'audit par la majorité des éditeurs SaaS — ils couvrent 261 contrôles de sécurité cloud. Les certifications ISO 27001, SOC 2 Type II et ISAE 3402 peuvent être exigées contractuellement comme preuve de maturité minimale. La clause de droit d'audit indirect — droit d'accéder aux rapports de pentests tiers commandités par l'éditeur — est souvent plus acceptable que le droit d'audit direct. Les exigences NIS 2 Article 21 sur les fournisseurs peuvent être utilisées comme levier légal : une entité essentielle peut légitimement exiger de ses fournisseurs critiques des garanties de sécurité alignées sur les obligations NIS 2, sous peine de rupture de contrat.