Controllo delle modifiche crittografiche ed evidenze CBOM

Quantsiv trova la crittografia che i computer quantistici potrebbero violare

Mostra cosa correggere per primo, in base a quanto a lungo i tuoi dati devono restare segreti, e segnala le modifiche che ne aggiungono altra. Per impostazione predefinita la scansione avviene nella tua pipeline di build e produce un inventario standard di ciò che ha trovato: una Cryptographic Bill of Materials (CBOM).

Perché è importante Guarda la roadmap

Un futuro computer quantistico potrebbe violare la crittografia a chiave pubblica oggi di uso comune, e Stati Uniti e UE hanno pubblicato le date per sostituirla. Sostituirla comincia dal sapere dove si trova. Quantsiv scansiona il tuo codice a ogni build e mostra cosa è esposto, per quanto tempo resta esposto e verso cosa migrare.

Harvest Now, Decrypt Later

Gli attaccanti possono copiare oggi i dati cifrati e conservarli finché un computer quantistico non potrà decifrarli. Per i dati che devono restare segreti per anni, il rischio comincia adesso.

Rubare ora, leggere dopo

Oggi a un attaccante non serve un computer quantistico. Gli basta registrare adesso il tuo traffico cifrato e i dati rubati, e decifrarli quando esisterà un computer quantistico abbastanza grande. RSA, ECDSA, Diffie-Hellman e DSA, i metodi a chiave pubblica di uso comune, cedono tutti a un metodo quantistico noto, l'algoritmo di Shor. Per i wallet di cripto-attività la blockchain stessa è l'archivio: una chiave pubblica già on-chain basta per falsificare un trasferimento in futuro.

La vera scadenza è la vita utile dei tuoi dati

Non conta quando arriverà il computer quantistico, ma per quanto tempo i tuoi dati devono restare segreti. Se i dati di un sistema devono restare riservati per 25 anni, il traffico registrato ieri è già a rischio. Cartelle cliniche, dati finanziari, comunicazioni governative e segreti industriali spesso devono restare segreti per anni.

Gli assistenti di programmazione IA possono ripetere scelte predefinite vulnerabili

Gli assistenti di programmazione scelgono la crittografia completando schemi familiari, e possono così ripetere vecchie scelte predefinite che un computer quantistico potrebbe violare. Il codice funziona e supera i test, ed è comunque vulnerabile.

Oggi

Cattura

Gli attaccanti registrano il traffico cifrato, copiano i dati cifrati e li conservano.

Dopo

Decifratura

Un computer quantistico abbastanza grande viola la crittografia a chiave pubblica che proteggeva le copie conservate.

Poi

Esposizione

I dati la cui cifratura si basava su RSA o ECC possono allora essere letti, compresi quelli che devono restare riservati ancora per anni. Per le firme il rischio è diverso: la falsificazione futura, non la lettura di dati vecchi.

La scadenza è già fissata

Sono date pubblicate, non previsioni. Enti di normazione e governi negli Stati Uniti e nell'UE hanno pubblicato linee guida e requisiti con date definite per sostituire la crittografia vulnerabile.

13 ago 2024

Il NIST pubblica gli standard sostitutivi

L'istituto di standardizzazione statunitense pubblica tre nuovi algoritmi: FIPS 203 (ML-KEM) per concordare le chiavi che cifrano i dati, e FIPS 204 (ML-DSA) e FIPS 205 (SLH-DSA) per le firme digitali. I sostituti ora esistono.
nov 2024

Il NIST propone quando dismettere gli algoritmi attuali

Nella bozza pubblica iniziale di NIST IR 8547, RSA, ECC e DH con sicurezza a 112 bit, come RSA-2048, sono deprecati (deprecated) dopo il 2030. Tutti gli algoritmi a chiave pubblica vulnerabili agli attacchi quantistici, P-256 compreso, non sono più consentiti (disallowed) dopo il 2035.
22 giu 2026

Un ordine esecutivo statunitense fissa scadenze per il 2030 e il 2031

L'ordine esecutivo 14412 affronta la minaccia harvest now, decrypt later. Fissa il 31 dic 2030 per lo scambio di chiavi post-quantum e il 31 dic 2031 per le firme, sugli high-value asset e sui sistemi ad alto impatto.
24 giu 2026

OMB M-26-15 pianifica la migrazione federale in fasi

Cinque fasi dal 2026 al 2035, dall'Office of Management and Budget statunitense. Le agenzie federali costruiscono un inventario automatizzato i cui dati "should populate a central Cryptographic Bill of Materials" (dovrebbero alimentare una CBOM centrale). I piani delle agenzie vanno presentati entro il 22 ott 2026.
~mar 2027

Linee guida su cosa dovrebbe contenere una CBOM

La CISA, l'agenzia statunitense per la cybersicurezza, in coordinamento con il NIST, pubblica linee guida sugli elementi minimi della CBOM entro 270 giorni dall'EO 14412, intorno a marzo 2027.
2030 – 2035

Le scadenze della migrazione arrivano al 2035

In base all'EO 14412, scambio di chiavi entro il 31 dic 2030 e firme entro il 31 dic 2031 sugli high-value asset e sui sistemi ad alto impatto, con una proposta di norma FAR (Federal Acquisition Regulation) per i contraenti interessati. NSA CNSA 2.0 fissa date di uso esclusivo tra il 2030 e il 2033, a seconda della categoria. Nell'UE, la roadmap del Gruppo di cooperazione NIS (23 giu 2025, una raccomandazione) chiede strategie nazionali entro la fine del 2026, i casi d'uso ad alto rischio entro la fine del 2030 e il maggior numero di sistemi possibile entro il 2035.

Fonti: EO 14412, OMB M-26-15, NIST IR 8547, CISA Post-Quantum Cryptography Initiative, NSA CNSA 2.0, NIST FIPS 203, roadmap del Gruppo di cooperazione NIS (UE).

Come funziona Quantsiv

Quattro passi, dalla scansione del tuo codice a un registro standard della sua crittografia (una CBOM CycloneDX 1.6).

1. Individuare

Quantsiv cerca la crittografia nel codice sorgente, nei file di chiavi e certificati, negli script di build e nelle connessioni sicure (TLS) dei server che indichi o di cui dimostri la proprietà. Per impostazione predefinita gira nella tua CI, la build automatica che parte ogni volta che i tuoi sviluppatori modificano il codice. Solo la CBOM e i dettagli di ogni rilevamento arrivano a Quantsiv, e solo se li carichi.

2. Analizzare

Ogni rilevamento viene confrontato con gli algoritmi che un computer quantistico potrebbe violare: RSA, ECDSA, Diffie-Hellman e DSA. Cifratura e scambio di chiavi vengono ordinati in base a quanto a lungo dichiari che i dati devono restare segreti, il rischio harvest now, decrypt later. Le firme vengono ordinate su un binario separato, rispetto alla scadenza per le firme.

3. Dare priorità

I risultati sono ordinati in modo che le correzioni più importanti vengano prima, non la lista più lunga. Una cartella clinica che deve restare segreta per anni e un token di accesso di breve durata non sono lo stesso rischio, anche se entrambi usano RSA. Ogni rilevamento spiega perché occupa quella posizione e, dove l'uso è chiaro, verso quale standard migrare.

4. Dimostrare

Quantsiv produce una CBOM CycloneDX 1.6, un file SARIF per gli strumenti di analisi del codice e un report ordinato. Ogni build viene confrontata con l'ultima build del tuo branch principale, e il controllo delle modifiche segnala la crittografia che una modifica aggiunge, così la migrazione non torna indietro.

Cosa fa Quantsiv

Quantsiv trova la crittografia riconoscendo schemi noti nel codice. Rileva le API crittografiche comuni in Python, JavaScript e TypeScript, Go, Java e Kotlin, C#, Rust, Ruby, PHP, C e C++, Objective-C, Swift e Dart, i comandi openssl, ssh-keygen e keytool negli script di CI e di shell, e chiavi e certificati in formato PEM e SSH. Poiché riconosce schemi, la profondità varia a seconda del linguaggio e alcune chiamate non vengono rilevate.

Cryptographic Bill of Materials

Come una lista di ingredienti per la crittografia: cosa è stato trovato e dove. Quantsiv produce CycloneDX 1.6 che supera la validazione rigorosa dello schema, importa una CBOM CycloneDX 1.6 da qualsiasi altro strumento ed esporta l'ultima CBOM di ogni repository in un solo documento.

Ordinata in base a quanto i dati restano segreti

Dichiari per quanto tempo ogni tipo di dato deve restare riservato, e cifratura e scambio di chiavi vengono ordinati in base a quella durata. Le firme sono seguite a parte, rispetto alla scadenza per le firme, perché il loro rischio è la falsificazione, non che qualcuno legga dati vecchi.

Segnala le modifiche che ne aggiungono altra

Ogni build viene confrontata con l'ultima build del tuo branch principale, e la crittografia che una modifica aggiunge viene segnalata. Imposta regole per ogni tipo di dato e registra le eccezioni con il nome di chi le approva e una data di scadenza. I risultati arrivano a GitHub Code Scanning come SARIF e, con il template per GitHub Actions, alla pull request come commento.

Gira nella tua build

Un container, un pacchetto pronto all'uso, con template per GitHub Actions, GitLab, Jenkins e Azure DevOps. La scansione funziona offline. Solo la CBOM e i dettagli di ogni rilevamento arrivano a Quantsiv, e solo se li carichi.

Chiavi, certificati e connessioni sicure

Legge i file di chiavi e certificati per ricavarne algoritmo e dimensione, e non conserva mai la chiave stessa. Sonda la connessione sicura (TLS) dei server che indichi; il servizio in hosting sonda solo i domini di cui dimostri la proprietà con un record DNS.

Codice di wallet e custodia

Trova la firma e lo scambio di chiavi nelle librerie per wallet comuni: chiavi di firma secp256k1 ed Ed25519, firme Schnorr e trasporto di chiavi ECDH ed ECIES. Una volta che la chiave pubblica di un wallet è sulla blockchain, il suo rischio è un trasferimento falsificato, non la decifratura, e le indicazioni del rilevamento dicono cosa fare finché la chain non accetta firme post-quantum. Legge il codice, non la blockchain.

Per gli assistenti di programmazione IA

Un connettore in sola lettura (un server MCP) permette a un assistente di programmazione basato sull'IA di consultare le tue regole e le durate dichiarate dei dati prima di scrivere crittografia. Lo stesso controllo viene poi eseguito nella tua build. Il connettore non può modificare nulla e non contiene alcun nostro modello di IA.

Verso cosa migrare

Dove l'uso è chiaro, ogni rilevamento indica lo standard verso cui migrare: ML-KEM (FIPS 203), ML-DSA (FIPS 204) o SLH-DSA (FIPS 205), con scambio di chiavi ibrido, vecchio e nuovo combinati, durante la transizione.

Limiti dichiarati

Il pattern matching non rileva le chiamate fatte con un altro nome o costruite durante l'esecuzione, il codice esterno copiato in un progetto (vendored code) e i pacchetti di terze parti (dipendenze). Dichiariamo i limiti fin dall'inizio.

Roadmap

Pianificata secondo le scadenze statunitensi ed europee qui sopra.

Fase 1 · Ora → 2027

Audit

Mostrare dove ogni applicazione usa la crittografia, dall'interno della sua build. Le funzionalità qui sopra sono già realizzate; i prossimi passi di questa fase:

Crittografia post-quantum e ibrida conteggiata come avanzamento della migrazione, in codice, chiavi, certificati e configurazione
Un inventario dei pacchetti di terze parti (dipendenze): quali introducono crittografia
Report che dichiarano la propria copertura, perché una scansione parziale non venga scambiata per una pulita
Output CBOM allineato agli elementi minimi CISA una volta pubblicati, intorno a marzo 2027, e CycloneDX 1.7 accettato in importazione
Report di evidenza CBOM per gli auditor, con riferimento alle linee guida statunitensi ed europee

Fase 2 · 2027 → 2028

Migrazione

Chiudere il ciclo dal rilevamento alla correzione, con una persona che approva ogni modifica.

Correzioni suggerite come bozze di pull request con la modifica al codice, la motivazione e la linea guida citata, da far revisionare a una persona
Obiettivi di migrazione con scambio di chiavi ibrido come impostazione predefinita, con le versioni di piattaforma richieste da ogni modifica
Test che verificano ogni modifica prima che una persona la revisioni

Fase 3 · 2028 → 2030

Crypto-agilità agentica

Gli agenti propongono; controlli deterministici verificano; una persona approva. Nessuna modifica viene integrata o rilasciata da sola.

Fase 4 · 2030 → 2035

Consolidamento della piattaforma

Un solo prodotto da installare, che copre audit, migrazione e revisione.