Sicurezza e trattamento dei dati

SecCheck è uno strumento di sicurezza, quindi è tenuto agli standard di uno strumento di sicurezza. Questa pagina dichiara con chiarezza come la autentica, cosa registra e cosa esce — e cosa no — dal perimetro Cert-IX.

Autenticazione e abilitazioni

• Ogni richiesta a https://mcp.cert-ix.com/seccheck deve portare 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: ne richieda una su cert-ix.com/tools/seccheck-mcp, confermi il suo indirizzo e-mail e la chiave le arriva via e-mail. Una chiave self-service corrisponde all'edizione Community, dura 90 giorni e può essere rinnovata dall'e-mail di promemoria inviata prima della scadenza. Tratti una chiave come una password: la conservi nella configurazione del suo client MCP o in un gestore di segreti, mai nel controllo di versione, e la ruoti se potrebbe essere trapelata.
• Tutto il traffico passa da TLS. Non invii chiavi su HTTP in chiaro.

La sua edizione viaggia con la sua chiave, ed è questa la parte da capire:

Le abilitazioni sono risolte all'edge, a ogni richiesta

L'edge Cert-IX autentica la sua chiave e poi imposta le sue abilitazioni sulla richiesta inoltrata — incondizionatamente, a ogni richiesta, anche se vuote. Un chiamante non può quindi dichiarare il proprio livello inviando da sé informazioni sulle abilitazioni: qualunque cosa invii viene sovrascritta prima che il backend la veda.

Il server si rifiuta di avviarsi in modalità ospitata se è configurato un file di licenza a livello di processo, perché una sola variabile d'ambiente promuoverebbe altrimenti tutti i chiamanti in un colpo solo. Le abilitazioni provengono dalla sua chiave, una richiesta alla volta, oppure non ci sono affatto.

Se uno strumento restituisce un errore di limitazione inatteso, richiami license_status — riporta esattamente cosa sblocca la sua credenziale.

Limiti di frequenza e protezione dagli abusi

L'endpoint ospitato applica i limiti all'edge (nginx dell'host), prima di svolgere qualsiasi lavoro:

Ambito	Limite
Per chiave API	20 richieste/secondo (breve raffica fino a 40), 20 connessioni contemporanee
Per IP di origine	40 richieste/secondo (raffica 80), 40 connessioni contemporanee

I limiti per IP si applicano prima dell'autenticazione, così anche le ondate non autenticate risultano limitate.

Superare un limite restituisce 429 Too Many Requests con un'intestazione Retry-After. La rispetti e applichi un backoff esponenziale; un client corretto dovrebbe restare comodamente sotto le 10 richieste/secondo per chiave. Questi tetti sono ben oltre il normale uso di un agente — qualche ricerca e uno o due caricamenti per compito — ed esistono per fermare le ondate, non per frenare il lavoro reale.

I fallimenti di autenticazione ripetuti sono trattati come abuso: un IP che produce molti 401 in poco tempo viene bloccato temporaneamente (fail2ban). Chi possiede una chiave valida non arriva mai a questo, perché una chiave corretta non produce mai 401.

Cosa invia e cosa ne viene fatto

Gli strumenti di SecCheck sono consultazioni di sola lettura su un corpus fisso. Ecco esattamente a cosa serve ciascun tipo di input:

Lei invia	Cosa ne fa SecCheck
Una query di ricerca e dei filtri	Li valuta rispetto al catalogo in memoria e restituisce i riepiloghi dei playbook corrispondenti.
Un id di skill	Restituisce lo SKILL.md di quel playbook.
Un id di skill + un percorso di risorsa	Restituisce quel file incluso, risolto rigorosamente all'interno della directory propria dello skill.

Non invia mai a SecCheck il suo codice, i suoi log, i suoi rilievi né alcunché sul suo ambiente — gli strumenti ricevono una stringa di ricerca e degli identificativi, nient'altro. Il server ospitato non ha accesso al suo file system né alcuna possibilità di raggiungere i suoi sistemi.

Quali dati operativi vengono conservati

Esistono due registrazioni, entrambe deliberatamente ristrette:

• Misurazione dell'utilizzo — conteggi di chiamate aggregati per strumento e per cliente, per capacità e monitoraggio. Un indicatore vivo, non un registro di fatturazione.
• Un record di audit per chiamata a strumento, con il nome dello strumento, solo i nomi degli argomenti, la sua etichetta cliente, il suo livello e se la chiamata è andata in errore.

Le query di ricerca non vengono mai registrate

Il record di audit annota che lei ha chiamato search_skills con un argomento query — non cosa diceva la query. Una query di ricerca è input dell'utente e può descrivere un incidente in corso; registrare la chiave senza il valore è ciò che rende il log una prova per la revisione degli accessi anziché uno scarico di debug della sua postura di sicurezza.

Entrambe sono esposte solo su un endpoint /metrics interno protetto da token, mai raggiungibile dalla rete pubblica, che fallisce in chiusura — senza token configurato rifiuta del tutto di rispondere.

Residenza dei dati — dove risiedono i contenuti

Per SecCheck la risposta è semplice:

• L'intero corpus di 857 playbook è incorporato nel server SecCheck e servito dalla memoria. Ricerca, caricamento e lettura delle risorse sono tutti gestiti dal server che ha ricevuto la richiesta.
• SecCheck non effettua chiamate in uscita verso servizi di terze parti al momento della richiesta. Non c'è API a monte, né consultazione di ripiego, né telemetria verso un fornitore esterno — lo stesso server risponde anche con la rete completamente disattivata. La sua query riceve risposta sull'infrastruttura Cert-IX e non viene inoltrata altrove.
• Anche il suo client MCP, e il modello IA che vi sta dietro, vedono tutto ciò che il suo agente invia e riceve. Quella parte è regolata dal suo client e dal suo fornitore del modello, non da Cert-IX.

Desidera un'installazione completamente offline?

Esegua SecCheck in locale via stdio — il binario porta con sé il corpus e non richiede alcuna rete, il che si adatta ad ambienti isolati e ad alta garanzia. Si veda Guida introduttiva → Opzione 2. Il binario locale non è ancora scaricabile pubblicamente: si rivolga al suo team dell'account Cert-IX.

Postura di rete (ospitato)

• L'endpoint è preceduto da nginx dell'host, unico ingresso, che si occupa di autenticazione, limitazione di frequenza, risoluzione delle abilitazioni e terminazione TLS.
• Il container SecCheck è pubblicato solo sul loopback dell'host, quindi non è raggiungibile da internet se non attraverso quel nginx.
• Il server Go rifiuta un binding non di loopback salvo deroga esplicita, perché il livello applicativo non ha alcuna autenticazione propria — l'autenticazione è compito dell'edge, e un binding su tutte le interfacce pubblicherebbe un server MCP non autenticato.
• /seccheck è l'unico percorso esposto pubblicamente per questo server. I percorsi operativi (/metrics) sono solo interni.

Integrità dei contenuti

Un corpus vuoto o parziale sarebbe la versione «falso verdetto pulito» di questo prodotto: search_skills restituirebbe «nessun risultato» e un modello lo leggerebbe come «quel lavoro di sicurezza non esiste». Per questo il server si rifiuta di avviarsi in modalità ospitata con un catalogo vuoto, e il suo controllo di integrità si dichiara non sano anziché servirlo — un'immagine priva di corpus non può superare il deployment.

Obblighi di licenza e attribuzione

I playbook sono contenuti di terze parti ridistribuiti sotto licenze permissive (Apache-2.0 e MIT), con tutti i diritti degli autori originali mantenuti.

• get_attribution restituisce origine, autore, identificativo di licenza, homepage e testo completo della licenza per ogni libreria.
• Se ridistribuisce contenuti dei playbook — internamente su larga scala, in un prodotto o in un deliverable per un cliente — riproduca quegli avvisi. L'accesso tramite SecCheck non modifica i termini di licenza sottostanti.

Note di conformità

• SecCheck tratta query di ricerca e identificativi di documento — input tecnico, non dati personali. I valori delle query non vengono conservati.
• Le chiavi API identificano un cliente/un'organizzazione, per controllo degli accessi, risoluzione delle abilitazioni e contabilizzazione aggregata della frequenza — non per profilazione.
• Il progetto a corpus incorporato risponde a ogni query sull'infrastruttura Cert-IX: SecCheck stesso non ha alcuna via di consultazione verso terze parti da cui doversi escludere.

Se le occorre un'appendice sul trattamento dei dati o una garanzia di residenza per un carico di lavoro regolamentato, ne parli con il suo team account Cert-IX per un'installazione dedicata o completamente offline.

Uso accettabile

La libreria include materiale offensivo — sfruttamento, attacchi alle credenziali, post-sfruttamento, metodologia di attacco web. È pubblicata per lavoro di sicurezza autorizzato: sistemi di sua proprietà, incarichi per cui dispone di autorizzazione scritta, CTF, ambienti di formazione e ricerca difensiva.

Usarla per attaccare sistemi che non è autorizzato a testare è un uso improprio del servizio e una sua responsabilità. Cert-IX può revocare una chiave usata in tal modo.

Elenco di buone pratiche

• ✅ Conservi la chiave API nella configurazione riservata del suo client MCP, non nel repository.
• ✅ Ruoti la chiave in caso di cambiamenti di personale o sospetta esposizione.
• ✅ Faccia in modo che l'agente segnali chiaramente un NO MATCH invece di improvvisare una procedura (si veda Flussi di lavoro degli agenti).
• ✅ Legga un playbook prima di eseguirne i comandi — è un'indicazione di terze parti scritta per lo stack di qualcun altro.
• ✅ Se il playbook ha una sezione di verifica o di convalida, la esegua prima di dichiarare concluso il lavoro.
• ✅ Riproduca gli avvisi di attribuzione se ridistribuisce contenuti.
• ✅ Mantenga SecCheck come uno dei livelli — lo abbini a revisione, test e ai suoi controlli esistenti.