# Supporto di sicurezza per SDK e strumenti Questa pagina riguarda il software che scarichi ed esegui tu stesso: gli SDK, la CLI, il provider Terraform/OpenTofu e il server MCP. Spiega per quanto tempo ricevono correzioni di sicurezza, come segnalare una vulnerabilità, dove vengono pubblicati gli avvisi di sicurezza e che cosa accompagna ogni release, così che tu possa verificare ciò che installi. KeenAuth progetta questi processi per soddisfare i requisiti dell'EU Cyber Resilience Act (CRA) per i prodotti con elementi digitali. Nessun pacchetto è ancora stato pubblicato su un registro pubblico. Tutto ciò che in questa pagina è legato a una release (SBOM, firme, provenienza) inizia con la prima release di ogni pacchetto. ## Periodo di supporto - La linea di prodotti nel suo complesso riceve supporto di sicurezza per almeno 5 anni, a partire dalla sua disponibilità generale. - Le correzioni di sicurezza vengono rilasciate nell'ultima versione major di ogni pacchetto, e l'aggiornamento a tale versione è gratuito. - La versione major precedente riceve correzioni di sicurezza per 12 mesi dopo che la major successiva diventa generalmente disponibile. - Ogni aggiornamento di sicurezza pubblicato resta disponibile per almeno 10 anni, o per il resto del periodo di supporto se più lungo. La politica completa, inclusi gli avvisi di fine vita e il supporto runtime, si trova nella pagina [politica di versioning e deprecazione](/docs/policies/versioning). ## Segnala una vulnerabilità Scrivi a **security@keenauth.com**. Questo canale è sempre aperto e non dipende da una campagna di bug bounty. - Cifra i dettagli sensibili con la nostra chiave OpenPGP, pubblicata su `https://trust.keenauth.com/pgp-key.txt`. La sua impronta digitale è `0336 4D65 3B6C AA93 98A6 BE84 5C82 4CF9 48AB 83D6`. - I nostri contatti sono pubblicati anche in `https://trust.keenauth.com/.well-known/security.txt` (RFC 9116). - Includi il nome e la versione del pacchetto, una descrizione e l'impatto, la riproduzione passo passo e, se desideri essere citato, il tuo nome o nickname. - Non segnalare vulnerabilità tramite ticket di supporto o issue pubbliche. Un'impostazione predefinita insicura in un SDK rientra nell'ambito. Tempi di risposta, regole di test, tutela legale (safe harbor) e divulgazione coordinata sono descritti nella nostra [politica di divulgazione delle vulnerabilità](https://trust.keenauth.com/vdp). ## Avvisi di sicurezza Quando correggiamo una vulnerabilità, pubblichiamo un avviso di sicurezza in `https://trust.keenauth.com/advisories`. Ogni avviso ha un identificatore nella forma `ASA-YYYY-NNNN` e indica: - una descrizione, l'impatto e l'azione che dovresti intraprendere; - per un SDK o uno strumento, il nome del pacchetto, l'intervallo di versioni interessate e la versione corretta; - un vettore CVSS v4.0 e la data della correzione; - i riconoscimenti per le persone che hanno segnalato il problema. Le vulnerabilità negli SDK, nella CLI, nel server MCP e nel provider ricevono anche identificatori CVE tramite gli avvisi di sicurezza di GitHub. Per essere avvisato, segui il feed Atom `https://trust.keenauth.com/advisories.atom` con un qualsiasi lettore di feed. Se una vulnerabilità in uno di questi prodotti è sfruttata attivamente, o un incidente grave ne compromette la sicurezza, la segnaliamo alle autorità come richiesto dal CRA e informiamo gli utenti tramite un avviso. ## SBOM e VEX Disponibili con la prima release di ogni pacchetto: - **SBOM.** Ogni release è accompagnata da una distinta base del software (software bill of materials) in formato CycloneDX JSON, che elenca i componenti contenuti nel pacchetto. - **VEX.** Quando una vulnerabilità nota in un componente elencato non interessa il pacchetto, lo dichiariamo in un documento OpenVEX. Un documento VEX viene prodotto solo quando esiste una dichiarazione del genere; una release senza di essa non ha alcun file VEX. ## Verifica una release Disponibile dalla prima release. I pacchetti JavaScript/TypeScript su npm e il pacchetto Python su PyPI sono compilati e pubblicati dai repository pubblici degli SDK tramite un workflow di rilascio che usa il trusted publishing, senza token di registro di lunga durata. - **npm:** i pacchetti sono pubblicati con provenienza. Verifica le firme del registro e le attestazioni di provenienza dei pacchetti nel tuo progetto con: ```sh npm audit signatures ``` - **PyPI:** le release sono pubblicate con attestazioni, visibili nella pagina del progetto. - **Bundle Sigstore:** ogni file del pacchetto e il relativo SBOM sono firmati con la firma keyless di Sigstore, e i file del pacchetto includono un'attestazione di provenienza SLSA. Questi file sono allegati all'esecuzione del workflow di rilascio nel repository pubblico degli SDK e vi restano conservati per 90 giorni. Verifica un file scaricato con: ```sh cosign verify-blob --bundle .sigstore.json \ --certificate-identity "https://github.com///.github/workflows/release.yml@refs/tags/" \ --certificate-oidc-issuer https://token.actions.githubusercontent.com ``` Il comando deve riportare che la firma è stata verificata. Usa il repository e il tag della release che hai scaricato. Il server MCP è un pacchetto npm e segue i passaggi npm sopra indicati. I passaggi di firma e verifica per l'SDK Go, la CLI e il provider saranno pubblicati qui con la loro prima release.