🌐 Site du projet & documentation →

Fonctionnalités

• 10 écosystèmes en une seule passe ; Maven, Gradle, npm/Yarn/pnpm, Composer, PyPI, NuGet, Go, Ruby — plus le JS vendu, les binaires natifs commités (identifiés par checksum) et les JARs embarqués (fat-jars/war/ear, ouverts en mémoire).
• Aucun outil de build ; les manifestes et lockfiles sont lus sur le disque. Pas de mvn/gradle/npm install/pip/dotnet restore/go build, pas de node_modules/. Le graphe Maven est résolu de la manière dont Maven le résout. → comment
• CVE, fusionnées & priorisées ; CVEProject + OSV.dev + NVD, CPE/version recoupés pour réduire les faux positifs, classées CISA KEV → EPSS → CVSS.
• Au-delà des CVE ; frameworks en fin de vie (EOL) et hors support actif, dépréciés/abandonnés/retirés (yanked), périmés avec dates de publication, licences SPDX, et paquets privés/internes — chaque coordonnée qu'aucun registre configuré ne connaît, dans n'importe quel écosystème.
• Matériel cryptographique ; certificats commités (expiration, clé faible, signature faible, auto-signé), clés privées vs publiques à travers PEM/OpenSSH/PuTTY/PGP et keystores JKS/PKCS#12. Analysés hors ligne, sans réseau.
• Air-gapped ; zéro réseau sous --offline, testé en régression et reproductible sous unshare -rn. Sur Maven, il récupère 657/657 du résultat en ligne d'OSV-Scanner sans aucune interface réseau, contre 45 / 40 / 37 pour les autres. → Benchmark · Air-gapped
• Risque de chaîne d'approvisionnement ; avis malveillants connus (bloquent toujours le gate CI) et typosquats suspectés (--typosquat).
• Niveau audit ; chaque rapport porte un manifeste de provenance et un chapitre Méthodologie & limites ; les artefacts livrent SHA256SUMS ; les audits différentiels comparent à une exécution antérieure (--baseline) et la CI peut ne bloquer que sur les nouveaux constats.
• Un --help qui tient sur un écran ; la longue traîne de commutateurs se replie en quatre flags — -d eol,nvd désactive des choses, -a licenses,snyk active ce qui est désactivé par défaut, -r html,json choisit les sorties, -o dit où. Les flags individuels fonctionnent toujours et --help-all les liste.
• Rapports en anglais ou en français (--lang fr)
• Sorties & CI ; HTML + JSON des constats par défaut (Word .doc avec --report-doc), CycloneDX 1.6 SBOM, CSAF 2.0 VEX, SARIF 2.1.0, JSON ; gate avec --fail-on, triage avec --ignore/--vex. Registres privés pour chaque écosystème.

📖 Utilisation & tous les flags · Architecture · Comparaison vs autres outils · Sources de données

Pourquoi utiliser fad-checker pour les audits de code ?

Ce qu'il apporte à un audit que les autres n'apportent pas. Même jeu de colonnes et même discipline de sourçage que docs/COMPARISON.md — ⚠️ signifie partiel et précise comment, les cellules sont censées être vérifiables.

¹ Pas de mvn/go/npm/pip/dotnet — manifestes analysés sur le disque, rien d'installé ni d'exécuté. 105 × pom.xml en une passe : 790 paires contre 657 pour OSV-Scanner, 133 propres à fad, versions médiées par module et non aplaties.

² 657 sur 657 du résultat Maven en ligne d'OSV-Scanner, sous unshare -rn — aucune interface réseau. Testé par tripwire ; seules des coordonnées publiques quittent jamais l'enceinte.

³ Le chapitre 0 nomme chaque coordonnée pour laquelle chaque registre configuré a répondu 404 — Maven, npm, PyPI, NuGet, Composer, Go et RubyGems — avec le(s) manifeste(s) qui la déclarent. Un registre qui a expiré ou renvoyé une erreur n'est jamais compté : une réponse non concluante accuserait sinon un client de livrer des paquets internes parce que son proxy était instable. -e <regex> les exclut ensuite.

⁴ -t <dir> : POMs normalisés plus chaque lockfile non-Maven mis en miroir, coordonnées privées retirées. Archivable, et scannable par n'importe quoi — --snyk inclus.

⁵ endoflife.date, séparé direct vs transitif pour savoir quelle dépendance mettre à jour, plus déprécié / abandonné / retiré et périmé. Trivy ne couvre que les distros OS ; la santé des paquets de Snyk est web uniquement.

⁶ Inventaire et verdicts : expiration, RSA<2048, MD5/SHA1, auto-signé ; clés privées vs publiques ; JKS/PKCS#12. Parseur hors ligne. La règle de secrets de Trivy trouve le fichier, pas la faille.

⁷ Identifiés par hash via deps.dev + CIRCL → devrait-être-déclaré / nom≠checksum / inconnu / malveillant. Les motifs de Syft nomment une version, pas une identité.

⁸ Le chapitre 0 signale ce que ce scan n'a pas pu atteindre (lockfiles manquants, versions BOM-only, Yarn Berry, runtime PHP indéterminable) ; le chapitre 6.3 énonce ce que l'outil n'évalue jamais. Ailleurs, le premier est une ligne de log que l'audit ne voit jamais, le second n'est pas écrit.

⁹ Manifeste de provenance : outil, runtime, mode, configuration d'exécution et fraîcheur du cache pour les 13 sources. Grype et Dependency-Check portent la date d'une source, pas celle de l'exécution.

¹⁰ Chapitres 0→6 avec un résumé exécutif et des recettes de correction, HTML autonome plus un jumeau Word .doc. Aucun des autres n'émet du Word.

¹¹ Quatre graphiques SVG en ligne — CWE par pire sévérité, transitives vulnérables par dépendance racine, vos modules les plus vulnérables (direct vs transitif sur un projet mono-module), bandes de priorité de correction — rendus aussi dans le .doc, avec copie en un clic en PNG (ou un tableau en HTML riche) qui se colle dans Word formaté. Chaque CVE conserve son vecteur CVSS, CWE, références, configuration CPE et via-path derrière une exploration, sans aucune ressource externe.

¹² --baseline ajoute un chapitre Δ (nouveau / corrigé / inchangé) ; --fail-on-new ne bloque que sur les nouveaux constats. Snyk suit cela sur sa plateforme, pas comme un diff local.

Où il perd — conteneurs/paquets OS, PR de correction automatique, et couverture CVE face au flux curé de Snyk → docs/COMPARISON.md · l'écart, mesuré.

Délibérément pas un objectif : l'atteignabilité. Un constat est une version vulnérable sur le graphe de dépendances, et le rapport dit exactement cela (ch. 6.3) au lieu de deviner les chemins d'appel. Décider si le code vulnérable est atteignable dans cette application relève de l'auditeur, avec un contexte applicatif qu'aucun scanner ne possède.

[!WARNING] fad-checker est nouveau et peut encore contenir (de rares) bugs. Traitez sa sortie comme une première passe solide, vérifiez deux fois tout ce qui est critique, et veuillez signaler les problèmes ; ils sont corrigés rapidement.

Démarrage rapide```bash

npm install -g fad-checker fad-checker -s ./my-project # → ./fad-checker-report/cve-report.html

Ce que fait réellement -t <dir>. Il s'agit d'une étape d'extraction, pas d'un adaptateur Snyk. Elle écrit une arborescence parallèle de descripteurs de dépendances normalisés : chaque pom.xml réduit aux nœuds pertinents pour les dépendances (coordonnées, properties, dependencyManagement, dependencies, modules), les parents de réacteur recâblés vers leur véritable relativePath dans l'arborescence, les ${…} résolus dans les coordonnées — plus chaque lockfile/manifeste non-Maven dupliqué au même chemin relatif (package-lock/yarn.lock/pnpm-lock, composer.lock, poetry/Pipfile/uv/pdm, *.csproj/packages.lock.json, go.mod/go.sum, Gemfile.lock, et les compagnons comme Directory.Packages.props ou nuget.config). En ligne, elle sonde également chaque coordonnée contre les dépôts Maven configurés et signale celles qui n'y existent pas — vos modules privés/internes — que -e <regex> retire ensuite des POM réécrits. Puis elle s'arrête : pas de passe CVE/EOL et pas de rapport sauf si vous passez aussi --snyk, un --report-<type>, --fail-on* ou --baseline. Ce que vous obtenez est un inventaire de dépendances assaini et sans build que vous pouvez archiver comme preuve d'audit, remettre à un client ou à une revue juridique, ou pointer vers n'importe quel scanner — Snyk via --snyk étant l'un d'eux.

[!IMPORTANT] --offline lit le cache, il ne le remplace pas. Sur un cache froid, il n'y a rien à comparer, donc une première exécution hors ligne rapporte légitimement 0 CVE / 0 EOL / 0 obsolète ; c'est un cache vide, pas un projet propre. Réchauffez-le une fois (une exécution en ligne normale sur n'importe quel projet, ou --import-cache), puis --offline renvoie l'ensemble complet des résultats sans aucun appel réseau. Les machines isolées obtiennent leur cache via --export-cache / --import-cache.

Un binaire unique autonome (sans Node), l'installation depuis les sources et la complétion shell sont dans → docs/USAGE.md.

Ce qu'il détecte

Le rapport est organisé en chapitres racines (chacun regroupant des sous-chapitres liés) :

Le rapport HTML s'ouvre dans n'importe quel navigateur, contient chaque détail (vecteurs CVSS, références, descriptions complètes, configurations CPE, via-paths pour les transitives) et est livré avec un jumeau .doc compatible Word. Chaque correspondance porte une priorité composite (exploité par KEV > probabilité EPSS > sévérité CVSS), et l'exécution peut en outre émettre un SBOM CycloneDX 1.6 (--report-sbom, vulnérabilités en ligne) et un CSAF 2.0 VEX (--report-csaf) pour l'outillage en aval.

Couverture, honnêtement : les paires que Snyk rapporte et que fad-checker ne rapporte pas

Aucun outil ne trouve tout. fad-checker mène à 87 % d'une union de 908 paires, et 131 paires sont revenues de Snyk et non de lui. Arbitrées une par une contre OSV, aucune n'est un bug de rappel :

Deux tiers contredisent l'enregistrement public, donc les rapporter signifierait livrer des faux positifs. CVE-2023-6481 est l'exemple limpide : revendiquée sur [email protected], elle lie logback-core à [1.2.12, 1.2.13) — mauvais artefact, et une version publiée avant que la faille n'existe.

Périmètre. Les 131 sont toutes de Snyk : OSV-Scanner, Trivy et Grype+Syft ont chacun contribué 0 constat que personne d'autre n'avait. Et toutes concernent la cible Maven — hors Maven, le graphe est dans le lockfile, chaque scanner lit la même entrée, et le benchmark mesure des ensembles de constats identiques sur npm, RubyGems et Composer.

C'est pourquoi --snyk existe. fad-checker prend la sortie de snyk test comme entrée et la fusionne, de sorte que vous obtenez l'union plutôt que de choisir un camp. Un choix de couverture, pas une correction.

Méthode, mises en garde et verdicts par paire → docs/BENCHMARK.md ; à reproduire avec scripts/adjudicate-gap.js.

Audits en environnement isolé

Garantie zéro donnée envoyée. Sous --offline, fad-checker n'effectue aucun appel réseau quel qu'il soit ; il lit uniquement les caches ~/.fad-checker/ réchauffés et ne transmet jamais une dépendance, un chemin ou un constat hors de la machine. C'est testé en régression (test/offline-guarantee.test.js, un fetcher-piège qui lève une exception s'il est touché) et reproductible par l'auditeur : unshare -rn node fad-checker.js -s ./proj --offline … l'exécute dans un namespace sans interface réseau et produit des constats identiques au byte près. Contrairement aux scanners OSS grand public, fad résout aussi le graphe transitif Maven hors ligne ; ainsi, sur un projet multi-modules isolé, il trouve les CVE transitives qu'ils ne peuvent pas trouver.

Lorsque le système audité est hors ligne / confidentiel (typique d'un audit réglementé ou isolé), il ne peut pas atteindre OSV / NVD / Maven Central / npm. Répartissez le travail entre machines tout en gardant zéro information d'environnement hors de l'enceinte sécurisée : un descripteur anonymisé ne porte que des coordonnées de paquets publics ; aucun chemin de système de fichiers, aucune URL de registre, aucun nom d'hôte/nom d'utilisateur ; et le rapport détaillé est produit de retour sur la machine hors ligne.

Le transfert repose sur une propriété des caches de fad-checker : ils sont indexés par coordonnée ou id de vulnérabilité, jamais par chemin, donc ils sont indépendants de la machine. L'étape en ligne ne fait que réchauffer les caches ; l'étape hors ligne rejoue le scan et obtient des hits de cache.```bash

── Phase 1; OFFLINE (audited machine): export the anonymized descriptor ──

Exclude private/internal packages with -e (offline we can't tell private from public).

fad-checker -s ./proj -e "^(client|internal)." --export-anonymized deps.json

→ deps.json: public coordinates only. Review it before it leaves the enclave.

── Phase 2; ONLINE (any machine, no source needed): warm the caches ──

fad-checker --import-anonymized deps.json # scans coordinates → OSV/NVD/CVE/registry/EOL + retire signatures fad-checker --export-cache fad-cache.tar.gz # bundle the warmed ~/.fad-checker/

── Phase 3; OFFLINE (audited machine): full report, all local context ──

fad-checker --import-cache fad-cache.tar.gz # merged into the enclave's own cache fad-checker -s ./proj --offline # re-collect locally (real paths) + cache hits

→ full HTML/.doc report with manifests & structure, generated inside the enclave.