🌐 Sito del progetto e documentazione →

Funzionalità

• 10 ecosistemi in un solo passaggio; Maven, Gradle, npm/Yarn/pnpm, Composer, PyPI, NuGet, Go, Ruby — più JS vendorizzato, binari nativi committati (identificati tramite checksum) e JAR incorporati (fat-jar/war/ear, aperti in memoria).
• Nessun build tool; manifest e lockfile vengono letti dal disco. Niente mvn/gradle/npm install/pip/dotnet restore/go build, niente node_modules/. Il grafo Maven viene risolto come lo risolve Maven. → come
• CVE, unite e prioritizzate; CVEProject + OSV.dev + NVD, CPE/versione incrociati per ridurre i falsi positivi, classificate CISA KEV → EPSS → CVSS.
• Oltre le CVE; framework EOL e fuori supporto attivo, deprecati/abbandonati/yanked, non aggiornati con date di rilascio, licenze SPDX e pacchetti privati/interni — ogni coordinata che nessun registry configurato conosce, in qualsiasi ecosistema.
• Materiale crittografico; certificati committati (scadenza, chiave debole, firma debole, self-signed), chiavi private vs pubbliche tra PEM/OpenSSH/PuTTY/PGP e keystore JKS/PKCS#12. Analizzati offline, senza rete.
• Air-gapped; zero rete con --offline, testato in regressione e riproducibile sotto unshare -rn. Su Maven recupera 657/657 del risultato online di OSV-Scanner senza alcuna interfaccia di rete, contro 45 / 40 / 37 degli altri. → Benchmark · Air-gapped
• Rischio supply-chain; advisory note come malevole (bloccano sempre il gate CI) e sospetti typosquat (--typosquat).
• Livello audit; ogni report porta un manifest di provenienza e un capitolo Metodologia e limitazioni; gli artefatti includono SHA256SUMS; gli audit differenziali confrontano con una esecuzione precedente (--baseline) e la CI può fare gating solo sui nuovi findings.
• Un --help che sta in una schermata; la lunga coda di switch si riduce a quattro flag — -d eol,nvd disattiva cose, -a licenses,snyk attiva ciò che è disattivato di default, -r html,json sceglie gli output, -o dice dove. I singoli flag funzionano ancora e --help-all li elenca.
• Report in inglese o francese (--lang fr)
• Output e CI; HTML + JSON dei findings di default (Word .doc con --report-doc), CycloneDX 1.6 SBOM, CSAF 2.0 VEX, SARIF 2.1.0, JSON; gate con --fail-on, triage con --ignore/--vex. Registry privati per ogni ecosistema.

📖 Utilizzo e tutti i flag · Architettura · Confronto con altri tool · Fonti dei dati

Perché usare fad-checker per gli audit del codice?

Cosa fa per un audit che gli altri non fanno. Stesso set di colonne e stessa disciplina di sourcing di docs/COMPARISON.md — ⚠️ significa parziale e indica come, le celle sono pensate per essere verificabili.

¹ Niente mvn/go/npm/pip/dotnet — i manifest vengono analizzati dal disco, nulla installato o eseguito. 105 × pom.xml in un solo passaggio: 790 coppie contro le 657 di OSV-Scanner, 133 solo fad, versioni mediate per modulo non appiattite.

² 657 su 657 del risultato Maven online di OSV-Scanner, sotto unshare -rn — nessuna interfaccia di rete. Testato con tripwire; solo coordinate pubbliche lasciano mai l'enclave.

³ Il capitolo 0 nomina ogni coordinata per cui ogni registry configurato ha risposto 404 — Maven, npm, PyPI, NuGet, Composer, Go e RubyGems — con il/i manifest che la dichiara. Un registry che è andato in timeout o in errore non viene mai conteggiato: una risposta inconcludente accuserebbe altrimenti un cliente di distribuire pacchetti interni perché il suo proxy era instabile. -e <regex> le esclude poi.

⁴ -t <dir>: POM normalizzati più ogni lockfile non-Maven rispecchiato, coordinate private rimosse. Archiviabile e scansionabile da qualsiasi cosa — --snyk incluso.

⁵ endoflife.date, suddiviso diretto vs transitivo così sai quale dipendenza aggiornare, più deprecati / abbandonati / yanked e non aggiornati. Trivy copre solo le distro OS; la salute dei pacchetti di Snyk è solo web.

⁶ Inventario e verdetti: scadenza, RSA<2048, MD5/SHA1, self-signed; chiavi private vs pubbliche; JKS/PKCS#12. Parser offline. La regola sui secret di Trivy trova il file, non il difetto.

⁷ Identificati tramite hash via deps.dev + CIRCL → dovrebbe-essere-dichiarato / nome≠checksum / sconosciuto / malevolo. I pattern di Syft nominano una versione, non un'identità.

⁸ Il capitolo 0 segnala ciò che questa scansione non ha potuto raggiungere (lockfile mancanti, versioni solo-BOM, Yarn Berry, runtime PHP indeterminabile); il capitolo 6.3 dichiara ciò che il tool non valuta mai. Altrove il primo è una riga di log che l'audit non vede mai, il secondo non è scritto da nessuna parte.

⁹ Manifest di provenienza: tool, runtime, modalità, configurazione di esecuzione e freschezza della cache per tutte le 13 fonti. Grype e Dependency-Check portano la data di una fonte, non dell'esecuzione.

¹⁰ Capitoli da 0→6 con un executive summary e ricette di fix, HTML autonomo più un gemello Word .doc. Nessuno degli altri emette Word.

¹¹ Quattro grafici SVG inline — CWE per severità peggiore, transitive vulnerabili per dipendenza radice, i tuoi moduli più vulnerabili (diretto vs transitivo su un progetto mono-modulo), fasce di priorità di fix — renderizzati anche nel .doc, con copia con un clic come PNG (o una tabella come HTML ricco) che si incolla in Word formattata. Ogni CVE mantiene il suo vettore CVSS, CWE, riferimenti, configurazione CPE e via-path dietro un drill-down, con zero asset esterni.

¹² --baseline aggiunge un capitolo Δ (nuovi / risolti / invariati); --fail-on-new fa gating solo sui nuovi findings. Snyk traccia questo sulla sua piattaforma, non come diff locale.

Dove perde — container/pacchetti OS, PR di auto-fix e copertura CVE rispetto al feed curato di Snyk → docs/COMPARISON.md · il divario, misurato.

Deliberatamente non un obiettivo: la raggiungibilità. Un finding è una versione vulnerabile sul grafo delle dipendenze, e il report dice esattamente questo (cap. 6.3) invece di indovinare i call path. Decidere se il codice vulnerabile è raggiungibile in questa applicazione è compito dell'auditor, preso con il contesto applicativo che nessuno scanner ha.

[!WARNING] fad-checker è nuovo e potrebbe ancora contenere ( rari ) bug. Tratta il suo output come una solida prima passata, ricontrolla qualsiasi cosa critica e per favore segnala i problemi; vengono risolti rapidamente.

Avvio rapido```bash

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

Cosa fa effettivamente -t <dir>. È un passo di estrazione, non un adattatore Snyk. Scrive un albero parallelo di descrittori di dipendenze normalizzati: ogni pom.xml ridotto ai nodi rilevanti per le dipendenze (coordinate, properties, dependencyManagement, dependencies, modules), i parent del reactor ricablati al loro reale relativePath nell'albero, ${…} risolti nelle coordinate — più ogni lockfile/manifest non-Maven rispecchiato allo stesso percorso relativo (package-lock/yarn.lock/pnpm-lock, composer.lock, poetry/Pipfile/uv/pdm, *.csproj/packages.lock.json, go.mod/go.sum, Gemfile.lock, e companion come Directory.Packages.props o nuget.config). Online sonda anche ogni coordinata contro i repository Maven configurati e segnala quelle che non esistono lì — i tuoi moduli privati/interni — che -e <regex> poi rimuove dai POM riscritti. Poi si ferma: nessuna passata CVE/EOL e nessun report a meno che tu non passi anche --snyk, un --report-<type>, --fail-on* o --baseline. Quello che ottieni è un inventario di dipendenze sanificato e senza build che puoi archiviare come evidenza di audit, consegnare a un cliente o a una revisione legale, o puntare a qualsiasi scanner — Snyk via --snyk essendo uno di questi.

[!IMPORTANT] --offline legge la cache, non la sostituisce. Su una cache fredda non c'è nulla con cui confrontarsi, quindi una prima esecuzione offline riporta legittimamente 0 CVE / 0 EOL / 0 obsoleti; quella è una cache vuota, non un progetto pulito. Scalda la cache una volta (una normale esecuzione online su qualsiasi progetto, o --import-cache), poi --offline restituisce il set completo di risultati con zero chiamate di rete. Le macchine air-gapped ottengono la loro cache tramite --export-cache / --import-cache.

Un singolo binario autonomo (senza Node), l'installazione da sorgente e il completamento shell sono in → docs/USAGE.md.

Cosa trova

Il report è organizzato in capitoli radice (ciascuno raggruppa sotto-capitoli correlati):

Il report HTML si apre in qualsiasi browser, contiene ogni dettaglio (vettori CVSS, riferimenti, descrizioni complete, configurazioni CPE, via-path per i transitivi) e include un gemello .doc compatibile con Word. Ogni corrispondenza porta una priorità composita (sfruttata da KEV > probabilità EPSS > severità CVSS), e l'esecuzione può inoltre emettere un SBOM CycloneDX 1.6 (--report-sbom, vulnerabilità inline) e un CSAF 2.0 VEX (--report-csaf) per strumenti a valle.

Copertura, onestamente: le coppie che Snyk riporta e fad-checker no

Nessuno strumento trova tutto. fad-checker è in testa all'87% di un'unione di 908 coppie, e 131 coppie sono tornate da Snyk e non da esso. Valutate una per una contro OSV, nessuna è un bug di recall:

Due terzi contraddicono il registro pubblico, quindi riportarli significherebbe spedire falsi positivi. CVE-2023-6481 è l'esempio limpido: rivendicata su [email protected], si lega a logback-core a [1.2.12, 1.2.13) — artefatto errato, e una versione pubblicata prima che il difetto esistesse.

Ambito. Tutte le 131 sono di Snyk: OSV-Scanner, Trivy e Grype+Syft hanno contribuito ciascuno con 0 rilevamenti che nessun altro aveva. E tutte sono sul target Maven — fuori da Maven il grafo è nel lockfile, ogni scanner legge lo stesso input, e il benchmark misura set di rilevamenti identici su npm, RubyGems e Composer.

Ecco perché esiste --snyk. fad-checker prende l'output di snyk test come input e lo unisce, così ottieni l'unione invece di scegliere una parte. Una scelta di copertura, non una correzione.

Metodo, avvertenze e i verdetti per coppia → docs/BENCHMARK.md; riproduci con scripts/adjudicate-gap.js.

Audit air-gapped

Garanzia di zero dati inviati. Sotto --offline, fad-checker non effettua alcuna chiamata di rete di sorta; legge solo le cache riscaldate in ~/.fad-checker/ e non trasmette mai una dipendenza, un percorso o un rilevamento fuori dalla macchina. È testato per regressioni (test/offline-guarantee.test.js, un fetcher tripwire che lancia un'eccezione se toccato) e riproducibile dall'auditor: unshare -rn node fad-checker.js -s ./proj --offline … lo esegue in un namespace con nessuna interfaccia di rete e produce rilevamenti identici byte per byte. A differenza dei scanner OSS mainstream, fad risolve anche il grafo transitivo Maven offline; quindi su un progetto multi-modulo air-gapped trova le CVE transitive che loro non riescono a trovare.

Quando il sistema sottoposto ad audit è offline / riservato (tipico di un audit regolamentato o air-gapped) non può raggiungere OSV / NVD / Maven Central / npm. Suddividi il lavoro tra macchine mantenendo zero informazioni sull'ambiente fuori dall'enclave sicura: un descrittore anonimizzato porta solo coordinate di pacchetti pubblici; nessun percorso filesystem, nessun URL di registry, nessun hostname/username; e il report dettagliato è prodotto di nuovo sulla macchina offline.

Il trasferimento si basa su una proprietà delle cache di fad-checker: sono indicizzate per coordinata o id di vulnerabilità, mai per percorso, quindi sono indipendenti dalla macchina. Il passo online si limita a riscaldare le cache; il passo offline riproduce la scansione e ottiene cache hit.```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.