Sécurité dès la conception
Développement logiciel sécurisé
Nous développons et maintenons des applications dans un système certifié au titre du Schéma national de sécurité espagnol, catégorie MOYENNE. Chaque modification passe par des analyses de sécurité automatiques avant d'arriver en production : c'est la garantie de qualité de nos logiciels sur mesure et de nos produits.
Approche
La sécurité au cœur du cycle de développement
Le périmètre de notre certification ENS couvre précisément les systèmes d'information qui servent au développement et à la maintenance d'applications informatiques. La sécurité n'est pas vérifiée à la fin : elle est contrôlée automatiquement à chaque modification et laisse des preuves auditables.
- Exigences de sécurité dès la conception : contrôle d'accès, journalisation de l'activité et protection de l'information.
- Des analyses automatiques qui bloquent l'intégration lorsqu'elles détectent des problèmes graves.
- Des résultats publiés à chaque revue et des rapports conservés comme preuves.
- Ce qui n'a pas pu être analysé est signalé explicitement : rien n'est considéré comme acquis.
- Le code écrit avec l'aide de l'IA est relu par un développeur et passe les mêmes analyses (utilisation sûre de l'IA).
Pipeline de sécurité
Ce que nous vérifions à chaque modification
Les analyses s'exécutent dans nos pipelines d'intégration continue. Si une analyse ne respecte pas son seuil, la modification n'est pas intégrée tant qu'elle n'a pas été corrigée ou justifiée.
-
Contrôle
Modification revue
Toute modification passe par une demande d'intégration (pull request) dans laquelle les analyses sont exécutées et leurs résultats publiés.
Rien n'est intégré sans revue ni sans analyses.
-
SAST
Analyse statique avec Semgrep
Règles de code, de conformité, d'infrastructure et de secrets, plus des règles internes rattachées aux mesures de l'ENS et de l'ISO/IEC 27001.
Bloque les résultats de gravité élevée.
-
SCA
Dépendances et images avec Trivy
Recherche les CVE connues dans les paquets et dans les images de conteneur mises en production.
Bloque les CVE élevées ou critiques pour lesquelles un correctif existe.
-
DAST
Tests dynamiques avec OWASP ZAP
Teste l'application en cours d'exécution, sans identifiants (boîte noire) et authentifiée (boîte grise).
Bloque les résultats de risque élevé.
Le scan dynamique actif n'est lancé que sur des environnements éphémères ou de préproduction dont les données peuvent être perdues, jamais sur les données réelles d'un client. Les exceptions concernant une CVE sans correctif compatible sont acceptées avec leur justification documentée.
Configuration sécurisée
En-têtes, politiques et infrastructure
Les applications web sont publiées avec des en-têtes de sécurité restrictifs. Ce site lui-même est servi avec ces en-têtes et sans ressources tierces.
- Politique de sécurité du contenu (CSP) stricte, sans scripts ni styles en ligne
- HTTPS obligatoire avec HSTS
- Protection contre l'intégration dans des cadres d'autres sites
- Autorisations du navigateur limitées (caméra, micro, localisation, paiements)
- Politique de référent et isolation entre origines
- Contrôle du type de contenu (nosniff)
Infrastructure as code revue
Les fichiers de déploiement passent eux aussi par l'analyse statique, avec des règles internes alignées sur les mesures de configuration de sécurité de l'ENS : images à version figée, secrets hors du code, bases de données non exposées, conteneurs sans privilèges et réseaux internes chiffrés.
Dans des produits comme CIGES, l'accès prend en charge l'annuaire d'entreprise (LDAP) ou l'authentification unique et l'authentification à deux facteurs ; dans ACAE, les actions de chaque utilisateur sont en outre journalisées.
Gestion des vulnérabilités
Des vulnérabilités avec identifiant CVE
Nous sommes autorité de numérotation CVE (CNA), sous la supervision de l'INCIBE. Lorsqu'une vulnérabilité est découverte dans l'un de nos produits, nous la corrigeons, prévenons les clients concernés avant sa divulgation publique et la publions avec son identifiant CVE et la version qui la corrige.
Questions fréquentes
Vos questions sur le développement sécurisé
Quelle différence entre SAST, SCA et DAST ?
Le SAST analyse le code source sans l'exécuter ; le SCA examine les bibliothèques et les images tierces à la recherche de vulnérabilités connues (CVE) ; le DAST attaque l'application en cours d'exécution comme le ferait un utilisateur externe. Ils sont complémentaires : chacun détecte des problèmes que les autres ne voient pas.
Quelles mesures de l'ENS le développement sécurisé couvre-t-il ?
Principalement celles relatives à la protection des applications informatiques : développement des applications (mp.sw.1) et recette et mise en service (mp.sw.2), ainsi que la configuration de sécurité et la gestion des vulnérabilités du cadre opérationnel. Dans l'ISO/IEC 27001:2022, elles correspondent aux mesures relatives au cycle de développement sécurisé, au codage sécurisé et aux tests de sécurité.
Que se passe-t-il si une vulnérabilité est découverte dans l'un de vos produits ?
Elle est évaluée, corrigée et les clients concernés sont prévenus avant la divulgation publique, conformément à notre politique de divulgation des vulnérabilités. En tant qu'autorité de numérotation CVE, nous lui attribuons un identifiant CVE et la publions dans la liste des vulnérabilités.
Pouvez-vous appliquer ce processus à un développement sur mesure pour mon organisation ?
Oui. Les projets de logiciels sur mesure sont développés selon le même processus, dans le périmètre de notre certification ENS MOYENNE.
Besoin d'un logiciel sécurisé pour votre organisation ?
Nous développons des applications sur mesure dans un système certifié ENS catégorie MOYENNE.
