Modèle de menace du référentiel du code source

Livrer un modèle de menace de qualité AppSec exploitable et spécifique au référentiel ou à un chemin de projet, et non une liste de contrôle générique. Ancrer chaque affirmation architecturale à des preuves dans le repo et garder les hypothèses explicites. Prioriser les objectifs réalistes des attaquants et les impacts concrets plutôt que les listes de contrôle génériques.

Démarrage rapide

Collectez (ou déduisez) les entrées :

Chemin racine du repo et tous les chemins dans le périmètre.
Utilisation prévue, modèle de déploiement, exposition à Internet et attentes d'authentification (si connues).
Tout résumé de référentiel ou spécification d'architecture existant.
Utilisez les invites dans references/prompt-template.md pour générer un résumé de référentiel.
Suivez le contrat de sortie requis dans references/prompt-template.md. Utilisez-le textuellement si possible.

Flux de travail

1) Périmètre et extraction du modèle de système

Identifiez les composants primaires, les magasins de données et les intégrations externes à partir du résumé du repo.
Identifiez le mode d'exécution du système (serveur, CLI, bibliothèque, worker) et ses points d'entrée.
Séparez le comportement à l'exécution de l'outillage CI/build/dev et des tests/exemples.
Mappez les emplacements dans le périmètre à ces composants et excluez explicitement les éléments hors périmètre.
Ne réclamez pas de composants, de flux ou de contrôles sans preuve.

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

Énumérez les limites de confiance en tant qu'arêtes concrètes entre les composants, en notant le protocole, l'authentification, le chiffrement, la validation et la limitation du débit.
Listez les actifs qui pilotent le risque (données, identifiants, modèles, configurations, ressources de calcul, journaux d'audit).
Identifiez les points d'entrée (points de terminaison, surfaces de téléchargement, analyseurs/décodeurs, déclencheurs de tâches, outils d'administration, puits de journalisation/erreurs).

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

Listez les actifs qui pilotent le risque (identifiants, données personnelles, état critique pour l'intégrité, composants critiques pour la disponibilité, artefacts de build).
Décrivez les capacités réalistes des attaquants en fonction de l'exposition et de l'utilisation prévue.
Notez explicitement les non-capacités pour éviter les sévérités gonflées.

4) Énumérez les menaces en tant que chemins d'abus

Préférez les objectifs des attaquants qui correspondent à des actifs et des limites (exfiltration, escalade de privilèges, compromission d'intégrité, refus de service).
Classifiez chaque menace et liez-la aux actifs impactés.
Gardez le nombre de menaces petit mais de haute qualité.

5) Priorisez avec des justifications explicites de probabilité et d'impact

Utilisez la probabilité et l'impact qualitatifs (faible/moyen/élevé) avec des justifications brèves.
Définissez la priorité globale (critique/élevée/moyenne/basse) en utilisant probabilité × impact, ajusté pour les contrôles existants.
Énoncez quelles hypothèses influencent le plus le classement.

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

Résumez les hypothèses clés qui affectent matériellement le classement des menaces ou le périmètre, puis demandez à l'utilisateur de les confirmer ou corriger.
Posez 1–3 questions ciblées pour résoudre 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-location).
Pause et attendez les retours de l'utilisateur avant de produire le rapport final.
Si l'utilisateur refuse ou ne peut pas répondre, énoncez quelles hypothèses restent et comment elles influencent la priorité.

7) Recommandez les atténuations et les chemins de focus

Distinguez les atténuations existantes (avec preuve) des atténuations recommandées.
Liez les atténuations à des emplacements concrets (composant, limite ou point d'entrée) et aux types de contrôle (vérifications authZ, validation des entrées, application de schéma, sandboxing, limitation du débit, isolation des secrets, journalisation d'audit).
Préférez les conseils de mise en œuvre spécifiques aux conseils génériques (par exemple, « appliquer le schéma à la passerelle pour les charges utiles de téléchargement » vs « valider les entrées »).
Basez les recommandations sur le contexte utilisateur validé ; si des hypothèses restent non résolues, marquez les recommandations comme conditionnelles.

8) Exécutez une vérification de qualité avant la finalisation

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

Guidance de priorisation des risques (illustratif, non exhaustif)

Élevé : RCE pré-auth, contournement d'authentification, accès inter-locataire, exfiltration de données sensibles, vol de clé ou de jeton, compromission d'intégrité du modèle ou de la configuration, échappatoire de sandbox.
Moyen : DoS ciblé de composants critiques, exposition partielle des données, contournement du limitation du débit avec impact mesurable, empoisonnement des journaux/métriques qui affecte la détection.
Faible : fuites d'informations peu sensibles, DoS bruyant avec atténuation facile, problèmes nécessitant des préconditions peu probables.

Références

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

Chargez uniquement les fichiers de référence dont vous avez besoin. Gardez le résultat final concis, fondé et révisable.