Cycle de vie de développement sécurisé - Modèles

En savoir plus sur Well-Architected Trust → Secure Development Lifecycle

La sécurité doit être intégrée tout au long du cycle de développement, depuis la conception initiale jusqu’au déploiement et aux opérations. Ces modèles activent les pratiques de sécurité de poste de travail à gauche, corrigent les vulnérabilités courantes et sécurisent vos pipelines de déploiement.

Modèles

Où chercherÀ quoi ressemble le bien
Développement | Tooling✅ Scan de sécurité IDE intégré au workflow du développeur
Développement | Design✅ Modélisation des menaces terminée pendant la phase de conception en utilisant la méthodologie STRIDE
Développement | Exigences✅ Exigences de sécurité incluses dans les récits utilisateur et critères d’acceptation
Développement | Contrôle de source✅ Les hooks de pré-engagement appliquent les politiques de sécurité (lecture secrète, analyse de code)
Développement | Formation✅ Formation de sécurité des développeurs actualisée régulièrement pour refléter l’évolution des menaces
Développement | CI/CD✅ Les tests de sécurité automatisés dans le pipeline CI/CD échouent sur la base de conclusions critiques
Développement | Révision de code✅ Examens pairs de sécurité requis pour l’authentification, l’autorisation et le code d’accès aux données
Développement | Analyse de code✅ Normes de codage sécurisées appliquées par linters et analyse statique
Développement | Dépendances✅ Analyse de la vulnérabilité de dépendance exécutée à chaque engagement
Développement | Tests✅ La portée du test de pénétration inclut de nouvelles fonctionnalités avant la publication de GA

Anti-modèles

Où chercherÀ quoi ressemble mal
Développement | Tests⚠️ Le test de sécurité reporté à un examen manuel avant la publication
Développement | Formation⚠️ Formation à la sécurité dispensée une seule fois lors de l’intégration
Développement | Révision de code⚠️ L’équipe de sécurité examine le code après la fusion
Développement | Design⚠️ Modèles de menaces non mis à jour lorsque l’architecture change
Développement | Contrôle de source⚠️ Scan secret désactivé pour réduire les faux positifs
Développement | CI/CD⚠️ Constatations de sécurité ignorées lorsque les échéances de publication approchent

Modèles

Où chercherÀ quoi ressemble le bien
Injection✅ Les requêtes SOQL utilisent des variables de liaison pour empêcher l’injection
Injection✅ Entrée utilisateur validée et désinfectée avant utilisation dans des requêtes SOQL, SOSL ou dynamiques
Injection✅ SOQL dynamique limité aux entrées approuvées
Contrôle d’accès✅ Autorisations CRUD et FLS appliquées en utilisant Security.stripInaccessible()
XSS✅ Les composants Lightning échappent les contenus générés par les utilisateurs dans le rendu de l’interface utilisateur
Injection✅ Les intégrations d’API externes valident et désinfectent toutes les entrées
Contrôle d’accès✅ Accès des utilisateurs invités réduit et fortement restreint
Authentification✅ Identifiants nommés utilisés pour l’authentification externe (pas les identifiants codés en dur)
Authentification✅ Flux OAuth 2.0 correctement implémentés avec PKCE
Gestion des sessions✅ Les stratégies de sécurité de session appliquent les restrictions d’expiration et d’adresse IP
Configuration✅ Contrôle d’intégrité de sécurité examiné tous les trimestres et constatations à haut risque corrigées
Contrôle d’accès✅ Métadonnées personnalisées et autorisations auditées pour éviter les privilèges excessifs

Anti-modèles

Où chercherÀ quoi ressemble mal
Injection⚠️ Requêtes SOQL construites en utilisant la concaténation de chaînes avec l’entrée utilisateur
Contrôle d’accès⚠️ Autorisations Créer, Mettre à jour ou Supprimer accordées aux profils utilisateur invité
XSS⚠️ Les composants Lightning utilisent des expressions non échappées dans les modèles
Authentification⚠️ Les intégrations externes utilisent des identifiants codés en dur dans le code
Consignation⚠️ Les journaux de débogage contiennent des données confidentielles telles que des mots de passe ou des PII
Contrôle d’accès⚠️ Contrôles FLS et CRUD omis car « nous contrôlons tous les utilisateurs »
Configuration⚠️ Constatations du Contrôle d’intégrité de sécurité ignorées ou reportées indéfiniment

Modèles

Où chercherÀ quoi ressemble le bien
Pipeline | Contrôle de la source✅ Les règles de protection des agences appliquent automatiquement les examens et les contrôles de statut requis
Pipeline | Contrôle d’accès✅ Les pipelines de déploiement utilisent des comptes de service avec des autorisations minimales requises
Pipeline | Secrets✅ Secrets stockés dans des coffres-forts sécurisés (jamais dans des variables de contrôle de source ou d’environnement)
Pipeline | Déploiement✅ Les déploiements en production nécessitent une porte d’approbation manuelle du personnel autorisé
Pipeline | Audit✅ Les journaux de déploiement capturent qui a déployé quoi quand avec des parcours d’approbation
Pipeline | Validation✅ La validation préalable au déploiement inclut des analyses de sécurité et des contrôles de conformité
Pipeline | Contrôle d’accès✅ Authentification multifacteur requise pour l’accès administratif au pipeline
Pipeline | Surveillance✅ Les changements de configuration du pipeline déclenchent des notifications d’équipe de sécurité
Pipeline | Validation✅ La validation après déploiement automatisée confirme l’activation des contrôles de sécurité attendus
Pipeline | Dépendances✅ Mises à jour de dépendance évaluées pour l’impact de sécurité avant le déploiement

Anti-modèles

Où chercherÀ quoi ressemble mal
Pipeline | Secrets⚠️ Secrets engagés dans le contrôle de version (même s’ils sont retirés ultérieurement)
Pipeline | Contrôle de la source⚠️ Tout le monde peut fusionner à la branche principale/production sans révision
Pipeline | Contrôle d’accès⚠️ Les pipelines de déploiement sont exécutés avec des autorisations de niveau administrateur
Pipeline | Déploiement⚠️ Déploiements en production entièrement automatisés sans portes d’approbation
Pipeline | Audit⚠️ Les journaux de déploiement ne consignent pas qui a initié ou approuvé les modifications
Pipeline | Validation⚠️ Échec des analyses de sécurité ignorées ou contournées pour respecter les délais
Pipeline | Surveillance⚠️ Modifications de la configuration du pipeline non suivies ni examinées
Pipeline | Validation⚠️ La validation post-déploiement vérifie uniquement l’exactitude fonctionnelle

Modèles

Où chercherÀ quoi ressemble le bien
Test | Analyse statique✅ Salesforce Code Analyzer exécuté dans les Developer IDE pour un retour immédiat et dans les pipelines CI/CD en tant que portes automatisées
Test | Test de pénétration✅ Test de pénétration effectué pour les applications personnalisées exposées à des utilisateurs non fiables, en particulier les sites Experience Cloud et les API accessibles au public
Tests | Tests unitaires✅ Les tests unitaires Apex axés sur la sécurité sont exécutés en tant qu’utilisateurs avec différents profils d’autorisation
Test | Dépendances✅ L’analyse des dépendances surveille les packages AgentExchange et les bibliothèques JavaScript pour détecter les vulnérabilités connues
Test | Contrôle de sécurité✅ Rapport d’analyse statique préparé pour chaque soumission AppExchange ou AgentExchange Security Review
Test | Contrôle de sécurité✅ Rapport d’analyse dynamique (test de pénétration) préparé lorsqu’une solution intègre une application Web ou un service tiers
Test | Dépendances✅ Avis de sécurité pour les packages installés abonnés et surveillés

Anti-modèles

Où chercherÀ quoi ressemble mal
Test | Couverture⚠️ Le test de sécurité repose sur une technique unique telle que l’analyse statique seule
Tests | Tests unitaires⚠️ Les tests Apex valident le comportement fonctionnel mais ne sont jamais exécutés en tant qu’utilisateurs à faible privilège
Test | Contrôle de sécurité⚠️ Soumission AppExchange ou AgentExchange préparée sans l’analyse statique requise ni les rapports d’analyse dynamique
Test | Test de pénétration⚠️ Test de pénétration ignoré pour les sites et les API Experience Cloud accessibles au public

Voir aussi :