Sécuriser l’Application Elle-Même — En Tant que Système Réglementé
La sécurité applicative se concentre sur la protection du logiciel tout au long de son cycle de vie — de la conception et du développement au déploiement et à l’exécution. Dans les environnements réglementés, cela va au-delà de la simple recherche de bugs : cela signifie construire des systèmes prouvables qui démontrent que les vulnérabilités sont systématiquement identifiées, suivies et remédiées dans les délais réglementaires.
Ce guide couvre les disciplines fondamentales de la sécurité applicative — SAST, DAST, SCA, SBOM et modélisation des menaces — et comment les implémenter d’une manière qui répond aux exigences de DORA, NIS2, ISO 27001, SOC 2 et PCI DSS.
1. Tests Statiques de Sécurité des Applications (SAST)
SAST analyse le code source ou compilé pour identifier les vulnérabilités de sécurité sans exécuter l’application. C’est un outil fondamental du « shift left » qui détecte les problèmes au plus tôt du cycle de développement.
Comment fonctionne SAST
Les outils SAST analysent le code source, le bytecode ou les binaires pour les schémas qui indiquent des vulnérabilités de sécurité — injections SQL, cross-site scripting (XSS), dépassements de mémoire tampon, failles cryptographiques et plus. Ils fonctionnent en construisant des modèles de flux de données et de flux de contrôle de l’application, puis en recherchant des chemins où des données non fiables atteignent des opérations sensibles.
SAST dans les environnements réglementés
Pour les environnements réglementés, SAST fournit :
- Preuve de test de sécurité — Les résultats d’analyse SAST documentent que le code a été analysé pour les vulnérabilités connues.
- Détection précoce — Les problèmes trouvés dans le code sont moins coûteux et moins risqués à corriger que ceux trouvés en production.
- Application des politiques — Les règles SAST peuvent codifier les standards de codage sécurisé requis par les cadres réglementaires.
- Suivi des tendances — Le suivi des découvertes SAST dans le temps démontre une amélioration continue de la posture de sécurité.
Intégration SAST
Intégrez SAST dans le pipeline CI à deux points :
- Analyse des pull requests — Analyse incrémentale sur les changements de code pour un retour rapide aux développeurs.
- Analyse complète — Analyse complète de la base de code sur les branches principales pour une couverture globale.
Définissez des seuils clairs : les découvertes critiques bloquent la fusion, les découvertes élevées nécessitent une révision, les découvertes moyennes et basses sont suivies pour remédiation.
2. Tests Dynamiques de Sécurité des Applications (DAST)
DAST teste les applications en cours d’exécution de l’extérieur, simulant les attaques réelles. Il complète SAST en trouvant des vulnérabilités qui ne se manifestent qu’au runtime — erreurs de configuration, problèmes d’authentification et failles de logique métier.
Comment fonctionne DAST
Les outils DAST interagissent avec une application en cours d’exécution via HTTP/HTTPS, envoyant des requêtes malformées et des payloads d’attaque pour identifier les vulnérabilités. Ils ne nécessitent pas d’accès au code source, ce qui les rend utiles pour tester les applications tierces et valider que les corrections SAST sont efficaces.
DAST dans les environnements réglementés
DAST est particulièrement précieux pour la conformité réglementaire car il :
- Valide les contrôles de sécurité au runtime — prouvant qu’ils fonctionnent réellement, pas seulement qu’ils existent dans le code.
- Teste ce que les auditeurs testent — Les tests d’intrusion (souvent requis par PCI DSS et d’autres cadres) sont essentiellement du DAST manuel.
- Découvre les erreurs de configuration — Mauvaise configuration des en-têtes de sécurité, gestion des sessions et contrôles d’accès.
Intégration DAST
Exécutez DAST dans les environnements staging qui reflètent la production. Intégrez dans le pipeline CI/CD comme une porte post-déploiement avant la promotion en production. Pour les applications exposées sur le web, programmez des analyses régulières en plus de l’analyse basée sur le pipeline.
3. Analyse de Composition Logicielle (SCA)
SCA identifie les composants open source et tiers dans votre application et les compare aux bases de données de vulnérabilités connues. Étant donné que les applications modernes se composent généralement de 70-90% de code open source, SCA est essentiel pour gérer le risque de la chaîne d’approvisionnement.
Comment fonctionne SCA
Les outils SCA analysent les manifestes de dépendances (package.json, pom.xml, requirements.txt, go.mod, etc.), les fichiers de verrouillage et parfois les binaires pour identifier toutes les dépendances directes et transitives. Ils comparent ensuite ces composants aux bases de données de vulnérabilités (NVD, GitHub Advisory Database, OSV) et aux bases de données de licences.
SCA dans les environnements réglementés
SCA aborde plusieurs exigences réglementaires :
- Sécurité de la chaîne d’approvisionnement — Requis par DORA (Art. 28), NIS2 (Art. 21) et d’autres cadres.
- Gestion des vulnérabilités — Preuve que les vulnérabilités connues sont identifiées et suivies.
- Conformité des licences — Certains cadres réglementaires exigent la connaissance des composants et licences tiers.
- Gestion des correctifs — SCA fournit les données nécessaires pour prioriser et suivre les mises à jour de dépendances.
Intégration SCA
Exécutez SCA à chaque build de pipeline et lors des vérifications de pull request. Configurez des alertes automatiques pour les nouvelles vulnérabilités dans les dépendances existantes (pas seulement les nouvelles dépendances). Définissez des délais clairs de remédiation par sévérité.
4. Nomenclature Logicielle (SBOM)
Un SBOM est un inventaire formel de tous les composants d’un logiciel — dépendances directes, dépendances transitives, versions et relations. C’est de plus en plus exigé par les cadres réglementaires et les contrats gouvernementaux.
Pourquoi SBOM est important
SBOM fournit la transparence dans la composition des logiciels, permettant :
- Réponse aux vulnérabilités — Quand une nouvelle CVE est publiée, SBOM vous permet de déterminer rapidement si vos applications sont affectées.
- Conformité réglementaire — DORA, NIS2 et divers mandats gouvernementaux exigent de plus en plus des capacités SBOM.
- Due diligence des tiers — Les clients et partenaires demandent de plus en plus des SBOM dans les processus d’approvisionnement.
- Gestion des licences — SBOM permet une conformité automatisée des licences.
Formats SBOM
Les deux principaux formats SBOM sont :
- SPDX (Software Package Data Exchange) — Standard ISO (ISO/IEC 5962:2021), largement adopté dans les contextes gouvernementaux et réglementaires.
- CycloneDX — Standard OWASP, riche en fonctionnalités axées sécurité, y compris l’intégration de données de vulnérabilité.
Intégration SBOM
Générez des SBOM automatiquement dans le pipeline CI/CD à chaque build de release. Stockez les SBOM comme artefacts de build avec un lien vers l’image de conteneur ou le binaire spécifique. Implémentez une surveillance continue de SBOM pour alerter lorsque des vulnérabilités sont découvertes dans les composants listés.
5. Modélisation des Menaces
La modélisation des menaces est le processus d’identification des menaces de sécurité, des vulnérabilités et des atténuations à la phase de conception — avant que le code ne soit écrit. C’est le complément « shift left » le plus poussé du scanning automatisé.
Approches de la modélisation des menaces
Plusieurs méthodologies existent :
- STRIDE — Catégorise les menaces en Spoofing, Tampering, Repudiation, Information disclosure, Denial of service et Elevation of privilege.
- PASTA (Process for Attack Simulation and Threat Analysis) — Approche centrée sur le risque qui s’aligne bien avec les cadres de gestion des risques réglementaires.
- LINDDUN — Axé sur les menaces à la vie privée, pertinent pour la conformité RGPD.
Modélisation des menaces dans les environnements réglementés
Les cadres réglementaires exigent de plus en plus une évaluation des risques (DORA Art. 5-6, NIS2 Art. 21, ISO 27001 clause 6.1). La modélisation des menaces fournit une approche structurée pour satisfaire cette exigence au niveau applicatif. Documentez les modèles de menaces et liez-les aux contrôles de sécurité dans votre pipeline.
6. Gestion des Vulnérabilités
Trouver les vulnérabilités n’est que la moitié du problème. Les environnements réglementés exigent des processus prouvables pour suivre, prioriser et remédier aux vulnérabilités dans des délais définis.
Cycle de vie des vulnérabilités
Définissez un cycle de vie clair pour les vulnérabilités :
- Découverte — Identifiée par SAST, DAST, SCA ou test d’intrusion.
- Triage — Évaluée pour sa sévérité, son exploitabilité et son impact métier.
- Remédiation — Corrigée, atténuée ou acceptée (avec documentation).
- Vérification — Confirmée comme résolue par un re-scan.
- Clôture — Documentée et enregistrée pour les preuves d’audit.
SLA de remédiation
Définissez des délais de remédiation par sévérité :
- Critique — 24-72 heures (selon le cadre et le contexte).
- Élevé — 7-30 jours.
- Moyen — 30-90 jours.
- Faible — 90-180 jours ou release suivante.
Documentez les SLA et suivez leur respect. Les preuves de suivi des SLA de remédiation sont précieuses pour les preuves d’audit.
7. Sécurité des API
Les applications modernes sont des systèmes axés API. La sécurité des API nécessite une attention spécifique car les API exposent la logique métier et les données directement.
Tests de sécurité des API
Implémentez des tests de sécurité spécifiques aux API :
- Validation des schémas — Vérifiez que les API respectent leur spécification OpenAPI/Swagger.
- Tests d’authentification/autorisation — Testez les BOLA (Broken Object Level Authorization) et autres failles d’accès.
- Limitation de débit — Vérifiez que les limites de débit sont en place et efficaces.
- Validation des entrées — Testez les attaques par injection sur tous les paramètres API.
Inventaire des API
Maintenez un inventaire de toutes les API exposées par vos applications. Les API fantômes — endpoints non documentés ou oubliés — représentent un risque de sécurité significatif et un risque de conformité.
8. Cartographie de la Conformité
Le tableau suivant montre comment les pratiques de sécurité applicative s’alignent sur les principaux cadres réglementaires :
| Pratique | DORA | NIS2 | ISO 27001 | SOC 2 | PCI DSS |
|---|---|---|---|---|---|
| SAST | Art. 9 (Tests) | Art. 21 (Sécurité) | A.8.28 (Codage sécurisé) | CC8.1 | 6.5 (Dev. sécurisé) |
| DAST | Art. 9 (Tests) | Art. 21 (Sécurité) | A.8.29 (Tests) | CC7.1 | 6.6 (Tests apps web) |
| SCA | Art. 28 (Tiers) | Art. 21 (Chaîne appro.) | A.8.28 | CC9.2 | 6.3 (Apps sécurisées) |
| SBOM | Art. 28 | Art. 21 | A.5.23 | CC3.2 | 6.3 |
| Modélisation menaces | Art. 5-6 | Art. 21 | A.8.28 | CC3.1 | 6.5 |
| Gestion vulnérabilités | Art. 9 | Art. 21 | A.8.8 | CC7.1 | 6.1 |
En savoir plus
La sécurité applicative est un pilier clé du DevSecOps dans les Environnements Réglementés. Pour la sécurité des pipelines de livraison, voir notre guide sur la Sécurité CI/CD. Pour la cartographie vers les cadres de conformité spécifiques, consultez la Cartographie de la Conformité.
