Chez une PME manufacturière, j’ai rencontré une équipe de trois développeurs qui bâtissait une application de gestion d’inventaire vraiment intéressante. Interface propre, logique bien réfléchie — bref, le client était vraiment satisfait de ses développeurs. Il me présentait cela tout heureux, jusqu’au moment où j’ai demandé comment le code était validé avant chaque mise en ligne.

Sa réponse : « On le relit. »

C’était tout.

Ils ne sont pas les seuls, puisque je croise des équipes de développement très compétentes, mais sans contrôle de sécurité automatisé sur leur code. Le produit est impressionnant. La validation, elle, n’existe pas.

Pourtant les outils pour combler ce trou existent et certains sont gratuits.

Voici les quelques pistes que je partage avec vous, par exemple si votre entreprise développe sur GitHub.

Pour rappel : c’est quoi GitHub Actions

GitHub héberge le code de la majorité des PME québécoises qui développent des logiciels. GitHub Actions est le mécanisme d’automatisation intégré à la plateforme : chaque fois qu’un développeur pousse du code, GitHub peut déclencher une série de vérifications avant que ce code se retrouve en production.

Le mécanisme d’envoyer le code existe déjà dans votre environnement. La question, c’est de savoir si on lui donne du travail à faire.

L’hésitation que je vois

Chaque vérification ajoutée au pipeline ralentit la livraison. Un développeur qui doit livrer une fonctionnalité pour vendredi ne voit pas toujours l’intérêt d’attendre dix minutes de plus pour un balayage de sécurité. Et personne, dans l’équipe, n’a le mandat explicite de refuser une mise en ligne pour une raison de sécurité.

Je comprends l’hésitation, puisqu’une fois l’outil en place, il fonctionne sans effort pour l’équipe. Mais qui a la responsabilité de ralentir, de vérifier et de prendre une décision ?

Les 4 outils open source à connaître

Voici quatre outils que j’ai vus sur le terrain, chacun avec un rôle précis — dans l’ordre où je recommande de les déployer.

Outil 1 — Gitleaks : les secrets oubliés dans le code

Gitleaks scanne l’historique complet d’un dépôt Git pour repérer les secrets poussés par erreur, comme :

  • une clé API codée en dur dans un fichier
  • un mot de passe oublié dans un fichier de configuration
  • un jeton d’accès (token) laissé dans un ancien commit

J’ai déjà vu une clé d’accès infonuagique se retrouver dans un dépôt GitHub public par erreur humaine banale. Une fois poussé, un secret reste dans l’historique du dépôt même si on le supprime du fichier après coup. Gitleaks l’aurait attrapé avant que le push se fasse.

Outil 2 — Trivy : les failles dans vos dépendances et vos conteneurs

Trivy vérifie si les composants que votre équipe utilise contiennent des vulnérabilités déjà connues et documentées publiquement, dans :

  • les librairies et dépendances du projet
  • les images de conteneurs (Docker)
  • l’infrastructure en tant que code (IaC)
  • les environnements Kubernetes

Outil 3 — Semgrep : les erreurs de code qui ouvrent des failles

Semgrep fait de l’analyse statique du code, dans plusieurs langages, basée sur des règles. Il trouve par exemple :

  • une requête mal construite vers une base de données, ce qu’on appelle une injection SQL
  • un mot de passe ou une clé écrits directement en clair dans le code

Outil 4 — Bandit : la même logique, propre à Python

Bandit applique la même approche que Semgrep, mais bâtie spécifiquement pour le langage Python. Pertinent si votre équipe développe dans ce langage.

Le lien avec ISO 27001

Ces outils ne sont pas seulement une bonne pratique technique. Ils répondent directement à des contrôles précis de la norme.

L’Annexe A d’ISO 27001:2022 contient le contrôle 8.28 (codage sécurisé), qui exige que l’organisation ait des règles pour écrire du code qui n’introduit pas de vulnérabilités évitables. Un scanner comme Semgrep ou Bandit intégré au pipeline, ce n’est pas un luxe : c’est une preuve concrète que ce contrôle existe et fonctionne, pas juste sur papier.

Il y a aussi le contrôle 8.29 (tests de sécurité en développement et en acceptation), qui exige que la sécurité soit vérifiée avant la mise en production, pas découverte après coup par un client ou un attaquant. Et le contrôle 8.8 (gestion des vulnérabilités techniques), qui couvre exactement ce que Trivy fait avec vos dépendances et vos conteneurs.

Minimalement, un auditeur va vous poser une question simple : montrez-moi comment vous savez que votre code ne contient pas de vulnérabilité connue avant qu’il parte en production. Sans un de ces outils intégré au pipeline, la réponse honnête est souvent : on ne le sait pas.

Guide de mise en œuvre simple

Vous n’avez pas besoin de tout implémenter en même temps. Le plus simple pour commencer, c’est Gitleaks. Voici comment votre équipe l’active, concrètement :

  1. Dans le dépôt GitHub, ouvrir l’onglet Actions.
  2. Cliquer sur New workflow et chercher « Gitleaks » dans le GitHub Marketplace.
  3. Sélectionner l’action proposée par Gitleaks et laisser GitHub créer le fichier de configuration par défaut, dans le dossier .github/workflows.
  4. Valider (committer) ce fichier directement dans le dépôt.
  5. Au prochain envoi de code, le scan se lance automatiquement. Le résultat apparaît dans l’onglet Actions, avec un crochet vert ou une alerte si un secret est détecté.

Cinq étapes, aucun serveur à installer, aucun coût. Une fois ce premier scan fonctionnel, la même logique s’applique aux autres outils : chacun a sa propre action prête à l’emploi sur le Marketplace, et l’ajout se fait de la même façon.

Ajoutez ensuite un scanner de dépendances comme Trivy sur votre pipeline. La majorité des vulnérabilités qui touchent une application ne viennent pas du code écrit par votre équipe, mais des librairies qu’elle a importées.

Le scanner de code statique, Semgrep ou Bandit selon le langage, vient en troisième, une fois que les deux premiers tournent sans trop de faux positifs.

Ce n’est pas la responsabilité de votre fournisseur ni d’un consultant externe de mettre ça en place à votre place. C’est votre équipe qui écrit le code, c’est elle qui doit posséder ces contrôles. Mon rôle, c’est de vous aider à savoir quoi exiger et à documenter que ça fonctionne, le jour où un auditeur ou un client vous pose la question.

Bref, la compétence technique de votre équipe de développement n’a jamais été le problème que je rencontre. C’est le contrôle qui manque entre leur code et la production. Ces quatre outils sont gratuits, implantables en une journée et vous donnent une réponse claire la prochaine fois qu’on vous pose la question.

Je ne sais pas si votre équipe a déjà ce genre de validation en place. Si ce n’est pas le cas, c’est probablement la chose la plus simple à combler cette semaine.

Quelle méthode utilisez-vous pour détecter les failles dans votre code ?