Correzione delle vulnerabilità
Correzioni del codice con l’IA e remediation automatica, approvate da una persona
Le correzioni del codice con l’IA sono modifiche che un modello di IA propone per eliminare una vulnerabilità, di solito l’aggiornamento di una dipendenza o una piccola modifica al codice. Possono ridurre i tempi di correzione, ma ciascuna dovrebbe essere approvata da una persona, perché una correzione può alterare il comportamento, introdurre nuovi pacchetti transitivi, cambiare una licenza o semplicemente non risolvere il problema.
Piano Free, nessuna carta richiesta.
Cosa sono le correzioni del codice con l’IA e la remediation automatica delle vulnerabilità?
La remediation automatica delle vulnerabilità comprende qualsiasi strumento che trasforma una rilevazione in una modifica proposta. Per una dipendenza vulnerabile, di solito si tratta di una nuova versione nel manifest e di un lockfile rigenerato. Per una rilevazione dell’analisi del codice sorgente, è una modifica al codice, come sostituire una query costruita concatenando stringhe con una query parametrizzata. Per un errore di configurazione, è un’impostazione modificata in un Dockerfile o in un file Terraform. Oggi i modelli di IA vengono usati sia per scrivere queste modifiche sia per spiegarle.
Gli approcci differiscono soprattutto per quanto una persona vede prima che una modifica venga applicata. A un estremo, uno strumento suggerisce una correzione accanto a una rilevazione e uno sviluppatore la applica a mano. Nel mezzo, uno strumento prepara una modifica che qualcuno revisiona. All’altro estremo, le modifiche vengono unite automaticamente quando i test passano. Più un processo si avvicina al merge automatico, più dipende da test in grado di intercettare una correzione errata o incompleta.
Perché ogni correzione dovrebbe essere approvata da una persona
Una correzione proposta è una modifica al codice di produzione, scritta da qualcosa che non può eseguire il tuo prodotto negli ambienti dei tuoi clienti. Il modello può essere sicuro di sé e sbagliare, e un diff pulito può nascondere un cambiamento di comportamento. Approvare non significa rifare il lavoro; significa che una persona designata ha verificato i punti seguenti e accetta la modifica. Quella registrazione diventa anche un’evidenza, più avanti, quando dovrai dimostrare come è stata gestita una vulnerabilità.
- Modifiche incompatibili: l’aggiornamento a una nuova versione major può eliminare o cambiare le API che il tuo codice chiama.
- Aggiornamenti transitivi: una nuova versione può portare con sé nuovi pacchetti, ciascuno con le proprie vulnerabilità e i propri manutentori.
- Cambi di licenza: una nuova release può passare a una licenza che la tua organizzazione non accetta.
- Rischio di regressione: i comportamenti non coperti dai tuoi test possono cambiare senza che nessuno se ne accorga.
- Correzioni incomplete: la modifica può tralasciare un percorso del codice interessato o puntare all’intervallo di versioni sbagliato.
- Dettagli inventati: una versione o un pacchetto proposti che non esistono.
Come valutare l’aggiornamento proposto di una dipendenza
Parti dall’avviso di sicurezza, non dalla proposta. Nel formato OSV, gli intervalli delle versioni interessate di un avviso registrano dove è stata introdotta una vulnerabilità e in quale versione è stata corretta. La mossa sicura più piccola è di solito la prima release corretta sulla linea di versioni che già usi, perché cambia il meno possibile. Passare all’ultima versione major può correggere di più, ma è un aggiornamento funzionale oltre che una correzione di sicurezza e merita una revisione a sé.
Se il pacchetto vulnerabile non è tra quelli che dichiari, arriva tramite una dipendenza diretta. Aggiornare da solo il pacchetto transitivo può entrare in conflitto con ciò che si aspetta il pacchetto padre, quindi la correzione più pulita è di solito aggiornare il padre a una release che risolve il pacchetto vulnerabile in una versione corretta. Gli override del gestore di pacchetti sono un ripiego quando una release del genere non esiste ancora; registrali, così da rimuoverli quando il padre si sarà allineato.
| Verifica | Cosa controllare |
|---|---|
| Versione corretta | L’avviso di sicurezza indica come corretta la versione proposta, o una precedente sulla stessa linea. |
| Diretta o transitiva | Per un pacchetto transitivo, è stata individuata la dipendenza diretta da aggiornare. |
| Diff del lockfile | Cambiano solo i pacchetti attesi e non compaiono nuovi pacchetti inattesi. |
| Note di rilascio | Nessuna modifica incompatibile, funzionalità rimossa o cambio di licenza. |
| Test | La suite di test passa e copre il codice che usa il pacchetto. |
| Provenienza | La versione è stata pubblicata sul registro ufficiale dai manutentori abituali del pacchetto. |
Cosa dice il Cyber Resilience Act sulla correzione delle vulnerabilità
L’allegato I, parte II, del Cyber Resilience Act, il regolamento (UE) 2024/2847 sulla ciberresilienza, stabilisce i requisiti di gestione delle vulnerabilità per i fabbricanti. Il punto 2 impone loro, in relazione ai rischi posti dal prodotto, di affrontare e correggere tempestivamente le vulnerabilità, anche fornendo aggiornamenti di sicurezza, e, ove tecnicamente fattibile, di fornire i nuovi aggiornamenti di sicurezza separatamente dagli aggiornamenti della funzionalità. Questo conta quando una correzione arriva insieme a un grande salto di versione.
Il punto 8 richiede che, qualora siano disponibili aggiornamenti di sicurezza per risolvere i problemi di sicurezza individuati, questi siano diffusi tempestivamente e, salvo diversamente convenuto con un utilizzatore commerciale per un prodotto su misura, gratuitamente, accompagnati da messaggi di avviso che forniscano agli utilizzatori le informazioni pertinenti, comprese le eventuali misure da adottare. Il CRA non prescrive come debba essere scritta una correzione, da una persona o con l’IA. Questi requisiti si applicano dall’11 dicembre 2027.
Quando non correggere: registrare che una vulnerabilità non ti riguarda
Non tutte le rilevazioni richiedono una modifica al codice. Una funzione vulnerabile potrebbe non essere mai chiamata, o la funzionalità interessata potrebbe essere disattivata nella tua build. In quel caso una decisione documentata è meglio di un aggiornamento che porta con sé rischi propri. Un documento VEX (Vulnerability Exploitability eXchange) registra, per ogni vulnerabilità, se un prodotto è interessato e perché, in un formato leggibile da un dispositivo automatico che clienti e autorità possono consultare. Conserva le evidenze alla base di ogni dichiarazione «non interessato» e riesaminale quando il codice cambia.
Disponibile oggi in KROMSE
KROMSE ti dice cosa cambiare e perché; una persona del tuo team decide e applica la modifica.
- Indicazioni di aggiornamento dai dati degli avvisi di sicurezza: la versione corretta del pacchetto vulnerabile e, per un pacchetto transitivo, la dipendenza diretta che lo introduce, dove il lockfile lo dimostra. Per quel pacchetto padre non viene inventata alcuna versione.
- Un verdetto dell’IA per ogni rilevazione, entro la quota di utilizzo del tuo piano, accanto a una spiegazione in linguaggio chiaro.
- Azioni di risposta proposte dall’assistente IA, ciascuna delle quali viene approvata o rifiutata da una persona.
- Pacchetti malevoli segnalati come critici, con la rimozione come unico rimedio.
- Per i progetti Go, un’analisi delle chiamate che può mostrare se il tuo codice chiama la funzione vulnerabile.
- Esportazione VEX in CycloneDX 1.6 VEX e OpenVEX 0.2.0, e pratiche di risposta CRA con scadenze e decisioni umane registrate.
- Nulla modifica il codice: l’app GitHub ha accesso in sola lettura e KROMSE non può aprire pull request.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q4 2026 (novembre)Correzioni proposte dall’IA, approvate da una persona. KROMSE proporrà correzioni per le rilevazioni, scritte con l’IA e applicate solo dopo l’approvazione di una persona del tuo team.
- In arrivo · Q4 2026 (novembre)Plug-in per agenti di programmazione IA. Un plug-in per gli agenti di programmazione basati sull’IA verificherà ogni pacchetto proposto dall’agente prima che entri nel codice, compresi i pacchetti che non esistono o che sono stati pubblicati solo pochi giorni prima.
- In arrivo · Q4 2026 (dicembre)Monitoraggio pianificato da te, con agenti IA. Le nuove scansioni verranno eseguite secondo una pianificazione definita da te, con agenti IA che seguono i nuovi avvisi di sicurezza, valutano quali ti riguardano, propongono correzioni e preparano il report per la tua revisione.
Domande frequenti
Le correzioni del codice con l’IA si possono unire in automatico senza rischi?
Solo dove test e revisione intercetterebbero una correzione errata, e anche allora con cautela. Una modifica proposta dall’IA può rompere un’API, introdurre nuovi pacchetti transitivi, cambiare una licenza o non coprire una parte della vulnerabilità. Una persona designata che approva ogni correzione, con davanti il diff del lockfile e le note di rilascio, è l’impostazione predefinita più sicura per il codice di produzione.
Qual è la versione minima sicura per l’aggiornamento di una dipendenza?
Di solito è la prima release che l’avviso di sicurezza indica come corretta sulla linea di versioni che già usi. Elimina la vulnerabilità con il minimo cambiamento di comportamento. Un salto più ampio, soprattutto tra versioni major, può valere la pena, ma è anche un aggiornamento funzionale che richiede una revisione e dei test a sé.
Come correggo una vulnerabilità in una dipendenza transitiva?
Individua la dipendenza diretta che introduce il pacchetto vulnerabile e aggiornala a una release che risolve il pacchetto in una versione corretta. Se una release del genere non esiste, un override del gestore di pacchetti può forzare la versione corretta, ma registralo e rimuovilo quando il padre si sarà allineato, perché un override può rompere il pacchetto padre.
Il Cyber Resilience Act impone la remediation automatica?
No. L’allegato I, parte II, impone ai fabbricanti di affrontare e correggere tempestivamente le vulnerabilità in relazione ai rischi, anche tramite aggiornamenti di sicurezza, e di diffondere tempestivamente e, di regola, gratuitamente gli aggiornamenti di sicurezza disponibili. Non dice come debbano essere prodotte le correzioni. L’automazione può aiutare sulla velocità; le decisioni documentate aiutano sulle evidenze.
KROMSE applica correzioni al mio codice?
No. KROMSE spiega ogni rilevazione, fornisce indicazioni di aggiornamento dai dati degli avvisi di sicurezza e può proporre azioni di risposta che una persona approva o rifiuta. Non modifica il codice né apre pull request. Le correzioni proposte dall’IA, applicate solo dopo l’approvazione di una persona, sono nella roadmap.