Modélisation des menaces pour les profils tech 2026 : STRIDE au-delà du corporate

Table des matières

• Pourquoi le threat modeling générique échoue pour les profils tech
• EFF SSD adapté : actifs, adversaires, capacités
• STRIDE pour les profils non-corporate
• Matrice de risque : dev solo sur Mac, iPhone, GitHub, AWS
• Mitigations par niveau
• Six profils : actifs, adversaires, mitigations prioritaires
• Révision annuelle : checklist de réévaluation

Pourquoi le threat modeling générique échoue pour les profils tech

Le NIST Cybersecurity Framework 2.0 (publié en février 2024) est un document de gouvernance solide. Il ne dit pas quoi faire quand un mainteneur OSS découvre qu'une PR malveillante vient d'être fusionnée dans un paquet avec 40 000 téléchargements hebdomadaires. Les conseils de sécurité grand public — « utilisez un gestionnaire de mots de passe, activez la 2FA » — sont nécessaires mais insuffisants pour quiconque dont la surface numérique ressemble à : trois organisations GitHub, un compte root AWS, un pipeline CI avec des clés de déploiement, un endpoint SSH public, un DNS géré via Cloudflare, et une machine de développement qui accède aussi aux comptes bancaires personnels.

Le problème n'est pas la sophistication. C'est la spécificité. Les guides grand public modélisent un profil de menace du type « prise de contrôle de compte par un attaquant opportuniste ». Le profil de menace réaliste d'un développeur ou sysadmin inclut : injection dans la chaîne d'approvisionnement ciblée, exfiltration de secrets CI/CD, vol de clé SSH depuis un dépôt dotfiles compromis, et ingénierie sociale par quelqu'un qui a lu votre historique de commits et connaît votre stack de déploiement.

EFF Surveillance Self-Defense (ssd.eff.org) cadre correctement la sécurité comme une fonction de votre situation spécifique — actifs, adversaires, capacités, probabilité, conséquences. Les guides grand public sautent la première étape : énumérer précisément ce que vous possédez réellement et qui vaut la peine d'être attaqué.

C'est pourquoi la méthodologie ci-dessous commence par l'énumération des actifs spécifique aux praticiens techniques, puis cartographie les adversaires avec des évaluations réalistes de leurs capacités, avant d'aborder la moindre recommandation de mitigation.

Consultez le guide pilier sur la confidentialité des navigateurs en 2026 pour le contexte de protection de la vie privée dans lequel s'inscrit ce modèle de menaces.

EFF SSD adapté : actifs, adversaires, capacités

Énumération des actifs pour les praticiens techniques

Avant de catégoriser les menaces, énumérez ce que vous possédez réellement. Pour un développeur indépendant ou un mainteneur OSS typique en 2026, l'inventaire des actifs se décompose en cinq catégories :

Actifs d'identité : comptes GitHub/GitLab (liés à une réputation publique et à des permissions organisationnelles), comptes root des cloud providers (AWS, GCP, Azure), comptes des registrars de domaines (la racine de votre présence web), comptes email (le chemin de récupération de tout le reste), et comptes des registres de paquets (npm, PyPI, crates.io — le rayon de la déflagration d'une compromission s'étend à chaque consommateur en aval).

Actifs d'infrastructure : serveurs et conteneurs de production, zones DNS, certificats TLS et configurations CA, clés SSH (en particulier les clés de déploiement avec accès en écriture aux dépôts), rôles IAM cloud et comptes de service, secrets stockés dans des fichiers .env ou des gestionnaires de secrets.

Actifs de code : dépôts privés, configurations de pipelines CI/CD, fichiers lockfile de dépendances, clés de signature pour les commits ou les publications de paquets.

Actifs financiers : comptes Stripe/processeurs de paiement, méthodes de paiement pour les renouvellements de domaines, portefeuilles de cryptomonnaies le cas échéant.

Actifs de réputation : votre historique de commits public, vos accès de publication de paquets, vos comptes sociaux liés à votre identité professionnelle.

Taxonomie des adversaires

EFF SSD utilise une taxonomie à cinq niveaux. Adaptée au profil du praticien technique :

Les attaquants opportunistes scannent internet à la recherche de credentials exposés, de services non patchés et de mots de passe réutilisés. Ils sont automatisés, à volume élevé et de faible sophistication. Ils trouveront votre instance EC2 avec le port 22 ouvert en quelques minutes après le lancement si elle est sur une plage d'IP résidentielle. C'est la menace de référence que traitent les fondamentaux de sécurité.

Les attaquants ciblés (criminels ou concurrents) vous ont identifié spécifiquement comme cible de valeur financière. Ils créeront du spear-phishing contre votre stack spécifique, tenteront l'injection dans la chaîne d'approvisionnement de vos dépendances, et surveilleront votre activité publique pour recueillir du renseignement opérationnel. Atteindre ce niveau nécessite soit des revenus significatifs, soit la garde de données précieuses, soit une visibilité dans un espace financièrement intéressant.

Les acteurs étatiques opèrent avec une persistance quasi illimitée et un large éventail de capacités zero-day. Pour la plupart des praticiens, ce niveau de menace requiert des circonstances exceptionnelles : travailler sur des infrastructures gouvernementales sensibles, être un dissident politique, ou être journaliste couvrant des services de renseignement. L'existence de ce niveau compte pour le calibrage — vous ne devriez pas concevoir toutes les mitigations pour résister à un acteur étatique, car le rapport coût/complexité est intenable pour la plupart des situations.

Les menaces internes sont des personnes avec un accès légitime qui agissent malicieusement ou par négligence. Pour les praticiens solo, c'est moins pertinent ; pour les mainteneurs OSS avec plusieurs collaborateurs, c'est significatif — un compte mainteneur compromis, un contributeur rancunier avec des droits de fusion, ou un commit accidentel de secret par un contributeur de confiance entrent tous dans cette catégorie.

Matrice des capacités — pour chaque type d'adversaire, évaluez les ressources disponibles : bases de données de credentials, infrastructure pour le phishing, exploits zero-day, contrainte légale, accès physique. Croiser la valeur des actifs avec les capacités des adversaires produit l'espace de menaces réaliste que vous devez adresser.

STRIDE pour les profils non-corporate

Le framework STRIDE de Microsoft (1999, Adam Shostack) catégorise les menaces en six classes. Les équipes de sécurité corporate l'appliquent aux diagrammes de flux de données d'architectures applicatives. Pour les praticiens individuels, appliquez-le à la topologie de votre infrastructure personnelle.

Spoofing (prise de contrôle de compte). La menace de spoofing pour un développeur est principalement la prise de contrôle de compte : quelqu'un vous usurpe l'identité sur GitHub, votre console cloud ou votre registrar pour effectuer des actions sous votre identité. Vecteurs d'attaque : credential stuffing depuis des bases de données piratées, proxies de phishing en temps réel (Evilginx2 peut contourner la 2FA TOTP), SIM swapping (pour intercepter les 2FA SMS), et vol de tokens OAuth via des GitHub Apps malveillantes. La mitigation est l'authentification résistante au phishing — clés FIDO2 matérielles — pour les comptes où un spoofing réussi a un fort rayon de déflagration.

Tampering (chaîne d'approvisionnement). Un artefact altéré signifie que du code modifié atteint la production ou les utilisateurs finaux. Pour un développeur, cela se manifeste par : une PR malveillante fusionnée sans revue adéquate, une mise à jour de version d'une dépendance qui introduit une backdoor (xz utils, event-stream), un environnement de build compromis qui signe un binaire modifié, ou un token de publication npm volé. La pile de mitigations comprend : Sigstore/cosign pour la signature d'artefacts, fichiers lockfile épinglés avec vérification de hash, portes de revue de code qui ne font pas confiance aux bots automatisés, et niveaux de provenance SLSA.

Repudiation (pistes d'audit). Pouvez-vous prouver ce qui s'est passé et qui l'a fait ? La signature des commits git avec des clés SSH ou GPG établit un enregistrement inviolable des modifications de code. Les commits signés ne préviennent pas les attaques mais établissent la responsabilité — crucial si vous devez démontrer à des utilisateurs en aval qu'un commit spécifique n'a pas été rédigé par vous. CloudTrail et les équivalents journaux d'audit pour les actions cloud servent la même fonction.

Information Disclosure (secrets fuités). L'incident le plus fréquent à fort impact dans le monde des développeurs. Un fichier .env commité dans un dépôt public, une clé AWS dans un log GitHub Actions, une chaîne de connexion à la base de données dans un message d'erreur, ou une clé privée intégrée dans une couche d'image Docker. git-secrets, truffleHog et le secret scanning de GitHub détectent les secrets commités ; les hooks pre-commit les empêchent d'atterrir. Faire pivoter les credentials immédiatement après toute divulgation suspectée est non négociable.

Denial of Service (disponibilité). Pour un développeur solo hébergeant un produit SaaS, un DDoS soutenu peut éliminer des revenus. Plus subtil : le rate limiting sur vos appels à l'API GitHub ou l'épuisement du pipeline CI/CD via une dépendance conçue qui déclenche des temps de build excessifs. La mitigation au niveau de base est Cloudflare ou un CDN/protection DDoS équivalent devant les endpoints publics. Au niveau infrastructure, assurez-vous qu'une seule dépendance compromise n'a pas la capacité d'épuiser votre budget CI.

Elevation of Privilege (pipelines CI/CD). Un pipeline CI qui s'exécute avec un accès en écriture sur l'environnement de production et accepte du code arbitraire depuis des pull requests est un vecteur EoP : un attaquant soumet une PR qui exfiltre des clés de déploiement ou écrit du code malveillant en production. GitHub Actions atténue cela avec l'événement pull_request ayant un GITHUB_TOKEN en lecture seule par défaut, mais de nombreux dépôts contournent cela. Séparer les workflows pour les PR non fiables (lecture seule, sans secrets) des fusions de confiance (accès déploiement) est l'architecture correcte. La fédération OIDC élimine entièrement les credentials long-lived dans les CI.

Matrice de risque : dev solo sur Mac, iPhone, GitHub, AWS

Exemple concret : un développeur solo gérant un produit SaaS sur Mac (poste de travail principal), iPhone (dispositif 2FA et communication personnelle), GitHub (code et CI/CD), et AWS (infrastructure de production). Scoring de chaque vecteur avec une échelle simplifiée probabilité × impact (1-5) :

Cette matrice indique où concentrer l'effort en premier : protection du compte GitHub et du compte root AWS, plus prévention des fuites de fichiers .env. Tout le reste est important mais n'est pas prioritaire.

Pour référence sur le scoring CVSS 3.1 de vulnérabilités spécifiques dans vos dépendances, la base de données NVD (nvd.nist.gov) fournit les scores de base pour les CVE ; les modificateurs environnementaux et temporels permettent d'ajuster les scores à votre contexte de déploiement.

Mitigations par niveau

Niveau de base (tous les praticiens tech, sans exception)

Passkeys et clés de sécurité FIDO2 matérielles pour GitHub, les consoles cloud, les registrars de domaines et l'email. Ce sont les comptes où la prise de contrôle a le plus fort rayon de déflagration. Un compte registrar compromis permet à un attaquant de prendre le contrôle de chaque domaine et du certificat associé. Un compte GitHub compromis lui permet de pousser du code malveillant et d'exfiltrer tous les secrets des dépôts.

2FA basée sur TOTP (Ente Auth, Aegis, 1Password TOTP) pour chaque compte qui ne supporte pas les passkeys. Le TOTP n'est pas résistant au phishing mais contrecarre le credential stuffing à grande échelle. La 2FA par SMS est inférieure au TOTP pour les comptes associés à un numéro de téléphone connu — le SIM swapping est un vecteur d'attaque documenté.

Gestionnaire de mots de passe avec des credentials uniques générés aléatoirement pour chaque compte. Bitwarden et 1Password proposent tous deux des outils CLI pour une utilisation en automatisation. Consultez le guide des gestionnaires de mots de passe pour ingénieurs pour les détails d'intégration CLI.

Hook pre-commit de scan de secrets. Installez truffleHog ou git-secrets comme hook pre-commit. Exécutez git log --all --full-history sur vos dépôts existants pour auditer les fuites historiques.

Verrouillage du compte root AWS. Les credentials root AWS doivent avoir la MFA activée avec une clé matérielle, et le compte root ne doit avoir aucune clé d'accès générée. Tous les accès opérationnels doivent utiliser des rôles IAM avec des politiques de moindre privilège.

Niveau intermédiaire

Clé de sécurité matérielle dédiée (YubiKey 5 NFC ou équivalent). La YubiKey 5 supporte FIDO2, PIV, OpenPGP et OTP dans un seul dispositif. Pour FIDO2, enregistrez deux clés et stockez la clé de sauvegarde dans un endroit physiquement séparé.

Machine de développement ou VM dédiée pour les opérations les plus sensibles. Si votre machine quotidienne exécute des npm install arbitraires depuis de nombreux projets, son store de credentials est exposé à tout paquet exécutant un script d'installation malveillant. Une VM dédiée et durcie avec uniquement les outils nécessaires pour l'accès aux comptes financiers ou la gestion d'infrastructure sensible limite le rayon de déflagration d'une compromission du poste de travail.

Signature des commits. Configurez la signature des commits SSH (supportée par GitHub depuis 2022) ou la signature GPG pour tous les commits. Activez les règles de protection de branche exigeant des commits signés sur les branches main/release.

Cron d'audit. Une vérification automatisée hebdomadaire : aws iam generate-credential-report pour revoir les credentials IAM, gh api /user/installations pour auditer les permissions des GitHub Apps, vérifications équivalentes pour les changements DNS non autorisés. Ce sont des signaux détectables de compromission de compte qui surviennent avant qu'un attaquant n'atteigne son objectif.

Épinglage des dépendances avec vérification de hash. Verrouillez les dépendances à des SHAs de commit spécifiques ou des hashes d'adressage par contenu, pas à des plages de versions sémantiques flottantes. Pour npm, npm ci avec un package-lock.json commité ; pour Python, pip-compile avec des requirements hachés ; pour Go, go.sum est déjà basé sur les hashes.

Niveau avancé

Tailscale (ou Headscale) pour l'accès à l'infrastructure. N'exposez rien sur internet public qui n'a pas besoin d'être public. SSH, panneaux d'administration, tableaux de bord de monitoring et environnements de staging appartiennent à un mesh Tailscale. Associez aux ACL Tailscale pour appliquer un accès réseau à moindre privilège entre les dispositifs. Headscale (serveur de coordination auto-hébergé) élimine la dépendance à l'infrastructure de coordination de Tailscale.

Profils de navigateur séparés par contexte. Les comptes financiers, le travail de développement, la navigation générale et les réseaux sociaux doivent fonctionner dans des profils de navigateur isolés ou des binaires de navigateur séparés. Firefox avec Multi-Account Containers offre une isolation au niveau des conteneurs dans un seul binaire. Cela prévient la corrélation des cookies et des sessions entre contextes. Consultez le guide de détection des fuites réseau pour la méthodologie de détection.

Environnement de build isolé. Le CI doit fonctionner dans des environnements éphémères sans credentials persistants. Pour les builds locaux, un conteneur ou une VM sans montage de credentials de l'hôte garantit qu'un script de build malveillant ne peut pas récolter l'agent SSH de l'hôte, les credentials cloud ou le trousseau de clés.

VPN pour les contextes réseau sensibles. Un VPN sans logs et audité sur les réseaux non fiables (Wi-Fi public, ethernet hôtel) prévient l'interception passive du trafic non chiffré et masque votre IP des serveurs de destination. Le guide VPN pour profils tech couvre la méthodologie d'évaluation des providers.

Six profils : actifs, adversaires, mitigations prioritaires

Révision annuelle : checklist de réévaluation

Un modèle de menaces n'est pas un document que l'on produit une fois et que l'on classe. La surface de menace évolue à mesure que votre activité évolue. Les événements suivants nécessitent chacun une réévaluation immédiate :

Événements déclencheurs nécessitant une réévaluation immédiate :

• Un nouveau projet devient publiquement visible (lancement ProductHunt, stars GitHub dépassant 1 000, mention presse)
• Vous obtenez un accès administrateur à une infrastructure que vous ne contrôliez pas avant
• Un incident de sécurité touche un compte de votre écosystème, même indirectement
• Vos revenus franchissent un seuil qui rend une attaque financière économiquement rationnelle
• Vous recevez un message qui pourrait être de l'ingénierie sociale ciblée
• Votre nom apparaît dans un contexte qui augmente le risque de doxxing

Checklist de réévaluation annuelle :

1. Réénumérez tous les actifs. Quels comptes existent qui n'existaient pas six mois auparavant ? Quels services avez-vous ajoutés à votre stack ?
2. Auditez les tokens d'accès. Exécutez gh auth list, aws iam list-access-keys --user-name <tous les utilisateurs>, gcloud auth list. Révoquez tout ce qui n'est pas activement utilisé.
3. Vérifiez les méthodes 2FA. Des comptes ont-ils été rétrogradés de clé matérielle vers TOTP, ou de TOTP vers SMS ? Corrigez les régressions.
4. Vérifiez les secrets exposés. Exécutez truffleHog sur tous les dépôts y compris les privés. Exécutez Grype ou équivalent sur les images de conteneurs.
5. Mettez à jour les fichiers lockfile de dépendances. Épinglez aux versions bonnes connues actuelles, revoyez le changelog pour les changements liés à la sécurité.
6. Revoyez les politiques IAM cloud. Le principe du moindre privilège s'érode avec le temps à mesure que des permissions sont ajoutées par commodité et jamais supprimées.
7. Testez la restauration des backups. Un backup non testé n'est pas un backup. Vérifiez que vos images disque chiffrées, snapshots de base de données et backups de phrase seed sont intacts et récupérables.
8. Réévaluez le niveau d'adversaire. Quelque chose dans votre profil professionnel ou public a-t-il changé qui vous élèverait vers un niveau de cible plus précieux ?

La fonction Gouvernance du NIST CSF 2.0 formalise ce type de boucle d'amélioration continue au niveau organisationnel. Pour les individus, l'équivalent est un rappel calendrier, une checklist structurée, et la discipline de l'exécuter même quand rien n'a visiblement mal tourné.

L'EFF publie des guides mis à jour sur ssd.eff.org en continu. La MITRE ATT&CK Matrix (attack.mitre.org) est mise à jour trimestriellement avec de nouvelles techniques d'adversaires tirées d'incidents réels — utile pour vérifier si de nouveaux TTPs sont pertinents à votre profil.

Construire un modèle de menaces fiable n'est pas un exercice d'un après-midi. C'est l'habitude de demander systématiquement, pour chaque changement significatif de votre surface d'attaque : qu'est-ce qu'un adversaire pourrait faire avec cela, et le coût de la prévention est-il inférieur au coût de l'incident ? Les frameworks ci-dessus — EFF SSD, STRIDE, scoring CVSS 3.1 — vous donnent un langage reproductible pour cette conversation, que ce soit avec vous-même, vos collaborateurs, ou un professionnel de la sécurité que vous consultez quand les enjeux justifient un avis extérieur.