Shift-left et OWASP Top 10 : la sécurité commence dans l'éditeur

Objectif

Comprendre pourquoi la sécurité doit entrer dans le travail des développeurs dès la première ligne de code (le « shift-left »), et savoir reconnaître, dans un vrai fichier source, les grandes familles de risques décrites par l'OWASP Top 10:2025.

L'essentiel

• Plus une faille est trouvée tard, plus elle coûte cher : une ligne corrigée dans l'éditeur coûte quelques minutes ; la même faille exploitée en production coûte une fuite de données, une déclaration à la CNDP et la confiance des clients.
• Le DevSecOps ajoute la sécurité à chaque étape du cycle DevOps (planifier, coder, construire, tester, livrer, exploiter), automatisée autant que possible et partagée par toute l'équipe.
• Shift-left = déplacer les contrôles vers la gauche du cycle : modélisation des menaces, analyse du code, des dépendances et des secrets avant la fusion, pas après la mise en ligne.
• L'OWASP Top 10 est la liste de référence des dix risques les plus graves des applications web. La version 2025 commence par le contrôle d'accès défaillant (A01) et fait entrer la chaîne d'approvisionnement logicielle (A03).
• Un outil ne remplace pas le raisonnement : il faut savoir lire un défaut, le classer et le corriger à la racine.

1. Pourquoi « shift-left » ?

Imaginez le cycle de vie d'une application dessiné de gauche à droite : on conçoit, on code, on construit, on teste, on déploie, on exploite. Pendant longtemps, la sécurité vivait tout à droite : une fois l'application terminée, un auditeur lançait un test d'intrusion quelques jours avant la mise en ligne, rendait un rapport de 60 pages… et l'équipe découvrait qu'il fallait revoir l'authentification entière.

Prenons une fintech de Casablanca qui développe un portefeuille mobile. Voici le même défaut — un mot de passe stocké en MD5 — découvert à quatre moments différents :

Le shift-left consiste à pousser les contrôles vers la gauche : on ne supprime pas l'audit final, mais on fait en sorte qu'il ne trouve presque plus rien.

Ce que cela change concrètement

# Avant : la sécurité arrive à la fin, une fois par an
#   code → build → déploiement → (6 mois plus tard) audit → panique

# Après : chaque étape porte son petit contrôle automatique
#   éditeur      : extension Semgrep, alerte sur un secret collé dans le code
#   pre-commit   : gitleaks refuse un commit contenant une clé
#   pull request : SAST (Semgrep), audit des dépendances (npm audit, pip-audit)
#   build        : scan de l'image (Trivy), SBOM (Syft), signature (cosign)
#   déploiement  : refus d'une image non signée ou porteuse d'une faille critique
#   production   : journaux, alertes, correctifs rapides

Vous verrez chacun de ces outils dans la suite de la formation.

2. DevSecOps : une culture avant d'être des outils

« DevSecOps » n'est pas un poste ni un logiciel que l'on achète. C'est une manière de travailler qui repose sur trois idées.

1. La sécurité est l'affaire de tous. Le développeur qui écrit la requête SQL est le mieux placé pour la protéger. L'équipe sécurité (quand elle existe) devient un soutien : elle fournit des règles, des modèles et des formations, au lieu de jouer le gendarme en fin de projet.
2. Automatiser ce qui peut l'être. Un humain oublie ; un pipeline, non. Tout contrôle répétitif (secrets, dépendances, image Docker) doit tourner seul à chaque modification.
3. Des retours rapides et utiles. Une alerte doit arriver pendant que le développeur a encore le code en tête, avec une explication et une piste de correction. Mille alertes non triées, en revanche, sont ignorées : mieux vaut peu de règles fiables que beaucoup de bruit.

Le cadre légal marocain

Au Maroc, la loi 09-08 protège les données à caractère personnel. Le responsable d'un traitement (une banque, une boutique en ligne, une administration qui propose un téléservice) doit prendre des mesures techniques et organisationnelles appropriées pour protéger ces données contre la destruction, la perte, l'altération ou l'accès non autorisé. La CNDP (Commission nationale de contrôle de la protection des données à caractère personnel) contrôle ces obligations.

Autrement dit : une injection SQL qui expose les CIN et les numéros de téléphone de vos clients n'est pas seulement un « bug ». C'est un manquement à une obligation légale. Le DevSecOps vous donne des preuves concrètes que vous avez pris ces mesures : règles d'analyse, rapports de scan, historique des corrections.

3. L'OWASP et son Top 10

L'OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui publie gratuitement des guides, des outils et des standards de sécurité applicative. Son document le plus connu, le Top 10, classe les risques les plus graves observés dans les applications web, à partir de données réelles fournies par des entreprises et de l'avis de la communauté.

La version 2025 est la suivante :

Retenez les deux nouveautés de 2025 : la chaîne d'approvisionnement (A03) — tout ce que vous n'écrivez pas vous-même, mais que vous livrez quand même — et la gestion des situations exceptionnelles (A10). Ce sont précisément deux sujets que le DevSecOps traite avec des outils automatiques (audit des dépendances, SBOM, signatures, tests d'erreurs).

Le Top 10 est un outil de sensibilisation, pas une liste exhaustive. Pour vérifier une application point par point, l'OWASP propose un standard plus complet : l'ASVS (Application Security Verification Standard).

4. Lire du code avec les yeux d'un attaquant

Regardons un extrait typique, très proche de celui du lab. C'est l'API d'une fintech : un client connecté consulte une transaction.

async function voirTransaction(req, res, db) {
  const lignes = await db.query(`SELECT * FROM transactions WHERE id = ${req.params.id}`);
  res.json(lignes[0]);
}

Deux défauts se cachent dans ces trois lignes.

Défaut 1 — A05 Injection. La valeur req.params.id vient de l'URL, donc de l'attaquant. Elle est collée dans le texte SQL. Si l'on demande /transactions/0 OR 1=1, la requête devient ... WHERE id = 0 OR 1=1 et renvoie la première transaction de la base, quelle qu'elle soit. Avec un peu plus d'imagination (UNION SELECT ...), on lit d'autres tables.

La correction : une requête paramétrée. Le texte SQL contient des marques ? et les valeurs voyagent à part ; le pilote de base de données ne les interprète jamais comme du SQL.

const lignes = await db.query(
  "SELECT * FROM transactions WHERE id = ? AND client_id = ?",
  [req.params.id, req.user.id]          // valeurs envoyées séparément
);

Défaut 2 — A01 Contrôle d'accès défaillant. Même sans injection, la première version renvoie la transaction demandée sans vérifier qu'elle appartient au client connecté. C'est le défaut le plus fréquent du Top 10 (on l'appelle aussi IDOR, Insecure Direct Object Reference). La correction ci-dessus le traite aussi : la condition AND client_id = ? limite la recherche aux transactions de l'utilisateur authentifié.

Le stockage des mots de passe

function hacherMotDePasse(mdp) {
  return crypto.createHash("md5").update(mdp).digest("hex");
}

A04 Défaillances cryptographiques. MD5 est une fonction de hachage rapide et cassée. Rapide est ici un défaut : une carte graphique calcule des milliards d'empreintes MD5 par seconde, et sans sel, deux clients qui ont le même mot de passe (Casa2026!) ont la même empreinte, que l'on retrouve dans des tables précalculées.

Il faut une fonction lente et salée, conçue pour les mots de passe : scrypt, Argon2id ou bcrypt. Node.js fournit scrypt sans dépendance :

const crypto = require("node:crypto");

function hacherMotDePasse(mdp) {
  const sel = crypto.randomBytes(16);                     // sel aléatoire, unique par compte
  const empreinte = crypto.scryptSync(mdp, sel, 64);      // dérivation volontairement coûteuse
  return sel.toString("hex") + ":" + empreinte.toString("hex");   // on stocke les deux
}

Pour vérifier un mot de passe à la connexion, on relit le sel stocké, on recalcule l'empreinte et on compare avec crypto.timingSafeEqual (comparaison en temps constant).

Les erreurs qui bavardent

function gererErreur(err, req, res, next) {
  res.status(500).json({ erreur: err.message, pile: err.stack });
}

A10 Mauvaise gestion des conditions exceptionnelles (on le classait autrefois en mauvaise configuration, A02). La pile d'appels révèle les chemins des fichiers, les versions des bibliothèques, parfois une requête SQL complète : un cadeau pour l'attaquant. On journalise le détail côté serveur et on renvoie un message neutre :

function gererErreur(err, req, res, next) {
  console.error(err);                                     // le détail reste dans les journaux
  res.status(500).json({ erreur: "Erreur interne, réessayez plus tard" });
}

5. Quel outil pour quel risque ?

Aucun outil ne couvre tout le Top 10. Voici la carte de ce que vous allez apprendre et de ce que chaque outil attrape :

Ce que les outils trouvent mal : les défauts de logique métier (un remboursement que l'on peut demander deux fois, un contrôle d'accès « presque » correct). Pour ceux-là, il reste la modélisation des menaces, la revue de code et les tests.

6. Par où commencer dans une petite équipe ?

Une start-up de trois développeurs à Rabat n'a ni budget ni équipe sécurité. Un ordre réaliste :

# Semaine 1 : arrêter l'hémorragie
#   - gitleaks en pre-commit et en CI (les secrets fuient en premier)
#   - npm audit / pip-audit dans la CI, seuil « critical »
# Semaine 2 : le code
#   - Semgrep avec un jeu de règles standard, en mode « avertissement » d'abord
# Semaine 3 : les conteneurs
#   - Dockerfile non root, image de base précise, scan Trivy de l'image
# Ensuite : modélisation des menaces de chaque nouvelle fonctionnalité sensible,
#           SBOM et signature des livraisons, puis durcissement des seuils

L'important est de commencer petit et de ne jamais reculer : une fois qu'une porte bloque les failles critiques, on ne la retire plus.

Pièges fréquents

• Croire qu'un outil suffit. Un scanner vert ne prouve pas que l'application est sûre ; il prouve seulement qu'il n'a rien trouvé de ce qu'il sait chercher.
• Activer toutes les règles le premier jour. Des centaines d'alertes non triées découragent l'équipe, qui finit par désactiver l'outil. Commencez par les sévérités élevées.
• Corriger le symptôme, pas la cause. Filtrer le mot OR dans un champ ne corrige pas une injection ; seule la requête paramétrée le fait.
• Oublier le contrôle d'accès. Une requête paramétrée qui renvoie la transaction d'un autre client reste une faille (A01).

Lab

Vous faites ce lab sur votre propre machine virtuelle de travail : lancez sudo ml demarrer devsecops-1-1, faites les tâches dans votre terminal, puis vérifiez avec sudo ml verifier.

Vous êtes chargé de la revue de sécurité d'un extrait de l'API d'AtlasPay, une fintech casablancaise : /root/atlaspay/src/paiements.js. Quatre défauts y sont marqués [1] à [4].

1. Classez chaque défaut dans l'OWASP Top 10:2025 (fichier constats.txt).
2. Corrigez l'injection et le contrôle d'accès avec une requête paramétrée filtrée sur le client connecté.
3. Remplacez MD5 par scrypt avec un sel aléatoire.
4. Faites en sorte que les erreurs ne révèlent plus rien au client.

Après chaque modification, contrôlez la syntaxe avec node --check /root/atlaspay/src/paiements.js et relisez le fichier avec cat -n.

Quiz

1. Que signifie « shift-left » ?
2. Dans quelle catégorie de l'OWASP Top 10:2025 classez-vous une API qui renvoie la commande d'un autre client quand on change l'identifiant dans l'URL ?
3. Pourquoi une requête paramétrée protège-t-elle de l'injection SQL, alors que filtrer les apostrophes ne suffit pas ?
4. Pourquoi MD5 est-il un mauvais choix pour stocker des mots de passe, et que faut-il utiliser ?
5. Quelle catégorie est apparue dans le Top 10:2025 pour couvrir les bibliothèques, images et outils que l'on livre sans les avoir écrits ?

Sources de référence : OWASP (CC BY-SA 4.0), documentation Node.js, CNDP. Texte original MasterLinux.