DevSecOps : intégrer la sécurité dans la mise en ligne

Le DevSecOps consiste à placer des contrôles de sécurité dans la chaîne de mise en ligne elle-même, au lieu de les faire une fois à la fin. Pour une PME, trois gestes ont le meilleur rapport effort/protection : surveiller les composants tiers qui présentent des vulnérabilités connues, ne jamais laisser de mot de passe ou de clé dans le code, et faire relire les changements avant leur publication. Ces mesures réduisent des risques courants ; elles ne garantissent pas qu’une application est inviolable.

Cet article présente une version accessible, sans prérequis techniques, pour aider à dialoguer avec un prestataire. Pour un audit ou un test d’intrusion, un périmètre précis reste nécessaire : voir notre page cybersécurité. Pour l’organisation du déploiement lui-même, voir DevOps et hébergement.

Pourquoi parler de sécurité dès le déploiement ?

Un site moderne est rarement écrit de zéro : il assemble un framework, des dizaines ou des centaines de bibliothèques, des services d’hébergement et des outils de publication. Chacun de ces éléments peut contenir une faille ou être compromis. L’OWASP, fondation de référence en sécurité applicative, a classé en troisième position de son Top 10 de 2025 les « défaillances de la chaîne d’approvisionnement logicielle » (Software Supply Chain Failures), une catégorie qui élargit l’ancien risque des composants vulnérables ou obsolètes. Elle couvre les dépendances, les systèmes de build et l’infrastructure de distribution (OWASP, A03:2025).

Une mauvaise configuration figure en deuxième position (OWASP, A02:2025). Dans les deux cas, ce sont des problèmes que des contrôles automatisés dans la chaîne de déploiement peuvent aider à repérer plus tôt.

Comment surveiller les dépendances d’un projet ?

Une dépendance est un composant écrit par d’autres que votre projet utilise. Quand une faille y est publiée, les outils d’analyse comparent la liste de vos composants et de leurs versions avec des bases d’avis de sécurité, puis signalent ceux qui sont concernés.

Les plateformes de code proposent ces fonctions. GitHub, par exemple, indique que les alertes Dependabot croisent le graphe de dépendances d’un dépôt avec les avis publiés dans sa base d’avis de sécurité, et peuvent proposer des mises à jour de sécurité (GitHub Docs, fonctions de sécurité). La disponibilité de chaque fonction dépend du type de dépôt et de l’offre : vérifiez la documentation de votre plateforme.

Pour que ce suivi serve à quelque chose :

• Désignez un responsable qui lit les alertes et décide.
• Classez par exposition : une faille dans un composant réellement utilisé et accessible depuis Internet passe avant une faille dans un outil de développement.
• Mettez à jour par petits pas, avec les contrôles automatiques et la recette avant la production.
• Conservez la liste des composants : l’OWASP recommande de tenir un inventaire (SBOM, nomenclature logicielle) et de privilégier les paquets signés.

Une alerte n’est pas toujours une urgence : certaines failles ne s’appliquent pas à votre usage. Mais ignorer toutes les alertes ou ne jamais mettre à jour crée un risque durable.

Comment éviter de laisser des secrets dans le code ?

Un secret est une information qui donne accès : mot de passe, clé d’API, jeton, identifiant de base de données. Le laisser dans le code source, dans un fichier de configuration versionné ou dans un message est l’une des erreurs les plus fréquentes. Une fois dans l’historique d’un dépôt, il peut rester lisible longtemps, même si la ligne a été supprimée ensuite.

Mesures simples :

• Stocker les secrets dans le gestionnaire prévu par l’hébergeur ou par la plateforme de déploiement, pas dans le dépôt.
• Utiliser des variables d’environnement différentes selon la recette et la production.
• Activer l’analyse des secrets quand la plateforme le propose. GitHub décrit une fonction de détection des secrets qui analyse un dépôt à la recherche de clés ou de jetons, et une protection au moment du dépôt qui peut bloquer l’envoi de secrets pris en charge (GitHub Docs).
• Révoquer et remplacer tout secret exposé : le retirer du code ne suffit pas, il faut considérer qu’il a pu être lu.
• Limiter les droits de chaque clé à ce dont l’usage a besoin, et préférer des identifiants à durée limitée lorsque c’est possible : l’OWASP recommande d’éviter les clés statiques dans le code et les chaînes de déploiement.

Le principe vaut aussi pour les échanges : ne transmettez jamais un mot de passe par courriel ou dans un ticket. Convenez d’un canal de partage sécurisé avec votre prestataire.

Que doit vérifier une revue de code ?

La revue consiste à faire relire un changement par une deuxième personne avant publication. Elle attrape des erreurs de logique, des oublis de contrôle d’accès, des données sensibles affichées ou journalisées par erreur, des dépendances ajoutées sans raison.

Pour qu’elle soit efficace sans devenir une formalité, donnez-lui une liste courte de points :

• Un utilisateur peut-il accéder à des données qui ne sont pas les siennes ?
• Les entrées reçues (formulaires, paramètres d’URL, fichiers téléversés) sont-elles validées ?
• Les messages d’erreur révèlent-ils des informations internes ?
• Une nouvelle dépendance est-elle justifiée, maintenue et de provenance claire ?
• Des secrets ou des données personnelles figurent-ils dans le changement ?

Dans une très petite équipe, la revue peut être assurée par le prestataire et validée par vous sur les points fonctionnels. L’important est qu’aucun changement ne parte en production sans trace d’une relecture.

Quels contrôles automatiques ajouter avant la mise en ligne ?

Plusieurs contrôles peuvent s’exécuter à chaque changement :

Introduisez ces contrôles progressivement. Un outil qui produit des centaines d’alertes dès le premier jour sera désactivé. Commencez par les dépendances et les secrets, puis ajoutez le reste quand l’équipe sait traiter les résultats. Un contrôle qui bloque la publication doit rester rare et justifié ; les autres peuvent signaler sans bloquer.

Un test d’intrusion réalisé par un spécialiste, avec un périmètre et une autorisation écrite, complète ces contrôles automatiques sans les remplacer.

Qui est responsable quand une faille est découverte ?

Prévoyez la réponse avant l’incident : qui évalue la gravité, qui corrige, qui informe, et à quel moment un retour arrière est décidé. Si des données personnelles sont concernées, l’entreprise a des obligations de notification : consultez les pages de la CNIL sur les violations de données. Pour une première orientation, Cybermalveillance.gouv.fr propose des fiches et un service d’assistance aux victimes.

Un bon prestataire documente ce qu’il met en place et vous remet les accès au dépôt, aux outils de contrôle et aux rapports. Un contrôle caché dans un compte personnel disparaît avec la personne qui le gère. Pour lier ces contrôles à la mise en production, relisez notre guide sur le DevOps pour une PME et notre checklist de maintenance.

Exemple fictif : un petit site avec espace client

Cet exemple est fictif et ne décrit ni un client ni un résultat mesuré.

Un cabinet de services dispose d’un espace client développé avec plusieurs bibliothèques. Il met en place trois changements : les clés de messagerie et de base de données passent dans le gestionnaire de secrets de l’hébergeur, chaque modification est relue par une deuxième personne, et un contrôle automatique signale les dépendances avec avis de sécurité à chaque changement. Une fois par mois, le responsable trie les alertes, applique les mises à jour sur la recette, puis en production après validation. Dans cet exemple, aucune protection absolue n’est obtenue ; le cabinet réduit surtout les oublis et laisse une trace des décisions.

FAQ

Le DevSecOps remplace-t-il un audit de sécurité ?

Non. Il intègre des contrôles réguliers et automatisés, alors qu’un audit ou un test d’intrusion examine un périmètre précis à un moment donné, avec une méthode et une autorisation.

Faut-il tout mettre à jour dès qu’une alerte apparaît ?

Pas sans réflexion. Évaluez l’exposition, testez sur la recette, puis publiez. Une mise à jour urgente peut justifier une procédure accélérée, mais jamais l’absence de test.

Mon site WordPress est-il concerné ?

Oui : extensions, thèmes et noyau sont des dépendances. Les principes restent les mêmes, avec des outils adaptés à l’écosystème.

Conclusion

Intégrer la sécurité dans la mise en ligne revient à rendre les bons gestes automatiques : surveiller les composants, protéger les secrets, relire les changements et tester avant de publier. Commencez par les deux ou trois contrôles qui correspondent à vos risques réels. Pour définir un périmètre adapté, consultez nos pages cybersécurité et DevOps et hébergement, ou contactez-nous.