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 vengono emesse per ogni cliente dal tuo team dell'account Cert-IX. 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 conservato come documento archiviato.
Un ID di advisory / CVE	Cerca il suo dettaglio o l'intelligence sullo sfruttamento.

DepCheck estrae le coordinate (quali pacchetti, quali versioni) da un manifest — 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

Questa è la parte che conta per una postura sovrana:

• I dati sugli advisory vengono serviti per primi dal mirror sovrano degli advisory Cert-IX (osv-advisories) ospitato all'interno del cluster Cert-IX, arricchito con l'intelligence sullo sfruttamento CISA KEV ed EPSS proveniente dagli indici propri del cluster. In caso di hit sul mirror — il caso comune — la tua ricerca non lascia mai l'infrastruttura Cert-IX.
• Fallback in tempo reale: se il mirror non ha una risposta (un advisory molto recente, o un pacchetto che il mirror non ha ancora indicizzato), DepCheck ricorre all'API pubblica osv.dev per correttezza. suggest_safe_version utilizza in aggiunta deps.dev per enumerare le release di un pacchetto. In quei casi di fallback, la coordinata del pacchetto (ecosystem, name e version) viene inviata a quel servizio pubblico per risolvere la risposta.
• Cosa non viene mai inviato a terze parti: il tuo manifest come documento, il tuo codice sorgente, la tua chiave API o la tua identità. Solo la coordinata minima necessaria per rispondere a una ricerca viene mai inoltrata, e solo in caso di miss sul mirror.

Vuoi zero chiamate esterne?

Esegui DepCheck localmente su stdio rispetto al mirror sovrano (o a uno snapshot offline). In quella configurazione le ricerche vengono risolte rispetto al mirror senza traffico di fallback pubblico — adatto ad ambienti air-gapped o ad alta garanzia. 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 e si trova su una rete Docker dedicata a singolo servizio — gli altri servizi della piattaforma non possono raggiungerlo direttamente, e lui non può raggiungere loro.
• 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 mirror-sovrano-per-primo mantiene per impostazione predefinita l'attività di controllo delle dipendenze all'interno dell'infrastruttura UE/Cert-IX, con il fallback pubblico limitato alla coordinata minima necessaria per la correttezza.

Se hai bisogno di un addendum sul trattamento dei dati o di una garanzia di residenza per un carico di lavoro regolamentato, parla con il tuo team dell'account Cert-IX di un deployment dedicato o completamente offline.

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.