Codex CLI e Security Cloud: configurazione, costi e CI

Cosa offre Codex Security dopo DevDay?

Codex Security permette al team di intercettare codice vulnerabile in tre punti: nel repository, nella pull request e nella copia di lavoro dello sviluppatore. È come avere un'ispezione dell'edificio, una verifica di un progetto di ristrutturazione e un controllo prima che un operaio lasci il cantiere. Ogni passaggio osserva una parte diversa dello stesso sistema.

Una pull request è una modifica al codice in attesa di revisione. La CLI è lo strumento a riga di comando che si esegue nel terminale; la CI è il processo di verifica automatica che parte quando il codice cambia.

Cloud approfondisce i problemi rilevati, elimina i duplicati e prepara le correzioni anche a computer spento. OpenAI lo definisce ancora una research preview, un'anteprima di ricerca. L'annuncio DevDay del 29 settembre aggiunge informazioni sulla programmazione delle scansioni e sulla disponibilità; non rende Cloud un prodotto generalmente disponibile. Riepilogo di DevDay, stato attuale del prodotto.

I team che usano GitLab dovrebbero partire dalla CLI. La configurazione attuale di Security Cloud collega GitHub. Il supporto generale di Codex alle merge request di GitLab non dimostra che Security Cloud supporti GitLab. La guida dedicata a GitLab CI/CD descrive invece un percorso supportato per eseguire i controlli di sicurezza su questo stack.

Quali piani lo includono e quanto costa per cinque persone?

Codex Security Cloud è disponibile con Pro, Business, Enterprise ed Edu, secondo l'annuncio DevDay datato e l'attuale Help Center. Security Review elenca gli stessi piani ed esclude esplicitamente Plus. Restano da abilitare i permessi del workspace e l'accesso ai repository. Disponibilità di Cloud, accesso a Security Review.

Per una piccola azienda, il confronto utile è quello su cinque licenze Standard Business:

La fatturazione a token dipende da quanto il modello legge e genera. I prezzi delle licenze possono variare in base al paese e alla valuta. I calcoli dell'abbonamento seguono le FAQ attuali di Business. Le indicazioni attuali sulla fatturazione di Cloud prevedono che i clienti esistenti ricevano un avviso e debbano aderire prima dell'avvio dell'utilizzo a pagamento; senza fondi, le scansioni si fermano. Non forniscono un preventivo complessivo per le scansioni di un team di cinque persone. Fatturazione di Cloud, differenza tra prezzi dell'abbonamento e delle API.

Se hai già Business, il costo aggiuntivo delle licenze può essere nullo. Nel budget vanno comunque inclusi i consumi di scansioni e review. Il totale mensile comprende l'abbonamento, l'eventuale utilizzo di Cloud, le scansioni CI tramite API, il tempo del runner e un eventuale abbonamento a una dashboard di sicurezza.

Non mettere a budget un nuovo primo mese gratuito. L'offerta di utilizzo gratuito era legata al lancio del 6 marzo e copriva il mese successivo. Le pagine attuali del prodotto e della fatturazione non attestano un rinnovo dell'offerta al 30 settembre. Condizioni del lancio originale, condizioni attuali di fatturazione.

Come riferimento di prezzo, Semgrep indica $30 per collaboratore al mese per il prodotto Code a pagamento, cioè $150 per cinque collaboratori. La sua Free Edition supporta anche fino a 10 repository e 10 collaboratori. Un team di cinque persone può quindi valutare entrambe le opzioni senza dare per scontato che ogni scanner esistente richieda un acquisto. La copertura è diversa: il solo confronto dei prezzi non dovrebbe decidere quali strumenti di sicurezza adottare. Prezzi di Semgrep.

Collega un repository e arriva a una correzione verificata

Parti da un'applicazione che conosci e da un revisore capace di spiegarne le regole di accesso. Un modello delle minacce è una breve descrizione di ciò che l'applicazione protegge, di chi può raggiungerla e dei punti in cui si fida di un altro sistema. È la pianta dell'edificio che indica all'ispettore quali porte dovrebbero essere chiuse a chiave.

1. Apri Plugins in ChatGPT su desktop o web. Installa e abilita Codex Security Cloud, poi apri Security Cloud.
2. Seleziona New scan. Se richiesto, collega GitHub e concedi l'accesso al repository da analizzare.
3. Scegli il repository e un Cloud environment compatibile. Se necessario, crea un ambiente con le dipendenze e la configurazione dei test richieste dal progetto.
4. In What to scan, scegli Repository, poi Start scan. Segui l'avanzamento in Scans.
5. Apri Findings. Leggi il codice interessato, le evidenze di validazione e le indicazioni per la correzione. Un tentativo di validazione fallito lascia la questione irrisolta: non scagiona la vulnerabilità.
6. Quando è disponibile Fix with Codex, genera la patch, esaminala e usa Create draft pull request dopo la verifica. Esegui i test abituali e coinvolgi il responsabile del codice prima del merge.

Questi sono i controlli attuali per configurare Cloud. L'ambiente rende più pratico riprodurre i difetti sospetti, ma non garantisce che ogni problema venga validato. Comportamento della validazione.

Per i controlli continui, crea un'altra scansione con Commit changes. In Repositories, apri Monitoring settings per selezionare l'ambiente, impostare la finestra temporale dello storico e attivare o sospendere il monitoraggio. Aggiorna il modello delle minacce in Project context quando cambia l'architettura. Cloud supporta anche scansioni programmate dei repository, come descritto a DevDay; la procedura di configurazione attuale non specifica frequenze o quote, quindi non va presunta una dotazione di scansioni giornaliere. Configurazione del monitoraggio, scansioni programmate.

Un repository realmente analizzato: come valutare i risultati su Gogs

Il caso Gogs mostra perché una segnalazione richiede il contesto del deployment prima di diventare un ticket. OpenAI cita questo repository e le vulnerabilità seguenti tra le scoperte pubblicate di Codex Security. Si tratta di un caso di scansione pubblicato dal fornitore, non di una nuova scansione eseguita per questo articolo. Le decisioni di triage riportate sotto sono raccomandazioni basate sugli avvisi di sicurezza dei manutentori. Risultati divulgati da OpenAI.

Un numero CVE identifica una vulnerabilità divulgata. L'autenticazione a due fattori, o 2FA, aggiunge un secondo controllo di accesso oltre alla password.

Il primo avviso indica correzioni nelle versioni 0.13.4 e 0.14.0+dev; il secondo indica la 0.14.0. Sono le prime versioni corrette riportate negli avvisi storici, non una raccomandazione a scegliere oggi una vecchia release. Prima di aggiornare, controlla quale release del progetto è attualmente supportata. Avviso Gogs sui codici di recupero, avviso Gogs sui caricamenti.

Mantieni essenziale il registro di triage: revisione in produzione, punto di ingresso raggiungibile, evidenze, responsabile, azione e test che verificherà la correzione. Una segnalazione può essere accettata, scartata con una motivazione concreta o lasciata aperta per ulteriori indagini. Contrassegnala come corretta solo dopo aver verificato il comportamento modificato.

Applica la stessa disciplina alla tua scansione. I report salvati dalla CLI registrano problemi rilevati e copertura. Se una scansione successiva non riporta un problema precedente, non significa che sia stato corretto; inoltre, il feedback sui falsi positivi non sopprime definitivamente quella classe di vulnerabilità. Storico delle segnalazioni e feedback.

Come attivare le review automatiche di sicurezza

Dopo la prima analisi del repository, aggiungi la review delle pull request come ulteriore livello di controllo. In Codex settings, scegli il repository. Nella sezione Review security vulnerabilities, attiva Auto security review e seleziona All PRs, oppure le preferenze personali se vuoi introdurre il controllo su adesione volontaria.

Scegli On PR open per una review iniziale, On every push per ripeterla quando il codice cambia oppure Whenever code review runs per affiancarla alla Code Review generale. Una scansione Security Cloud già esistente è facoltativa. Puoi riutilizzarne il modello delle minacce o indicare il percorso di un file con il modello nel repository. Configurazione di Security Review.

Per impostazione predefinita, le review automatiche segnalano problemi di gravità High e Critical. Quelle richieste manualmente includono anche i problemi Medium. Le due soglie si possono modificare separatamente. Per richiedere una review manuale, scrivi @codex security review in un commento sulla PR e apri il Security Report dell'attività associata per leggere tutte le evidenze. Le segnalazioni pubblicate su GitHub ereditano la visibilità della PR.

Si tratta di una review di sicurezza mirata. Anche la Code Review generale può segnalare problemi di sicurezza, quindi è normale che ci sia una certa sovrapposizione. La guida completa alle review di Codex aiuta a decidere dove inserire ciascun controllo.

Codex CLI per la sicurezza: installazione e controlli pre-commit

La CLI offre lo stesso tipo di analisi del repository in un pacchetto utilizzabile negli script. Il codice sorgente è distribuito con licenza Apache 2.0 e il pacchetto npm pubblico è @openai/codex-security. La disponibilità del sorgente non dà accesso illimitato alle scansioni. Sorgente e licenza ufficiali, prerequisiti della CLI.

L'accesso incluso al modello Daybreak Blue di Cloud resta all'interno di Cloud; non dà accesso al modello attraverso altri prodotti Security o tramite API. Prima di spostare una scansione nella CI, verifica il metodo di autenticazione previsto e l'accesso al modello. Limiti di accesso tra i prodotti.

Le date vanno distinte: il repository GitHub è stato creato il 13 luglio 2026; lo storico pubblico attuale parte da un commit di inizializzazione del 15 luglio, mentre le pubblicazioni su npm iniziano il 28 luglio. La sola data del 13 luglio non dimostra che la CLI npm con quella licenza fosse già disponibile quel giorno. Per una configurazione riproducibile, fissa la versione del pacchetto. Metadati del repository, commit iniziale, storico delle pubblicazioni npm.

Usa Node.js 22.13.0 o successivo nella serie 22, Node 24 oppure Node 26, insieme a Python 3.10 o successivo. Dal repository, effettua l'accesso e salva l'output al di fuori della copia di lavoro:

npx @openai/codex-security@0.1.31 login
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results --dry-run
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results

Esamina report.md, findings.json e coverage.json. La copertura può essere completa, parziale o sconosciuta; leggi le aree rinviate e le domande aperte anche quando non viene segnalato alcun problema. Questi comandi seguono la guida rapida della CLI.

Installa il controllo pre-commit con npx @openai/codex-security@0.1.31 install-hook. Analizza le modifiche sia nell'area di staging sia fuori da essa, blocca per impostazione predefinita i problemi High e gli errori di scansione e conserva un eventuale script pre-commit già presente. Poiché vede entrambi i tipi di modifiche, tieni gli esperimenti estranei fuori dalla copia di lavoro quando interpreti il risultato. Comportamento dell'hook.

La versione del pacchetto e i comandi riportati sopra sono stati verificati durante la preparazione di questo articolo. Non viene dichiarata alcuna scansione locale autenticata, né una durata misurata o un costo di scansione.

Esegui la CLI in CI e conserva il SARIF

SARIF è un formato standard per i risultati delle analisi di sicurezza: permette a un altro strumento di mostrare ogni problema accanto alla posizione corrispondente nel sorgente. Esportare il file e acquistare una dashboard ospitata sono due decisioni separate.

Crea un secret CI chiamato CODEX_SECURITY_API_KEY per un account o un'organizzazione API con l'accesso richiesto alle scansioni. La chiave consente al runner di autenticarsi senza un accesso interattivo a ChatGPT. Questo esempio GitHub Actions analizza PR attendibili provenienti dallo stesso repository, ne confronta esattamente base e head, esporta SARIF e conserva i risultati. Adatta il template CI ufficiale, fissa la versione del pacchetto verificata per questo articolo e parte con una soglia di blocco alla gravità High. Per un'introduzione solo informativa, rimuovi --fail-on-severity high; gli errori di scansione e la copertura incompleta richiedono comunque attenzione.

Salvalo come .github/workflows/codex-security.yml:

name: Codex Security
on:
  pull_request:
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020
        with:
          node-version: '26'
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
        with:
          python-version: '3.14'
      - name: Install trusted CLI outside the checkout
        run: npm install --prefix "$RUNNER_TEMP/security-cli" --ignore-scripts --no-audit --no-fund @openai/codex-security@0.1.31
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - name: Scan and export
        env:
          OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
          CODEX_SECURITY_STATE_DIR: ${{ runner.temp }}/security-state
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          set -euo pipefail
          cli="$RUNNER_TEMP/security-cli/node_modules/.bin/codex-security"
          out="$RUNNER_TEMP/security-results"
          base="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
          scan_exit=0
          "$cli" scan . --diff "$base" --head "$HEAD_SHA" \
            --auth api-key --output-dir "$out" \
            --fail-on-severity high --json \
            > "$RUNNER_TEMP/security-result.json" || scan_exit=$?
          if test -f "$out/scan-manifest.json"; then
            "$cli" export "$out" --export-format sarif \
              --source-root "$GITHUB_WORKSPACE" \
              --output "$out/results.sarif"
          fi
          exit "$scan_exit"
      - name: Keep reports, including SARIF when available
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
        with:
          name: codex-security-results
          path: |
            ${{ runner.temp }}/security-results
            ${{ runner.temp }}/security-result.json
          retention-days: 7

Il workflow conserva il codice di uscita della scansione mentre esporta i risultati consolidati disponibili. Exit 0 indica che l'ambito selezionato ha copertura completa e rispetta la policy sulle gravità. Exit 1 indica che un problema raggiunge la soglia impostata. Exit 2 indica un errore o una copertura incompleta, compresa quella parziale o sconosciuta. Una scansione informativa che passa resta un report sull'ambito selezionato, non una certificazione di sicurezza. Esportazione degli artefatti e codici di uscita.

Per visualizzare SARIF come avvisi di code scanning su GitHub, aggiungi il passaggio upload-sarif del template ufficiale e i relativi permessi. I repository pubblici sono supportati; quelli privati e interni richiedono GitHub Code Security abilitato. Conservare SARIF come artefatto, come nell'esempio sopra, permette di esaminarlo senza promettere una dashboard gratuita per repository privati. Requisiti di GitHub per SARIF.

Per GitLab, usa il template CI/CD di produzione di OpenAI, che copre i diff delle merge request, le scansioni sul branch predefinito protetto e le scansioni programmate su adesione esplicita. L'acquisizione nativa dei file SARIF richiede GitLab Ultimate 19.2 o successivo. Se manca l'accesso a quella dashboard, i normali artefatti dei report restano un percorso separato.

Le esecuzioni CI usano i permessi del runner e possono ereditarne l'ambiente. Tieni fuori dal job le credenziali estranee e usa modifiche al sorgente attendibili. Dopo aver scelto un budget, aggiungi un valore --max-cost: è un limite stimato, che può essere superato dalle richieste già in corso. Prerequisiti CI, controlli sui costi.

Cinque impieghi da provare, in ordine di beneficio

1. Un team SaaS che modifica il login o l'accesso ai tenant. Esegui la scansione iniziale, migliora il modello delle minacce e abilita Security Review sulle relative PR. Il beneficio è una maggiore probabilità di intercettare un errore nei confini tra account prima che lo incontrino i clienti. Coinvolgi il responsabile dell'autenticazione nella review.
2. Un fondatore che eredita un'applicazione datata. Analizza il repository una volta e assegna le segnalazioni accettate prima di aggiungere funzionalità. Un backlog sconosciuto può così diventare un elenco breve di interventi sostenuti da evidenze, anziché una richiesta generica di riscrivere tutto.
3. Un team GitLab senza uno scanner di sicurezza gestito. Esegui i controlli CLI sui diff delle merge request e conserva SARIF e copertura come artefatti. Il beneficio è una traccia di review ripetibile all'interno del sistema CI che il team gestisce già.
4. Un'agenzia che mantiene più repository di clienti. Usa le scansioni in blocco riprendibili della CLI, un contesto architetturale distinto e uno storico delle segnalazioni per ogni cliente. Questo potrebbe ridurre le configurazioni ripetute e rendere più preciso il passaggio di consegne della manutenzione. Scansioni in blocco.
5. Un team con un backlog di sicurezza pieno di segnalazioni poco utili. Usa il workflow di triage del backlog di Codex Security per esaminare i risultati degli scanner alla luce del codice e dei controlli attuali. Il beneficio è avere evidenze su quali ticket meritino tempo di sviluppo. Mantieni attivi gli scanner originali. Triage del backlog.

Due servizi che potresti costruire attorno a Codex Security

L'opportunità più solida è introdurre e mantenere i controlli di sicurezza per piccoli team. Un fondatore paga per la configurazione, il lavoro sul modello delle minacce, l'integrazione CI e il triage umano periodico, più che per l'ennesima interfaccia attorno a un pulsante di scansione.

In questa esecuzione, le stime DataForSEO per Google negli Stati Uniti hanno restituito 720 ricerche mensili per “software vulnerability scanning” e 90 per “code security scanner”. Sono ricerche, non clienti paganti; inoltre, la frase più ampia comprende anche attività estranee alla scansione dei repository. Il prezzo di Semgrep Code, $150 al mese per cinque collaboratori, offre un riferimento concreto per un servizio dal perimetro ben definito. Riferimento di prezzo Semgrep.

La versione minima vendibile potrebbe comprendere un repository di proprietà del cliente, un modello delle minacce documentato, il workflow CI e una coda di segnalazioni già esaminate. Usa gli accessi del cliente e rendi visibili i costi di utilizzo. La difficoltà è operativa: devi conoscere l'applicazione abbastanza da scartare segnalazioni fuorvianti e valutare correzioni delicate. Vendere una garanzia di sicurezza andrebbe oltre quanto dimostrano le evidenze.

Una seconda opportunità è un dossier di evidenze di rilascio per le agenzie. Un'agenzia potrebbe offrire, a ogni passaggio di consegne al cliente, una documentazione datata del perimetro della scansione, delle segnalazioni accettate, delle lacune residue e delle correzioni verificate. La query generica “vulnerability scanning tools” ha una stima di 1,900 ricerche mensili negli Stati Uniti, ma misura l'interesse per strumenti di diversi ambiti della sicurezza. Sostiene un'ipotesi da verificare con potenziali clienti, non la domanda per questo prodotto specifico.

L'MVP potrebbe riunire gli artefatti di scansione salvati e il triage approvato in un report sintetico per il cliente. La difficoltà sta nella portabilità e nella fiducia: SARIF può essere trasferito, ma il valore del servizio nasce da un'interpretazione onesta, anche della copertura incompleta. Un semplice report generato è facile da copiare. Tutti i dati sulle ricerche sono stime mensili delle parole chiave DataForSEO raccolte il 30 settembre 2026; nessuno dimostra un mercato in crescita o un'intenzione di acquisto.

Quali controlli non sostituisce?

Mantieni la scansione delle dipendenze, che controlla i pacchetti e le versioni importati dall'applicazione, e la ricerca di segreti, che rileva credenziali esposte. L'analisi del repository può approfondire un problema collegato, ma non costituisce un inventario completo dei pacchetti né un sistema di monitoraggio delle credenziali.

Mantieni i controlli SAST deterministici quando contano le loro verifiche ampie e ripetibili o i tuoi requisiti di assurance. OpenAI afferma esplicitamente che Codex Security integra il SAST. Puoi provare l'agente senza acquistare una suite a pagamento; questo non rende superflua la copertura esistente. FAQ di Cloud.

Mantieni una revisione umana sul codice di autorizzazione. L'autenticazione stabilisce chi sei; l'autorizzazione stabilisce a quali dati di un cliente puoi accedere o quali azioni puoi compiere. Queste regole dipendono dalle finalità del prodotto e da ipotesi sul deployment che uno scanner può fraintendere. Chiedi al responsabile di verificare i confini tra tenant, i permessi amministrativi, i flussi di recupero e i test di regressione. È una raccomandazione ingegneristica coerente con la necessità di una valutazione umana delle minacce dichiarata dal fornitore.

Mantieni anche limiti chiari per l'ambiente di scansione. Cloud usa container isolati; le scansioni locali e CI usano i permessi locali. La guida alla sicurezza delle sandbox affronta il compito distinto di controllare a quali risorse può accedere un agente.

Codex o la security review di Claude Code?

Continua con Claude Code se l'esigenza immediata è un controllo di sicurezza sulle modifiche in attesa e il team lo usa già. Esegui /security-review in locale oppure configura la GitHub Action di Anthropic per le security review, con commenti sulle PR e filtraggio dei falsi positivi. Queste funzionalità sono disponibili agli utenti di Claude Code, compresi gli account Pro/Max a pagamento e API Console. Configurazione delle security review di Claude.

Scegli Codex Security Cloud se cerchi un workflow con analisi iniziale gestita del repository, monitoraggio dei commit, scansioni programmate e correzioni preparate. Scegli la sua CLI se lo storico salvato delle segnalazioni, gli artefatti di copertura e le esportazioni SARIF si adattano al tuo processo locale o CI. Questo confronto non stabilisce un vincitore per accuratezza o costi.

Controlla la policy di filtraggio in entrambi gli stack. La Action di Anthropic per le security review documenta esclusioni che comprendono denial of service ed esaurimento delle risorse: un problema di esaurimento del disco come quello dei caricamenti Gogs richiede quindi una verifica mirata di quella policy. La Action è un'offerta distinta dal prodotto Code Review ospitato di Claude. Repository delle security review di Anthropic.

Lunedì, assegna un responsabile a un repository. Esegui la scansione iniziale, correggi il modello delle minacce, valuta le prime segnalazioni e aggiungi controlli CI informativi prima di scegliere una soglia di gravità che blocchi le modifiche. Registra il costo di utilizzo e le lacune di copertura ancora aperte prima di passare a un altro repository.

Se vuoi integrare questi controlli nel processo di sviluppo del tuo team, sviluppo sistemi AI per la produzione.