Perché l'estensione VS Code di NotHoly per la review

Fare la review del codice per la sicurezza in un assistente generico va in due modi, entrambi cattivi. Tentenna quando gli chiedi di trovare il bug sfruttabile o di scrivere la prova che il bug è reale, oppure incolli una funzione in una chat e perdi gli import, il chiamante e il resto del file che decidono se il bug è raggiungibile. L'estensione di NotHoly fa la review del file e del diff dove vivono, in VS Code, Cursor, Windsurf o VSCodium, e il modello dietro accetta la domanda di sicurezza. Il caso d'uso di review del codice ha il flusso; qui si parla dell'estensione.

#Review del file o del diff

Apri un file ed esegui Review this file. L'agente lo legge, con qualsiasi modifica non salvata, ed elenca ciò che ha trovato nel pannello Problems, ogni voce un punto a cui saltare. Review changes manda il tuo git diff, le modifiche non in stage o quelle in stage quando non c'è nulla fuori stage, così una pull request ottiene un passaggio di sicurezza prima di lasciare il tuo branch. Explain selection prende un blocco che evidenzi, e Investigate a CVE recupera il record e lo spiega nella chat. Il modello non si ferma a discutere se leggere in cerca di una vulnerabilità è permesso, perché quello è il lavoro di chi fa la review. Il riferimento dei comandi li elenca tutti. Il selettore dei modelli elenca il catalogo con il prezzo di ogni modello, e quando una promozione ne rende uno gratis per il tuo account mostra un tag free con il prezzo di listino barrato. Ogni risposta mostra i conteggi dei token, e le ultime trenta conversazioni restano su questa macchina in History.

#Da un reperto a un test e una regola

Un reperto è più utile quando lascia qualcosa dietro. Write a regression test for the selection chiede all'agente un test che prenderebbe il bug di sicurezza nel codice che hai scelto, così la correzione resta corretta. Write a detection rule for the selection restituisce una regola Sigma, Semgrep o YARA per il pattern, così lo stesso errore viene preso altrove. Apply suggested fix apre la modifica come un diff con Accept e Reject, e un turno che ha scritto file finisce con Undo changes, che rimette ciò che ha scritto. Leggi ogni modifica e ogni comando su una scheda prima che parta. Un blocco shell nella chat porta Run in terminal, che mette il comando nel tuo prompt e lascia l'Enter a te, così nulla parte di sorpresa, e gli allegati funzionano solo in un workspace attendibile.

#Resta nel tuo editor, con delle guardie

L'estensione rispetta il Workspace Trust. In una cartella non attendibile l'agente non ha strumenti e risponde solo in testo, quindi non legge file né esegue comandi finché non ti fidi della cartella. Leggere o scrivere fuori dal workspace chiede prima, e percorsi di credenziali come .env, .ssh e .aws ti fanno ridigitare il nome del file, mentre grep li salta. Dopo che un file fuori dal workspace o una credenziale è stata letta, una ricerca web o nella base di conoscenza mostra la query prima che lasci la tua macchina. Un comando che approvi gira nella tua shell, nella cartella del workspace, con i tuoi permessi e senza la tua chiave NotHoly nell'ambiente. La chiave stessa sta nell'archivio segreti dell'editor, e per la CI la imposti nell'ambiente.

code --install-extension notholy-vscode-latest.vsix

#Dove non si adatta

Non è un analizzatore statico. Il modello può perdere un bug reale e segnalarne uno che non c'è, quindi una review pulita non è una garanzia e un reperto è una traccia da confermare. Zero Questions esegue modifiche e comandi senza chiedere e può svuotare il saldo, quindi è per un sandbox, non per un repo di cliente. In un workspace non attendibile gli strumenti di review sono spenti di proposito, e i tre editor che non sono VS Code non sono testati dalla nostra parte. L'estensione ha bisogno di un login, quindi è legata a un account e a una e-mail, e il modello può sbagliare come qualsiasi modello.

Tieni la review nell'editor, accanto al codice che gli dà il contesto. Installa dalla pagina dell'estensione, poi ricarica su prezzi.