APP / APP-01
Modélisation des menaces et conception sécurisée
Examiner une application avant ou pendant sa conception pour identifier les actifs sensibles, les limites de confiance et les scénarios d'abus. L'objectif est de sélectionner les contrôles appropriés avant que les erreurs architecturales ne deviennent coûteuses à corriger.
QUAND C'EST UTILE
Une réponse ciblée
à un besoin défini.
Un nouveau portail, une architecture multitenant, un changement de système d’identité, une intégration de paiement ou de données sensibles, ou un projet d’IA impliquant des systèmes informatiques.
EN UN COUP D'ŒIL
Famille
Sécurité des applications
Engagement
Conseil et mise en œuvre
Référence
APP-01
PORTÉE ET RÉSULTATS
Ce que couvre la mission.
Portée
- Ateliers d'affaires et d'architecture
- flux de données
- acteurs et privilèges
- scénarios d'abus
- contrôles de sécurité
- Des exigences testables
- Risques résiduels et propriété
Livrables
- Diagrammes annotés
- modèle de menace
- exigences de sécurité prioritaires
- Décisions architecturales
- tests prévus
- Risques acceptés ou nécessitant un traitement
Preuve de réception
Les principaux scénarios sont examinés en collaboration avec les équipes commerciales ; les exigences sont définies et testables ; les décisions sont documentées ; des examens sont planifiés pour les changements majeurs.
LIVRAISON
Comment le travail est structuré.
Approche
Comprendre l’architecture ; sélectionner les risques et les exigences ; intégrer ou vérifier les contrôles ; tester ; les transmettre aux équipes et planifier des contrôles de régression.
Prérequis et responsabilités
Client : code, architecture, développeurs, environnement de test et accès au pipeline. Fournisseur : expertise et contrôles ; correction du code uniquement lorsqu'elle est incluse.
Facteurs de portée
Applications, langages, référentiels, dépendances, rôles, pipelines, volume et profondeur. Séparer les licences d'outils, le développement de remédiation et la maintenance.
Questions à clarifier
Quelles actions causeraient le plus de dommages ? Où sont franchies les limites de la confiance ? Quelles décisions architecturales peuvent encore être modifiées ?
LIMITES IMPORTANTES
La modélisation des menaces n’est ni le test de pénétration ni la preuve de l’absence de failles. Sa valeur dépend de la qualité de l’information et des mises à jour après les modifications.
Les contrôles s'appliquent aux versions et au périmètre convenus. Aucun scanner, SBOM ou framework ne garantit à lui seul la sécurité du logiciel livré.
EN PRATIQUE
Situations illustratives.
Ces exemples décrivent des engagements possibles et des résultats cibles. Il ne s'agit pas de références clients ni de résultats obtenus.
Scénario 01
Un fournisseur prépare une application multirent. Projet : modèle d’accès et de partage des données des clients avant le développement. Objectif : les exigences d’isolation sont incluses dans le backlog et les tests plutôt que d’être ajoutées après le lancement.
Scénario 02
Une équipe ajoute un agent IA capable de modifier les données. Projet : évaluer les outils et les décisions sensibles. Objectif : limites d’action et approbations humaines prévues à l’avance ; certaines outils ne seront pas inclus dans le pilotage.
Contexte technologique et de référence
Références : pratiques d’OWASP et SSDF de NIST ; diagrammes et exigences indépendants de tout outil obligatoire.
L'ensemble final des technologies est convenu lors du cadrage, sur la base de l'interopérabilité, des licences, des droits d'accès et des exigences opérationnelles.
SERVICES CONNECTÉS
Construisez l'étape suivante.
Ces services peuvent compléter la mission. Ils ne sont pas inclus automatiquement.
Commencer une conversation
Clarifiez la portée.
Nous clarifierons l'objectif, les dépendances et les responsabilités de ce service avant de proposer la livraison.