Modèle de menace - Dépôt de code source

Livrer un modèle de menace actionnable de qualité AppSec, spécifique au dépôt ou à un chemin de projet, et non une liste de vérification générique. Ancrer chaque affirmation architecturale à des preuves dans le dépôt et rendre les hypothèses explicites. Privilégier les objectifs réalistes des attaquants et les impacts concrets par rapport aux listes de vérification génériques.

Démarrage rapide

1. Collecter (ou déduire) les entrées :

• Chemin racine du dépôt et chemins dans le périmètre.
• Usage prévu, modèle de déploiement, exposition internet et attentes d'authentification (si connues).
• Résumé de dépôt existant ou spécification d'architecture.
• Utiliser les prompts dans references/prompt-template.md pour générer un résumé de dépôt.
• Respecter le contrat de sortie requis dans references/prompt-template.md. L'utiliser littéralement si possible.

Flux de travail

1) Définir le périmètre et extraire le modèle système

• Identifier les composants principaux, les magasins de données et les intégrations externes à partir du résumé du dépôt.
• Identifier comment le système s'exécute (serveur, CLI, bibliothèque, worker) et ses points d'entrée.
• Séparer le comportement runtime des outils de CI/build/dev et des tests/exemples.
• Mapper les emplacements du périmètre à ces composants et exclure explicitement les éléments hors périmètre.
• Ne pas revendiquer de composants, flux ou contrôles sans preuves.

2) Dériver les limites, les actifs et les points d'entrée

• Énumérer les limites de confiance comme des arêtes concrètes entre les composants, en notant le protocole, l'authentification, le chiffrement, la validation et la limitation de débit.
• Lister les actifs qui conduisent au risque (données, credentials, modèles, config, ressources de calcul, journaux d'audit).
• Identifier les points d'entrée (endpoints, surfaces de téléchargement, parseurs/décodeurs, déclencheurs de tâches, outils d'administration, puits de logs/erreurs).

3) Calibrer les actifs et les capacités des attaquants

• Lister les actifs qui conduisent au risque (credentials, PII, état critique pour l'intégrité, composants critiques pour la disponibilité, artefacts de build).
• Décrire les capacités réalistes des attaquants en fonction de l'exposition et de l'usage prévu.
• Noter explicitement les non-capacités pour éviter les sévérités gonflées.

4) Énumérer les menaces comme des chemins d'abus

• Préférer les objectifs des attaquants qui correspondent aux actifs et aux limites (exfiltration, escalade de privilèges, compromission d'intégrité, déni de service).
• Classer chaque menace et la lier aux actifs impactés.
• Garder le nombre de menaces petit mais de haute qualité.

5) Prioriser avec une justification explicite de la probabilité et de l'impact

• Utiliser la probabilité et l'impact qualitatifs (faible/moyen/élevé) avec justifications courtes.
• Définir la priorité globale (critique/élevée/moyenne/faible) en utilisant probabilité × impact, ajustée en fonction des contrôles existants.
• Indiquer quelles hypothèses influencent le plus le classement.

6) Valider le contexte du service et les hypothèses avec l'utilisateur

• Résumer les hypothèses clés qui affectent matériellement le classement des menaces ou le périmètre, puis demander à l'utilisateur de les confirmer ou les corriger.
• Poser 1–3 questions ciblées pour clarifier le contexte manquant (propriétaire du service et environnement, échelle/utilisateurs, modèle de déploiement, authn/authz, exposition internet, sensibilité des données, multi-locataire).
• Faire une pause et attendre les retours de l'utilisateur avant de produire le rapport final.
• Si l'utilisateur refuse ou ne peut pas répondre, indiquer quelles hypothèses subsistent et comment elles influencent la priorité.

7) Recommander des mitigations et des chemins de focus

• Distinguer les mitigations existantes (avec preuves) des mitigations recommandées.
• Lier les mitigations à des emplacements concrets (composant, limite ou point d'entrée) et à des types de contrôle (vérifications authZ, validation des entrées, application de schéma, sandboxing, limitations de débit, isolation des secrets, journalisation d'audit).
• Préférer les indices d'implémentation spécifiques aux conseils génériques (ex : « appliquer le schéma à la passerelle pour les charges de téléchargement » plutôt que « valider les entrées »).
• Baser les recommandations sur le contexte utilisateur validé ; si des hypothèses subsistent non résolues, marquer les recommandations comme conditionnelles.

8) Lancer une vérification de qualité avant de finaliser

• Confirmer que tous les points d'entrée découverts sont couverts.
• Confirmer que chaque limite de confiance est représentée dans les menaces.
• Confirmer la séparation runtime vs CI/dev.
• Confirmer que les clarifications de l'utilisateur (ou les non-réponses explicites) sont reflétées.
• Confirmer que les hypothèses et les questions ouvertes sont explicites.
• Confirmer que le format du rapport correspond étroitement au format de sortie requis défini dans le modèle de prompt : references/prompt-template.md
• Écrire le Markdown final dans un fichier nommé <repo-or-dir-name>-threat-model.md (utiliser le nom de base de la racine du dépôt, ou du répertoire du périmètre si vous avez été invité à modéliser un sous-chemin).

Recommandations de priorisation des risques (illustratives, non exhaustives)

• Élevée : RCE pré-authentification, contournement d'authentification, accès cross-tenant, exfiltration de données sensibles, vol de clé ou token, compromission d'intégrité du modèle ou de la config, échappement du sandbox.
• Moyenne : déni de service ciblé de composants critiques, exposition partielle de données, contournement de limite de débit avec impact mesurable, empoisonnement de logs/métriques affectant la détection.
• Faible : fuites d'info peu sensibles, déni de service bruyant avec mitigation facile, problèmes nécessitant des préconditions peu probables.

Références

• Contrat de sortie et modèle de prompt complet : references/prompt-template.md
• Liste optionnelle de contrôles/actifs : references/security-controls-and-assets.md

Charger uniquement les fichiers de référence dont vous avez besoin. Garder le résultat final concis, ancré et révisable.