Politique de développement sécurisé
Cette politique décrit comment France Nuage conçoit, écrit, teste et livre le code qui fait tourner sa plateforme. Elle décline, sur le volet développement, les principes de notre politique de sécurité de l'information et couvre les contrôles A.5.8 et A.8.25 à A.8.31 de la déclaration d'applicabilité.
Nos contrôles sont auto-évalués, alignés sur ISO/IEC 27001, non certifiés par un tiers à ce jour. Le statut de chaque mesure ci-dessous reflète cette auto-évaluation.
Objet et périmètre
La politique s'applique à tout le code que nous écrivons et déployons : plan de contrôle, console d'administration, interface en ligne de commande nuage, SDK, ainsi que les charts Helm et l'infrastructure décrite en code. Elle couvre également la chaîne d'intégration continue qui valide et promeut ces changements. Elle concerne les salariés, les prestataires et toute contribution externe.
Principes
- La sécurité se décide en amont. Les choix structurants (authentification, autorisation, cryptographie) font l'objet d'une décision d'architecture écrite avant d'être codés, pas d'un correctif après coup.
- Fail-closed. En cas de doute, d'erreur ou d'indisponibilité d'un composant de sécurité, le code refuse l'accès plutôt que de l'accorder.
- Le langage fait une partie du travail. Le cœur de la plateforme est écrit dans un langage à sûreté mémoire, ce qui élimine des classes entières de vulnérabilités au lieu de les traquer une par une.
- Ce qui n'est pas testé n'est pas garanti. Les propriétés de sécurité sont exprimées sous forme d'assertions exécutées à chaque changement, pas de bonnes intentions dans une documentation.
- Aucune donnée de production hors production. Les jeux d'essai sont synthétiques ; qualification et production ne partagent ni cluster, ni identifiants.
Mesures
| Domaine | Mesure |
|---|---|
| Cycle de vie | Cycle gouverné par des décisions d'architecture documentées, une chaîne d'intégration continue multi-étapes et une revue de code automatisée sur chaque demande de fusion (A.8.25). |
| Exigences applicatives | Exigences de sécurité explicitement spécifiées (comportement fail-closed, anti-CSRF, anti-rejeu) et appliquées dans le code d'authentification (A.8.26). |
| Architecture | Défense en profondeur : client confidentiel, autorisation fine par relations, chiffrement au repos, isolation par locataire, durcissement des pods (A.8.27). |
| Codage | Lint bloquant, langage à sûreté mémoire (Rust) sur le cœur de la plateforme, garde-fous de code : garde de compilation empêchant tout composant factice en production, effacement mémoire des clés, rédaction des secrets dans les journaux (A.8.28). |
| Tests | Tests unitaires, d'autorisation, d'intégration et de sécurité des manifestes exécutés en intégration continue comme conditions de recette (A.8.29). |
| Environnements | Clusters et espaces de noms distincts entre qualification et production, identifiants séparés, promotion vers la production limitée à la branche principale (A.8.31). |
| Chaîne d'intégration | Sécurité intégrée à la chaîne : analyse de secrets bloquante, puis analyse d'infrastructure en code et de dépendances (A.5.8). |
| Développement externalisé | Développement principalement interne ; toute contribution externe suit la même chaîne de validation que le code interne (A.8.30, partiel). |
Responsabilités
- Le RSSI (François-Guillaume Ribreau) est responsable de cette politique et des exigences de sécurité applicables au code.
- Chaque personne qui soumet du code répond de la sécurité de ce qu'elle propose et ne contourne aucune condition de recette bloquante.
- Toute faiblesse constatée dans le code ou dans la chaîne de livraison est signalée sans délai à security@france-nuage.fr.
Statut et trajectoire
Le cycle de développement, les exigences applicatives, l'architecture, le codage sécurisé, les tests de sécurité et la séparation des environnements sont en place et opérationnels (A.8.25–A.8.29, A.8.31, A.5.8). Le développement externalisé reste partiel (A.8.30). Le développement est aujourd'hui principalement interne et les critères d'acceptation d'une contribution externe restent à formaliser.
Deux compléments portent sur la chaîne d'intégration elle-même et sont détaillés dans notre politique de veille et de gestion des vulnérabilités, à savoir la détection CVE automatisée (A.8.8) et l'analyse antimalware des images (A.8.7), toutes deux à câbler dans la CI. Les réglages de protection de la branche de code (A.8.4) restent à documenter, comme indiqué dans notre politique de gestion des changements.
Revue
Cette politique est revue au moins une fois par an et à chaque évolution significative de notre chaîne de développement ou de livraison.
Dernière revue : 31 août 2026.
Voir aussi
- Déclaration d'applicabilité (le statut des contrôles A.5.8 et A.8.25–31)
- Politique de gestion des changements (comment un changement passe de la demande de fusion à la production)
- Politique de veille et de gestion des vulnérabilités (le traitement des failles publiées et des dépendances)
- Modèle de sécurité (les couches de défense que ce cycle de développement met en œuvre)
- Politique de sécurité de l'information (le cadre du SMSI dont cette politique découle)