Ces derniers temps, tu as vu passer combien de failles de sécurité dans ton fil ? Une par semaine ? Une par jour ? Entre les paquets npm compromis, les CVE critiques et les fuites de secrets, rester à jour est devenu un boulot à temps plein. C'est de là qu'est né Nodock : un outil qui garde un œil sur tout ça pour moi, directement dans mon éditeur.
Je vais être honnête avec toi dès le début : je ne cherchais pas à réinventer la sécurité. Je suis dev, j'ai un boulot, une asso, et accessoirement une vie. Je n'avais pas le temps de surveiller manuellement chaque dépendance de chaque projet. Mais laisser traîner une faille connue pendant des semaines parce que je ne l'avais pas vue passer ? Ça, ça me mettait mal à l'aise.
Le déclic : la sécurité qui ne dort jamais
Franchement, le rythme des failles ces dernières années est devenu dingue. Un paquet npm ultra-populaire qui se fait compromettre, une CVE critique dans une librairie que la moitié de la planète utilise, un token qui traîne dans un commit public… Ça n'arrête pas. Et le pire, c'est que le temps entre la publication d'une faille et son exploitation se réduit à vue d'œil.
Le souci, quand tu jongles avec plusieurs projets, c'est que tu ne peux pas tout suivre. Tu ne vas pas checker manuellement chaque dépendance, chaque avis de sécurité, chaque nouveau CVE tous les matins. Alors dans les faits, tu ne le fais pas, et une faille peut rester tranquillement dans ton projet pendant des semaines.
Je voulais donc un outil qui bosse à ma place : qui surveille en continu, qui me prévient des nouveautés, et qui vérifie mes dépendances sans que j'aie à y penser. Directement dans mon éditeur, là où je passe mes journées, pour ne pas avoir à ouvrir un dashboard de plus.
Mais très vite, un deuxième problème est apparu. Les scanners classiques comparent bêtement les numéros de version, et te balancent une liste rouge longue comme le bras. Or une faille dans un paquet ne veut pas dire que ton code est vulnérable : peut-être que la fonction concernée, tu ne l'appelles jamais. Résultat, au bout de la troisième alerte injustifiée, tu arrêtes de lire, et le jour où une vraie faille arrive, elle se noie dans le tas. C'est la fatigue d'alerte, et c'est un des trucs les plus vicieux en sécurité : trop d'infos tue l'info.
Du coup, l'objectif s'est précisé : un outil qui reste au courant à ma place, et qui ne me noie pas sous le bruit. Spoiler : c'est beaucoup plus dur que ça en a l'air.
L'idée centrale : le triage (ou "est-ce que ça me concerne, en vrai ?")
Le cœur de Nodock, c'est ça. Le triage.
Quand un avis de sécurité décrit une faille, il nomme souvent l'API responsable, genre oidcProvider() ou tel module précis, écrit entre backticks dans la description. Nodock lit ces noms, puis va fouiller ton code pour voir si tu les utilises réellement. Et il te sort un verdict en trois niveaux :
- Exploitable : le paquet est importé et l'API vulnérable apparaît dans ton code. Là, tu bouges.
- À vérifier : c'est importé, mais l'avis ne nomme aucune API précise. Zone grise, à toi de juger.
- Aucun chemin détecté : le paquet n'est jamais importé, ou pas de trace de la fonction vulnérable. Tu respires.
Petit garde-fou honnête, parce que je refuse de te vendre du rêve : "aucun chemin détecté" ne veut pas dire "invulnérable". Si tu utilises le paquet dans ton build ou en CLI, ça passe sous le radar. Et un futur import réintroduit le risque. Du coup, Nodock ne masque jamais ces findings, il les rétrograde juste d'un cran et les colle en fin de liste. La nuance plutôt que le mensonge par omission.
Ce triage, je l'ai étendu à JS/TS, Python, Go, Rust, Java/Kotlin, PHP, Ruby et C#. Autant te dire que les soirées ont été longues.
Ce que ça scanne (le tour du propriétaire)
Une fois le triage posé, l'appétit vient en codant. Nodock ne fait pas que traquer les dépendances vulnérables. Petit inventaire de ce qu'il regarde :
- Les dépendances (SCA) : npm, PyPI, Cargo, Go, Maven, RubyGems, Packagist, NuGet, le tout comparé à la base OSV.dev, gratuite et sans clé API. Et surtout, il lit tes lockfiles pour tester les versions réellement installées, pas juste ce que tu déclares. Nuance capitale.
- Les secrets : 15 patterns pour repérer les clés AWS, GitHub, OpenAI, Stripe, les JWT, les clés privées oubliées dans un coin… (on est tous passés par là, avoue).
- Le code (SAST) : les classiques qui font mal -
eval, injections SQL, XSS, TLS désactivé, crypto faible. - Le web (Websec) : SSRF, open redirect, CORS reflété, JWT
none, mass assignment… la panoplie du chemin d'attaque. - L'infra / CI : Dockerfiles qui tournent en root, images non épinglées, secrets en variable d'environnement, permissions GitHub Actions trop larges.
- L'audit de posture : et ça, c'est ma partie préférée. Au lieu de chercher ce qui est présent et dangereux, il cherche ce qui manque : une route qui touche à la base sans vérifier l'identité, une entrée non validée, un endpoint d'auth sans rate-limit. La sécurité, c'est aussi les trous dans la raquette.
Et pour la touche qui manque à beaucoup d'outils : la conformité. Nodock repère les trackers, cookies et collectes de données perso dans ton code, puis te dit quoi déclarer selon la juridiction, RGPD, CCPA, LGPD, et une dizaine d'autres. Il peut même générer un fichier mentions-legales.md pré-rempli. (À titre indicatif, hein — je suis dev, pas avocat. Je tiens à le préciser avant qu'un juriste me tombe dessus.)
Le truc dont je suis le plus fier : les templates YAML
Si je devais garder une seule feature, ce serait celle-là.
Le souci avec un scanner, c'est qu'il connaît ce qu'on a codé dedans, et rien d'autre. Si demain une nouvelle mauvaise pratique émerge dans ton langage préféré, tu attends une mise à jour. Frustrant.
Du coup j'ai fait un système de templates YAML : tu décris ta propre règle de vulnérabilité dans un petit fichier, tu le déposes dans .nodock/templates/, et Nodock la charge au scan. Un fichier ressemble à ça :
id: NDK-GO-001
info:
name: exec.Command avec chaîne
severity: high
matchers:
- type: regex
pattern: '\bexec\.Command\s*\('
condition: or
Simple, lisible, et ça hérite de tous les garde-fous du moteur (les commentaires sont ignorés, les fixtures de test rétrogradées, la baseline respectée). J'ai livré une vingtaine de templates embarqués pour couvrir Go, Rust, Java, PHP, Ruby et C#, mais l'idée c'est que tu écrives les tiens. Le scanner devient le tien.
Les galères (parce qu'il y en a eu)
Je serais malhonnête de te peindre un long fleuve tranquille.
Galère n°1 : le bruit. Ironique, non ? Je voulais réduire le bruit des autres scanners, et mes premières versions crachaient un mur de faux positifs. Chaque règle a fallu la border avec des plafonds anti-bruit, des exemptions, un triage par emplacement. Un secret dans .env.example, c'est pas un secret dans la prod, mais encore fallait-il l'apprendre à la machine.
Galère n°2 : ne jamais envoyer ton code ailleurs. Question de principe : Nodock n'envoie que les noms et versions de paquets à OSV.dev. Ton code ne quitte jamais ta machine. Pas de compte, pas de clé API, pas de serveur tiers qui aspire ton repo. Ça a contraint pas mal de choix techniques, mais c'était non négociable.
Et maintenant ?
Nodock est publié sur le Marketplace VS Code et sur Open VSX (donc dispo aussi sur Cursor, Windsurf, VSCodium…). C'est gratuit, open source sous licence MIT, et le code est là : github.com/nadsous/nodock.
Sur la roadmap, il me reste de quoi m'occuper : une version CLI pour la CI, un cache incrémental pour ne re-scanner que les fichiers modifiés, des hooks pre-commit, et même une app desktop en Tauri si le courage est au rendez-vous.