Développement sécurisé
ISO 27001 ne demande pas de tout scanner en continu. Elle demande que le développement, les tests et les mises en production soient encadrés. Nous posons des règles proportionnées à votre équipe.
Ce qu’on voit trop souvent
Quand on livre du code, l’audit ne se contente pas d’une politique « on fait attention ». Il veut savoir comment une exigence de sécurité entre dans une demande, qui revoit le code, et ce qui bloque une mise en production.
- les mêmes accès pour tout le monde sur le dépôt et la production
- aucun critère de release, ou un critère que personne n’applique
- secrets dans le code, dans un clavardage, ou dans un fichier partagé
- tests de sécurité « quand on a le temps », jamais avant une livraison majeure
- pigistes et agences hors des règles internes
De quoi s’agit-il
Le développement sécurisé, en ISO 27001, c’est encadrer le cycle : environnements, changements, revues, tests proportionnés, secrets, critères de mise en production. Ce n’est pas l’obligation d’un scanner en continu sur tout, ni un pentest à chaque commit.
Nous posons un standard que votre équipe (interne ou externe) peut suivre. Si vous n’avez pas de pipeline CI/CD, on part de votre façon actuelle de livrer. Les revues et les critères de release existent dès le premier jour.
Où ça se situe dans ISO 27001
Le module vise surtout les contrôles de l’Annexe A liés au développement et aux tests (dont A.8.28 et A.8.29), dans la proportion de votre réalité. Si vous ne développez pas, ces contrôles se traitent plutôt dans la SoA.
Ce que comprend ce module
- Cadrage des environnements (dev, test, production)
- Exigences de sécurité dans les demandes de changement
- Revues de code et tests de sécurité proportionnés
- Contrôle des accès aux dépôts et aux secrets
- Critères de mise en production
Comment on travaille
Cartographier le cycle actuel
Dépôts, environnements, qui livre, comment on hotfix. On décrit le vrai flux, pas le flux idéal.
Exigences dans le changement
Ce qui doit être demandé, revu et testé avant d’aller plus loin. Proportionné à la criticité.
Secrets, accès, environnements
Séparation dev / test / prod, gestion des secrets, accès aux dépôts. Les externes suivent les mêmes règles.
Critères de mise en production
Checklist de release, quand un test de sécurité est exigé, qui peut déroger. Le pentest reste un service distinct.
Ce que vous recevez
- Standard de développement sécurisé
- Checklist de revue avant mise en production
- Procédure de gestion des secrets et des environnements
- Exigences minimales pour le pipeline CI/CD
Pour qui
Éditeurs de logiciels, équipes produit et TI internes qui livrent du code, des API ou des intégrations.
Pour qui ce n’est pas
Ce module n’est pas un pentest, ni un audit de code complet, ni la gestion des accès de toute l’entreprise. Il n’est pas utile si vous n’écrivez ni ne faites écrire de logiciel.
Durée type
2 à 5 semaines selon la maturité de votre pipeline.
Ce que vous devez fournir
Vous donnez accès (en lecture) à un dépôt représentatif, à la description du pipeline, et à un lead tech. La liste des contributeurs externes est essentielle.
Limites de ce module
Ce module encadre le développement. Il ne remplace pas un pentest, ni la gestion des accès de toute l’entreprise.
Questions fréquentes
- Faut-il un pentest dans ce module ?
- Pas automatiquement. Le pentest est un service distinct. Ici, nous posons quand un test est exigé avant une mise en production majeure.
- Et si nous n’avons pas de pipeline CI/CD ?
- Nous partons de votre façon actuelle de livrer. Un pipeline n’est pas obligatoire le premier jour; des revues et des critères de release le sont.
- Cela couvre-t-il les développeurs externes ?
- Oui, les mêmes règles s’appliquent aux pigistes et fournisseurs. Les accès et les revues font partie du livrable.
- Peut-on acheter seulement ce module ?
- Oui. Chaque module se vend séparément. Vous n’êtes pas obligé de prendre le programme complet. Le prédiagnostic reste le point d’entrée le plus efficace si vous ne savez pas encore par où commencer.
- Faut-il commencer par le prédiagnostic ?
- Non, ce n’est pas obligatoire. Le prédiagnostic accélère le cadrage si vous n’avez pas encore de photo d’ensemble. Si vous savez déjà ce qui manque, on peut démarrer ce module directement.