Sicurezza e gestione dei dati

📄 Preferisci offline? Scarica questa guida in PDF.

DepCheck è uno strumento di sicurezza, quindi è tenuto agli standard di uno strumento di sicurezza. Questa pagina spiega in modo chiaro come ti autentica, cosa fa con i dati che gli invii e cosa esce — e cosa non esce — dal perimetro Cert-IX.

Autenticazione

• Ogni richiesta a https://mcp.cert-ix.com/depcheck deve trasportare una chiave API valida come Authorization: Bearer <key>. Le richieste che ne sono prive ricevono 401; il backend non vede mai traffico non autenticato.
• Le chiavi sono gratuite e self-service: richiedine una su cert-ix.com/tools/depcheck-mcp, conferma il tuo indirizzo e-mail e la chiave ti arriva via e-mail. Una chiave dura 90 giorni e può essere rinnovata dall'e-mail di promemoria inviata prima della scadenza. Tratta una chiave come una password: conservala nella configurazione del tuo client MCP o in un archivio di segreti, mai nel controllo del codice sorgente, e ruotala se pensi che possa essere trapelata.
• Tutto il traffico avviene su TLS. Non inviare chiavi o manifest tramite HTTP in chiaro.

Limiti di velocità e protezione dagli abusi

L'endpoint ospitato applica i limiti sul bordo (host nginx), prima che venga svolto qualsiasi lavoro:

Ambito	Limite
Per chiave API	20 richieste/secondo (breve picco fino a 40), 20 connessioni concorrenti
Per IP sorgente	40 richieste/secondo (picco 80), 40 connessioni concorrenti

Il superamento di un limite restituisce 429 Too Many Requests — riduci la frequenza e riprova. Questi tetti sono ampiamente al di sopra del normale utilizzo da parte di un agente (una manciata di controlli per modifica); esistono per fermare i sovraccarichi, non per limitare il lavoro reale.

I ripetuti errori di autenticazione vengono trattati come abuso: un IP che produce molti 401 in una breve finestra viene temporaneamente bloccato (fail2ban). Chi possiede una chiave valida non incontra mai questo caso, perché una chiave corretta non produce mai 401.

Cosa invii e cosa gli succede

Gli strumenti di DepCheck sono ricerche in sola lettura. Ecco esattamente per cosa viene usato ciascun tipo di input:

Cosa invii	Cosa ne fa DepCheck
Una coordinata di pacchetto (ecosystem, name, version)	La cerca rispetto ai dati sugli advisory e restituisce gli advisory corrispondenti.
Un corpo di manifest (manifest_content)	Lo analizza in memoria per estrarre le coppie nome/versione dei pacchetti, quindi le cerca. Viene usato per produrre il tuo risultato e non viene né archiviato né registrato nei log da DepCheck.
Un ID di advisory / CVE	Cerca il suo dettaglio o la sua intelligence sullo sfruttamento.

Il manifest in sé raggiunge effettivamente il server Cert-IX — lo strumento scan_dependencies ospitato ne riceve il testo nella richiesta — ma non va oltre: DepCheck ne estrae le coordinate (quali pacchetti, quali versioni) e cerca quelle. Non ha bisogno, non vuole e non analizza il tuo codice sorgente, e il server ospitato non ha alcun accesso al tuo filesystem (è per questo che accetta il testo del manifest, non un percorso).

Quali dati operativi vengono conservati

Per far funzionare il servizio, DepCheck conserva solo contatori aggregati — totale delle richieste, errori, conteggio in corso e conteggi delle chiamate per strumento / per cliente ai fini della capacità e del monitoraggio. Questi contatori registrano che un cliente ha chiamato uno strumento, non i nomi dei pacchetti, le versioni o il contenuto del manifest nella chiamata. Sono esposti su un endpoint /metrics interno e protetto da token che non è mai raggiungibile da internet pubblico.

Residenza dei dati — dove risiedono i dati sugli advisory

DepCheck interroga prima il mirror, ma non solo il mirror. Risponde dall'infrastruttura Cert-IX quando può, e resta corretto quando non può:

• Prima il mirror. Le ricerche degli advisory vengono servite innanzitutto dalla copia dei dati sugli advisory OSV di proprietà di Cert-IX, arricchita con l'intelligence sullo sfruttamento CISA KEV ed EPSS proveniente dagli indici propri di Cert-IX. Quando il mirror può rispondere, la ricerca viene risolta sull'infrastruttura Cert-IX.
• Fallback su osv.dev. Quando il mirror non può rispondere con certezza — l'ecosistema del pacchetto non è coperto, il mirror è più vecchio di quanto consenta il suo limite di freschezza, un record di advisory non può essere abbinato con certezza, oppure il mirror restituisce un errore — DepCheck interroga invece l'API pubblica osv.dev, anziché dichiarare «pulito» sulla base di dati di cui non può fidarsi. get_advisory fa lo stesso per un ID di advisory che il mirror non contiene.
• Elenchi delle versioni da deps.dev. suggest_safe_version legge l'elenco delle release di un pacchetto dall'API pubblica deps.dev a ogni chiamata (le risposte restano in cache in memoria per un'ora), poi verifica le versioni candidate come sopra.
• Cosa ricevono quei servizi. osv.dev e deps.dev sono gestiti da Google, negli Stati Uniti. Ricevono una coordinata di pacchetto — ecosistema, nome e, per osv.dev, versione — oppure, per get_advisory, l'ID dell'advisory. Il tuo file manifest, il tuo codice sorgente, la tua chiave API e la tua identità non vengono inviati.
• Nomi di pacchetti privati. Se un manifest o una chiamata a check_package nomina pacchetti privati o interni, quei nomi possono raggiungere osv.dev lungo il percorso di fallback. Tieni i nomi di pacchetti riservati fuori dalle chiamate a DepCheck.

Anche il tuo client MCP, e il modello AI che vi sta dietro, vedono tutto ciò che il tuo agente invia e riceve. Quella parte è regolata dal tuo client e dal tuo fornitore del modello, non da Cert-IX.

Nessuna modalità senza traffico in uscita, per ora

DepCheck non ha alcuna configurazione che garantisca zero chiamate esterne. Un'istanza locale stdio interroga direttamente osv.dev a meno che non abbia accesso a un mirror Cert-IX, e suggest_safe_version legge sempre gli elenchi delle versioni da deps.dev. Vedi Per iniziare → Opzione 2.

Postura di rete (ospitata)

• L'endpoint è fronteggiato da host nginx, che è l'unico ingresso e si occupa dell'autenticazione, del rate-limiting e della terminazione TLS.
• Il container DepCheck è pubblicato solo sul loopback dell'host, quindi non è raggiungibile da internet se non attraverso quel nginx.
• L'endpoint MCP (/depcheck) è l'unico percorso esposto pubblicamente. I percorsi operativi (/metrics, health) sono solo interni.

Note sulla conformità

• DepCheck elabora coordinate di pacchetto e identificatori di advisory — metadati tecnici, non dati personali. Un manifest che invii viene analizzato in modo transitorio per estrarre quelle coordinate e non viene conservato come documento archiviato.
• Le chiavi API identificano un cliente/organizzazione, usate per il controllo degli accessi e la contabilità aggregata dei limiti di velocità — non per la profilazione.
• Il design che privilegia il mirror mantiene le ricerche sull'infrastruttura Cert-IX ogni volta che il mirror può rispondere. Non garantisce che ogni ricerca vi rimanga: le ricerche di fallback e gli elenchi delle versioni di suggest_safe_version vanno a osv.dev e deps.dev, con le sole coordinate dei pacchetti.

Se hai bisogno di un addendum sul trattamento dei dati per un carico di lavoro regolamentato, o di impegni di residenza che vadano oltre quanto descritto in questa pagina, parla con il tuo team dell'account Cert-IX.

Checklist delle buone pratiche

• ✅ Conserva la chiave API nella configurazione dei segreti del tuo client MCP, non nel repository.
• ✅ Ruota la chiave in caso di cambi di personale o sospetta esposizione.
• ✅ Scansiona i lockfile per la verità di ciò che è installato, non solo i manifest con intervalli.
• ✅ Ripeti periodicamente la scansione — "pulito oggi" non significa "pulito per sempre".
• ✅ Correggi per prime le rilevazioni contrassegnate exploited (vedi Riferimento degli strumenti → get_cve_intel).
• ✅ Mantieni DepCheck come un solo strato — abbinalo a revisione, SAST e principio del privilegio minimo.