Strumenti di sicurezza
Il toolkit del bug bounty e la NotHoly CLI
Un toolkit di bug bounty per chi inizia, più la NotHoly CLI nel terminale con lo scope registrato così i comandi restano dentro il programma.
L'agente gira sulla tua macchina con la tua approvazione, il modello accetta il lavoro di sicurezza, e un engagement controlla ogni comando.
Un assistente da terminale che rifiuta di leggere un disassembly o abbozzare un payload serve a poco per il lavoro di sicurezza. Uno che esegue i tuoi comandi sul proprio server è peggio, perché il traffico al tuo bersaglio esce da un indirizzo che nessuno ha messo nello scope. La CLI di NotHoly non fa nessuna delle due. Gira sulla tua macchina, agisce solo con la tua approvazione, e il modello dietro accetta il lavoro invece di farti la ramanzina. La metodologia è nel caso d'uso di pentest; qui si parla dello strumento.
notholy apre un agente nel tuo progetto. Legge e cerca file, li modifica e li scrive, esegue un comando, e raggiunge il lookup CVE, la base di conoscenza e la ricerca web. Ogni comando e ogni scrittura girano sulla tua macchina, sotto il tuo utente, e la modalità di default chiede prima di ognuna. La modalità plan è di sola lettura, auto-edit scrive senza chiedere ma chiede ancora per eseguire un comando, e yolo non chiede nulla e va impostato a ogni esecuzione. I server di NotHoly non eseguono mai nulla contro i tuoi bersagli. Le note del progetto vanno in NOTHOLY.md, e il contenuto dei file e l'output dei comandi sono trattati come dato, mai come istruzione all'agente, così un README piazzato non può dirottarlo. Gli slash command cambiano il modello, la modalità e lo sforzo di reasoning a metà sessione, /cost mostra quanto ha speso l'esecuzione, e le sessioni stanno in ~/.notholy/sessions con permesso solo al proprietario.
notholy engage registra cosa un test può toccare e controlla ogni comando contro quello prima che parta. Gli dai un nome, uno scope di host, wildcard, IP e CIDR, un riferimento alla tua autorizzazione, e una finestra temporale. Un comando nello scope passa dall'approvazione normale. Un bersaglio fuori scope ti fa digitare l'host e registra l'eccezione, e yolo è spento finché un engagement è attivo. Ogni decisione va in un log.jsonl con il comando, i bersagli, il codice di uscita e un hash dell'output, ogni riga concatenata alla precedente, così il registro è a prova di manomissione. Le regole stanno fuori dal repo, così un repository non piazza il proprio scope. La doc dell'agente da terminale ha i flag.
notholy engage init --name acme-q4 --scope "*.acme-staging.test,10.20.0.0/24" --auth "contract 2026-117"Per una risposta singola, notholy "..." legge lo standard input, così gli strumenti che già usi possono alimentarlo.
git diff | notholy "review this diff for injection bugs"notholy connect e notholy run puntano Claude Code, Codex o OpenCode ai modelli di NotHoly e registrano un server MCP locale con gli strumenti di CVE, advisory e base di conoscenza, così un agente che già usi guadagna quei dati senza una chiave nella sua configurazione. connect fa prima un backup della config dello strumento e --undo la ripristina, e la chiave resta nel login della CLI stessa invece che nel file dello strumento. Una sessione lunga viene compattata prima di passare la dimensione di contesto del modello, con un riassunto che tiene l'obiettivo, le decisioni e i reperti.
Il guardiano dell'engagement legge il testo di un comando e non risolve il DNS, quindi coglie un errore, non un aggiramento deciso. Non è un sandbox, e un comando può ancora raggiungere un host che non nomina. yolo esegue tutto senza chiedere e può cambiare file ed eseguire comandi che non hai letto, quindi tienilo per una cartella di prova. Un comando che approvi gira con i tuoi permessi, quindi leggi la scheda prima di permettere. La CLI ha bisogno di un login, quindi è legata a un account e a una e-mail. Il modello può sbagliare come qualsiasi modello, e l'output è una bozza da controllare, non un risultato da fidarsene. Non sostituisce nemmeno i giudizi: lo scope, l'autorizzazione e la decisione di eseguire sono tuoi.
Tieni i comandi, i file e il rischio sulla tua macchina, e lascia che il modello legga. Installa la CLI, poi ricarica un saldo piccolo su prezzi.
Strumenti di sicurezza
Un toolkit di bug bounty per chi inizia, più la NotHoly CLI nel terminale con lo scope registrato così i comandi restano dentro il programma.
Strumenti di sicurezza
Review del file o del git diff nel tuo editor, con tutto il contesto. Il modello accetta la domanda di sicurezza e crea da un reperto un test o una regola.
Strumenti di sicurezza
Nmap mappa le porte aperte sulla tua macchina. Impara connect scan e SYN scan, rilevamento dei servizi e file di output, poi abbina ogni porta al suo processo.