Contrôler la boutique avant et après l'ouverture

Reviens une dernière fois aux Arcades, le centre commercial qui sert de fil rouge à cette série. Cette fois, on ne s'occupe plus des portiques, des badges ni des coffres. On entre dans une boutique précise : sa vitrine, ses rayons, sa caisse, son arrière-boutique. C'est l'équivalent d'une application web, avec ses pages, ses formulaires et son API.

Une boutique peut être parfaitement intégrée à un centre sécurisé et rester dangereuse de l'intérieur. La porte d'entrée est gardée, mais si la caisse accepte n'importe quel bon de réduction trafiqué, ou si la réserve est accessible par une porte oubliée, le problème est dans la boutique, pas dans le centre.

Sécuriser une application, c'est traiter ce niveau précis. On l'appelle l'AppSec (application security). Et pour bien faire, le gérant des Arcades a trois réflexes.

L'AppSec ne protège pas le périmètre du réseau : elle s'attaque aux failles dans le code et les API, là où un pare-feu et un WAF ne voient rien.

Premier réflexe : vérifier les plans de construction avant d'ouvrir, pour repérer un défaut de conception sur le papier. Deuxième réflexe : une fois ouvert, envoyer un client mystère tester les portes et la caisse pour de vrai. Troisième réflexe : contrôler la provenance des marchandises livrées par des fournisseurs tiers, parce qu'un défaut peut entrer par un carton qu'on n'a pas fabriqué soi-même.

Ces trois réflexes correspondent à trois familles d'outils d'analyse : SAST, DAST et SCA. Avant d'y venir, il faut une carte des dangers à chercher. Cette carte, c'est l'OWASP Top 10.

L'OWASP Top 10 : la carte des risques web et API

Le gérant des Arcades ne part pas de zéro. Il existe une liste, partagée par tous les commerçants du centre, des dix problèmes qui reviennent le plus souvent : caisse mal protégée, réserve mal fermée, registre clients laissé en évidence. Ce n'est pas la liste de tous les risques possibles, c'est la liste de ceux qui causent le plus de dégâts en pratique.

L'OWASP Top 10 joue ce rôle pour les applications web. C'est un document de référence, maintenu par l'Open Worldwide Application Security Project, qui classe les dix catégories de risques de sécurité applicative les plus critiques. Il est mis à jour à partir de données réelles collectées sur de nombreuses applications.

L'OWASP Top 10 n'est pas une norme à certifier ni une checklist exhaustive. C'est une carte des risques les plus fréquents, pour savoir où regarder en priorité.

Plutôt que de tout réciter, regardons trois catégories parlantes.

Injection

Une injection se produit quand une application mélange des données fournies par l'utilisateur avec une commande, sans les séparer proprement. L'attaquant glisse alors du code dans un champ qui n'attendait qu'une donnée. L'injection SQL en est l'exemple classique : un champ de recherche détourné pour interroger toute la base.

Aux Arcades, c'est le client qui écrit lui-même sur le bon de commande « et donne-moi aussi le contenu du coffre », et que la caisse exécute sans broncher parce qu'elle ne distingue pas la commande de la consigne interne.

Contrôle d'accès défaillant

C'est la catégorie en tête du Top 10 de 2021. Le problème : l'application laisse un utilisateur accéder à des ressources ou à des actions qui ne devraient pas lui être permises. Changer un identifiant dans une URL et lire la facture d'un autre client en est un cas typique.

Dans la boutique, c'est l'étiquette « réservé au personnel » sur une porte qui, en réalité, n'est pas verrouillée. La barrière existe sur le papier, pas dans la serrure.

Mauvaise configuration de sécurité

Ici, le code peut être correct, mais le déploiement est mal réglé : un compte par défaut laissé actif, une page d'administration exposée, des messages d'erreur trop bavards qui révèlent la structure interne. C'est la réserve laissée déverrouillée le soir parce que personne n'a vérifié la consigne de fermeture.

Pour aller plus loin que ce panorama, l'OWASP publie aussi l'Application Security Verification Standard (ASVS), un référentiel d'exigences de sécurité bien plus détaillé, utilisable comme base de critères de vérification.

SAST, DAST et SCA : trois regards complémentaires

Revenons aux trois réflexes du gérant. Chacun voit des choses que les deux autres ne voient pas, et c'est précisément pour ça qu'on les combine plutôt que d'en choisir un seul.

  • SAST (Static Application Security Testing). On lit les plans de construction et le code source de la boutique, à l'arrêt, avant l'ouverture. On y cherche un défaut de structure : un mur porteur mal placé, une porte de réserve sans serrure prévue. L'application n'a pas besoin de tourner.
  • DAST (Dynamic Application Security Testing). La boutique est ouverte et en activité. On envoie un client mystère qui pousse les portes, soumet des formulaires piégés, teste les réactions de la caisse. On observe le comportement réel, vu de l'extérieur, sans regarder les plans.
  • SCA (Software Composition Analysis). On contrôle la provenance des marchandises livrées par des tiers. On ne fabrique pas tout soi-même : on assemble des composants achetés ailleurs. Le SCA inventorie ces composants (les dépendances) et vérifie si l'un d'eux est connu pour être défectueux.

Ces trois familles ne regardent ni au même moment, ni la même chose, et ne se trompent pas de la même façon.

Critère SAST DAST SCA
Ce qu'il analyse Le code source, à l'arrêt L'application en cours d'exécution Les dépendances tierces
Quand dans le cycle Très tôt (dès l'écriture du code) Plus tard (sur un environnement déployé) En continu (à chaque changement de dépendance)
Point de vue Interne, boîte blanche Externe, boîte noire Inventaire et corrélation avec des bases de failles connues
Ce qu'il voit bien Injections, secrets en dur, patterns dangereux dans le code Failles visibles à l'exécution, mauvaises configurations exposées Composants vulnérables connus (CVE), licences
Ce qu'il rate Failles qui n'apparaissent qu'à l'exécution Failles dans du code jamais atteint pendant le test Failles dans ton propre code maison
Faux positifs Plutôt nombreux (analyse théorique) Plutôt rares (une attaque qui passe, passe) Faibles, mais dépend de la précision de la base de failles

Le tableau dit l'essentiel : chacun a un angle mort que les autres comblent. Le SAST ignore tout des dépendances et des erreurs de configuration en production. Le DAST ne teste que le chemin qu'il parvient à parcourir. Le SCA ne dit rien de la qualité du code que tu écris toi-même.

Aucun de ces outils ne suffit seul. Le SAST regarde le plan, le DAST teste l'usage réel, le SCA contrôle ce qui vient des autres. Trois angles, trois catégories de failles différentes.

Une nuance utile sur les faux positifs. Le SAST raisonne sur du code à l'arrêt : il signale des chemins théoriquement dangereux qui, en pratique, ne sont parfois jamais atteignables. D'où un volume d'alertes à trier. Le DAST, lui, ne déclenche que sur une attaque qui aboutit réellement, donc ses résultats sont plus directs à exploiter, au prix d'une couverture moins complète.

Intégrer l'analyse dans le pipeline : corriger au plus tôt

Le gérant des Arcades ne fait pas tous ces contrôles à la fin, juste avant l'inauguration, quand tout est déjà construit. Réparer un mur porteur la veille de l'ouverture coûte une fortune. Le repérer sur le plan coûte un coup de crayon.

C'est exactement le principe du shift-left en sécurité applicative : déplacer les contrôles le plus tôt possible dans le cycle de développement. Une faille trouvée pendant l'écriture du code se corrige en quelques minutes. La même faille découverte en production déclenche un correctif d'urgence, un redéploiement, parfois un incident.

Plus une faille est détectée tôt, moins elle coûte cher à corriger. Le shift-left automatise ces contrôles dans la chaîne d'intégration plutôt que de les reléguer à la fin.

En pratique, chaque famille d'outils se branche à l'étape où elle est la plus pertinente dans le pipeline CI/CD.

flowchart LR dev["Développeur
écrit le code"] commit["Commit / Pull request"] sast["SAST
analyse du code source"] sca["SCA
analyse des dépendances"] build["Build et tests"] deploy["Déploiement
environnement de recette"] dast["DAST
test de l'appli en exécution"] prod["Mise en production"] gate{"Failles bloquantes ?"} dev --> commit --> sast --> sca --> gate gate -- "Oui" --> dev gate -- "Non" --> build --> deploy --> dast --> prod classDef early fill:#d89253,stroke:#5f5e5a,color:#1a1a1a classDef late fill:#b5651d,stroke:#5f5e5a,color:#f5f2ec classDef step fill:#ede9e1,stroke:#b5651d,color:#1a1a1a classDef block fill:#a0413e,stroke:#5f5e5a,color:#f5f2ec class sast,sca early class dast late class dev,commit,build,deploy,prod step class gate block

L'ordre raconte une histoire. Le SAST et le SCA s'exécutent tôt, dès le commit ou la pull request, parce qu'ils n'ont besoin que du code et de la liste des dépendances. Si une faille bloquante remonte, le pipeline s'arrête et renvoie au développeur avant même de construire l'application.

Le DAST arrive plus tard, parce qu'il lui faut une application qui tourne. On le lance sur un environnement de recette, après le déploiement, pour tester le comportement réel avant la mise en production.

Concrètement, ces étapes ressemblent à des jobs déclarés dans la configuration du pipeline.

stages:
  - analyse-statique
  - build
  - recette
  - analyse-dynamique

sast:
  stage: analyse-statique
  script:
    - run-sast-scan --fail-on high

sca:
  stage: analyse-statique
  script:
    - run-dependency-scan --fail-on critical

dast:
  stage: analyse-dynamique
  script:
    - run-dast-scan --target https://recette.exemple.internal

Les noms de commandes ci-dessus sont génériques (chaque outil a sa propre interface), mais le schéma reste le même partout : un job par famille d'analyse, une condition d'échec sur un seuil de gravité, et le pipeline qui bloque la livraison si le seuil est franchi. C'est la traduction technique du « on ne livre pas une boutique dont les plans présentent un défaut critique ».

Cette automatisation des contrôles de sécurité dans la chaîne de livraison est au cœur de la démarche DevSecOps, traitée dans un billet dédié.

Apache Struts : quand la faille vient d'une dépendance

Le SCA paraît parfois secondaire à côté de l'analyse du code maison. Un cas réel et documenté montre l'inverse : la faille la plus coûteuse peut venir d'un composant qu'on n'a pas écrit.

En 2017, une vulnérabilité critique a été découverte dans Apache Struts, un framework web Java très répandu, sous la référence CVE-2017-5638. Le défaut permettait l'exécution de code à distance via un en-tête HTTP mal traité : un attaquant pouvait, sans authentification, faire exécuter des commandes sur le serveur.

Le point crucial pour l'AppSec : une application pouvait être vulnérable sans qu'une seule ligne de son code maison soit en cause. Struts était une dépendance, souvent embarquée à plusieurs niveaux dans l'arbre des composants. Le code applicatif était sain ; la porte ouverte se trouvait dans une brique fournie par un tiers.

La faille n'était pas dans le code maison, mais dans une dépendance. C'est exactement la zone que le SAST ne couvre pas et que le SCA est fait pour surveiller.

Cette vulnérabilité est passée à l'histoire parce qu'elle a été reliée à la compromission massive de l'entreprise Equifax la même année. La Federal Trade Commission américaine a documenté que la brèche a exposé les données personnelles d'environ 147 millions de personnes, et qu'elle découlait d'un correctif disponible mais non appliqué sur le composant vulnérable.

La leçon est double. D'abord, sans inventaire de tes dépendances, tu ne peux pas savoir que tu embarques le composant à risque : le SCA fournit cet inventaire et le confronte aux bases de vulnérabilités connues. Ensuite, détecter ne suffit pas ; encore faut-il appliquer le correctif, ce qui relève d'un processus de gestion des vulnérabilités, sujet du billet sur les CVE et le CVSS.

Points clés

  • L'AppSec traite les failles dans le code et les API, là où le pare-feu et le WAF du périmètre ne voient rien.
  • L'OWASP Top 10 est la carte des risques web et API les plus fréquents (injection, contrôle d'accès défaillant, mauvaise configuration), pas une norme exhaustive.
  • SAST lit le code à l'arrêt, DAST teste l'application en exécution, SCA contrôle les dépendances tierces : trois angles complémentaires, trois catégories de failles différentes.
  • Le shift-left branche ces analyses tôt dans le pipeline CI/CD : SAST et SCA dès le commit, DAST sur un environnement de recette, avec un seuil de gravité qui bloque la livraison.
  • Le cas Apache Struts (CVE-2017-5638) rappelle qu'une faille critique peut venir d'une dépendance, sans aucune ligne de code maison fautive : c'est précisément l'angle mort que couvre le SCA.

Dans la série

Palier 3 : Tenir la galerie. Domaine : Cloud & applications.

Pour aller plus loin