• Business
• Sviluppo

OpenAI ha pubblicato Codex Security CLI come progetto open source: si tratta di uno strumento da riga di comando (CLI sta appunto per command-line interface) pensato per cercare vulnerabilità nei repository software, verificare se i problemi segnalati risultano realmente sfruttabili, controllare le correzioni e introdurre verifiche automatiche nei processi di sviluppo. Il rilascio ha avuto una partenza insolita: l’azienda non lo ha ancora annunciato ufficialmente ma alcuni utenti hanno già individuato e segnalato il repository pubblico su GitHub.

La novità arriva dopo anni nei quali l’analisi statica del codice di programmazione ha rappresentato il principale meccanismo automatizzato per intercettare errori di sicurezza. I tradizionali strumenti cercano pattern noti, chiamate pericolose, flussi di dati sospetti e violazioni di regole predefinite: funzionano bene sui casi riconoscibili, ma producono spesso falsi positivi e possono “mancare” vulnerabilità che emergono soltanto collegando più componenti, configurazioni e passaggi applicativi.

Codex Security prova a spostare il baricentro: non si limita a confrontare il codice con un insieme fisso di firme, ma tenta di “ragionare” sul funzionamento dell’applicazione, sulle superfici esposte e sui percorsi che un aggressore potrebbe sfruttare.

OpenAI presenta il prodotto come un assistente per i gruppi di sicurezza e sviluppo, non come un sostituto della revisione umana.

Che cos’è Codex Security CLI e perché il rilascio è importante

Il repository GitHub contiene una CLI e un SDK TypeScript distribuiti sotto licenza Apache 2.0. Gli sviluppatori possono quindi esaminare il codice del client, proporre modifiche, integrarlo nei propri strumenti e creare automazioni senza dipendere esclusivamente da un’interfaccia grafica.

Va però chiarito un punto: open source non significa che l’intero servizio funzioni offline o che i modelli sottostanti siano liberamente eseguibili. Il programma installato sul computer coordina la scansione, prepara gli input, conserva gli artefatti e interagisce con Codex Security; per eseguire le analisi servono credenziali valide e l’accesso alla funzionalità.

La disponibilità del codice sorgente ha un valore concreto soprattutto per chi deve introdurre uno scanner nei processi aziendali. Un responsabile della sicurezza può controllare il comportamento del client, capire dove finiscono i risultati, analizzare il formato dei file prodotti e verificare come la CLI gestisce autenticazione, errori ed exit code.

Requisiti, installazione e primo avvio

Codex Security CLI richiede Node.js 22 o una versione successiva. Per eseguire una scansione o esportare i risultati serve anche Python 3.10 o più recente. L’installazione indicata nel repository passa dal pacchetto npm ufficiale:

npm install @openai/codex-security

Dopo l’installazione, l’autenticazione interattiva si avvia con il comando npx codex-security login. Su un server privo di interfaccia grafica si può usare la modalità device authentication tramite l’opzione --device-auth. Nei job automatici, invece, OpenAI suggerisce di impostare la variabile d’ambiente OPENAI_API_KEY.

Se sul computer sono disponibili sia l’accesso ChatGPT sia una chiave API, la CLI interattiva chiede quale credenziale usare: è anche possibile imporre la scelta con --auth chatgpt oppure --auth api-key.

Il comando più semplice per analizzare la directory corrente è:

npx codex-security scan .

Prima di avviare una scansione reale conviene usare --dry-run: la modalità controlla percorsi, directory di destinazione e parametri senza avviare Codex, caricare le credenziali o interrogare l’interprete Python. Così permette di scoprire subito errori banali, come un percorso sbagliato o una cartella di output non scrivibile.

Come lavora la scansione e quali file produce

Una scansione standard esamina il repository indicato e restituisce un rapporto con vulnerabilità, gravità, attendibilità, posizione nel codice, dettagli tecnici e possibili rimedi.

• report.md offre una versione leggibile del risultato;
• findings.json contiene i rilievi con indicazione di gravità, stima della precisione del rilevamento, riferimenti ai file e indicazioni per la correzione del problema;
• scan-manifest.json descrive il bersaglio, l’ambito, il produttore del rapporto e gli artefatti associati;
• coverage.json registra le aree esaminate, quelle escluse, le verifiche rinviate e le domande rimaste aperte.

La presenza di una misura esplicita della copertura della scansione merita attenzione. Il valore può risultare “complete“, “partial” oppure “unknown“: uno scanner che segnala zero vulnerabilità ma ammette di aver analizzato soltanto una parte del repository non fornisce la stessa garanzia di una revisione completa. Eppure, molti sistemi di controllo mostrano il numero dei problemi senza spiegare con sufficiente chiarezza cosa non hanno controllato.

Scansioni complete, modifiche Git e modalità deep

La CLI non obbliga a riesaminare ogni volta l’intero progetto: attraverso l’opzione --path si possono selezionare servizi o pacchetti specifici, una funzione utile nei repository che raccolgono decine di applicazioni indipendenti. Un team potrebbe, per esempio, concentrarsi sul servizio di autenticazione o sul modulo che gestisce i pagamenti.

Con --diff e --head Codex Security confronta due revisioni Git; per analisi più ampie esiste la modalità deep scan, richiamabile con --mode deep.

OpenAI propone quest’ultima per repository o sezioni che richiedono un esame più approfondito: può aumentare il lavoro svolto, la durata e il costo associato alle richieste trasmesse ai modelli.

La CLI accetta inoltre documenti di architettura, modelli delle minacce e policy aziendali tramite l’opzione --knowledge-base.