Por qué usar NotHoly para bug bounty

Un bug bounty corre en bucle: recon, triaje, una prueba de concepto, un informe que un triador pueda reproducir. Dos cosas lo frenan. Un modelo genérico se niega a escribir la prueba de concepto para un programa que paga exactamente por eso, y cada consulta de enriquecimiento entra en una cuenta. NotHoly quita las dos. El modelo acepta el bucle, los datos de investigación no cuestan tokens, y la CLI mantiene el trabajo en tu máquina y dentro del alcance del programa. El caso de uso de bug bounty tiene la metodología; esto es sobre por qué la herramienta encaja en el bucle.

#El bucle, sin el rechazo

El modelo lee tu salida de recon y ordena lo que parece alcanzable, explica una respuesta que huele a IDOR o SSRF, y escribe la prueba de concepto para el endpoint que puedes probar. No se detiene a pesar si la petición está permitida, porque el alcance del programa ya lo respondió. Con reasoning activado, un paso de triaje recorre una cadena antes de ordenar, y el mismo modelo bosqueja la petición que prueba el siguiente salto. Para un objetivo web lee un bundle de JavaScript que pegas; para uno mobile adjuntas el APK y recibes el manifest y las strings. La base de conocimiento trae metodología de prueba de OWASP y referencias de payload con una fuente en cada pasaje, así que una técnica viene con dónde comprobarla. Como el modelo es abliterated, una prueba de concepto que funciona para un endpoint en alcance vuelve como código, no como rechazo, y la iteras en la misma conversación hasta que un triador pueda correrla.

#Quédate dentro del alcance del programa

Un programa te da un alcance y reglas, y notholy engage las convierte en un guardián. Registras los hosts y comodines en alcance y apuntas --auth a la página del programa, y cada comando que el agente corre se revisa contra ese alcance antes. Un host fuera de alcance te hace escribirlo y registra la excepción, así que un acierto accidental en un dominio hermano que no está en el programa se atrapa antes de salir de tu máquina. Las reglas viven fuera del repo, así que los archivos del propio objetivo no amplían tu alcance. El log es un log.jsonl encadenado, un registro a prueba de manipulación de lo que tocaste y cuándo, que es el registro que un programa o una disputa pide.

notholy engage init --name acme-bbp --scope "*.acme.com,api.acme.com" --auth "https://hackerone.com/acme"

#De un hallazgo a un informe

Un hallazgo se paga solo cuando un triador puede reproducirlo. Haz pipe de tus notas y la petición al modelo y pide un texto con impacto, pasos y un arreglo sugerido, en el formato que el programa quiere. La CLI lee la entrada estándar, así que un archivo de notas, un export HAR o un diff lo alimentan directo, y --json en una consulta devuelve datos estructurados que tus scripts parsean. Enriquece el informe con un lookup de CVE que lleva CVSS, EPSS y KEV, y una consulta de advisory para la dependencia que sospechas, ninguno de los dos cuesta tokens. El precio prepago por token encaja en una caza que se calienta un fin de semana y queda tranquila un mes, porque pagas el fin de semana.

cat finding.md | notholy "turn this into a reproducible report with impact, steps and a suggested fix"

#Dónde no encaja

La prueba activa es tuya. Los servidores de NotHoly nunca escanean ni envían tráfico a un objetivo, así que las peticiones al programa vienen de tus herramientas, en tu máquina. Si un hallazgo está en alcance, es válido o es duplicado es decisión del programa, no del modelo, y el modelo puede equivocarse, así que reproduce la prueba de concepto tú mismo antes de enviar. La cuenta necesita un correo, y el chat guarda tus conversaciones salvo que abras una efímera.

Mantén las peticiones en tu máquina y deja que el modelo lleve la lectura y la escritura. Instala la CLI, pon un saldo pequeño en precios, y corre un objetivo para el que ya tienes alcance.