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

01

Cartographier le cycle actuel

Dépôts, environnements, qui livre, comment on hotfix. On décrit le vrai flux, pas le flux idéal.

02

Exigences dans le changement

Ce qui doit être demandé, revu et testé avant d’aller plus loin. Proportionné à la criticité.

03

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.

04

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.

Prêt à encadrer vos mises en production ?

On part de votre façon actuelle de livrer. Pas besoin d’un pipeline parfait pour commencer.

Discuter de ce module