Saltar al contenido
Nuevo

DeepSeek V4.1 Flash gratis por 7 días: 10M tokens al día tras una recarga de $10 o más. Hasta el 30/11.

Cómo funciona

Por qué automatizar recon y pruebas en la API de NotHoly

Pon en tu pipeline un modelo que no rechaza, con CVE, advisory y lectura de páginas públicas sin coste de tokens. Tus herramientas hacen lo activo.

Intermedio3 min de lecturaPor NotHoly

Una pasada de recon produce más de lo que puedes leer: subdominios, endpoints, cabeceras, versiones, una pared de salida de herramienta. La parte lenta es el triaje, decidir qué merece una mirada más de cerca. Un modelo en el loop ayuda ahí, pero solo si no rechaza el contexto de seguridad y si los datos de apoyo no convierten cada consulta en un cargo. La API de NotHoly da ambas cosas. Este texto trata de conectarla a tu flujo, no de método de recon; el caso de uso de bug bounty cubre el flujo en sí.

El modelo lee, tu código toca

Mantén la línea clara. El modelo razona sobre la salida que ya tienes: lee un scan, ordena lo que parece alcanzable, bosqueja el siguiente paso, escribe el parser que ibas a escribir. Los servidores de NotHoly nunca escanean, sondean ni envían un payload a un objetivo. La parte activa, la petición al host en alcance, corre en tu entorno, desde tu dirección, bajo tu control. Esa división es el punto. Tienes un modelo que discute el hallazgo sin pelear por si está permitido, y el tráfico al objetivo sigue siendo tuyo para correr y registrar. Los resultados de herramienta que devuelves se tratan como dato, no como instrucción, así que un banner hostil en un scan no dirige la ejecución. Cuando corres el paso activo en la terminal, notholy engage puede registrar el alcance y revisar cada comando contra él antes de correr, y nada de ese alcance sale de tu máquina.

Datos que no cuestan tokens

La Research API responde a las consultas que un loop de recon hace todo el tiempo, y tiene límite de tasa por organización en vez de medición por token. GET /v1/cve/{id} y GET /v1/cve/search devuelven la descripción de NVD, CVSS, CWE, puntaje EPSS y estado CISA KEV en un registro, cada fuente con fecha. POST /v1/advisories/query devuelve lo que OSV lista para un paquete y versión. GET /v1/kb/search lee una base de conocimiento curada y con licencia, con una fuente en cada pasaje. POST /v1/web/search y POST /v1/web/read buscan y leen páginas públicas por una salida que rechaza direcciones privadas e internas, fija la conexión a una IP verificada y nunca envía tráfico a un objetivo. Resultados de NVD, CISA, GitHub, PortSwigger y OWASP quedan primero, y una página puede estar mal, así que abre la fuente antes de actuar. Enriquecer un CVE o comprobar una versión no gasta tokens del modelo.

bash
curl "https://api.notholy.com/v1/cve/search?q=openssh&kev=true&min_epss=0.5" \
  -H "Authorization: Bearer $NOTHOLY_API_KEY"

Conéctala al pipeline

El endpoint del modelo es compatible con OpenAI y Anthropic, así que tu código de orquestación, tus herramientas de función y tu streaming quedan como están. Pasa al modelo tus propias herramientas, deja que las llame y córrelas tú: el servidor corre solo las funciones que envías. El reasoning y el max_tokens siguen, así que un paso de triaje puede pensar antes de ordenar. Una petición sin streaming con una Idempotency-Key puede repetirse y reejecutarse hasta 24 horas, lo que ayuda a un pipeline que vuelve a correr un paso. POST /v1/messages/count_tokens mide un prompt antes de que gastes. Function calling tiene la forma de la petición, y el ID del modelo viene del catálogo. Como las rutas de investigación no cuestan tokens, enriqueces una cola entera de hallazgos y gastas solo en el razonamiento que los ordena.

Dónde no encaja

No encaja si quieres que la plataforma corra el scan. No lo hace. No hay ejecución en el servidor ni herramienta activa, y read_url abre solo páginas públicas, no un host interno ni un enlace que encontró en una página. El modelo puede poner un falso positivo primero o perder uno real, así que una lista ordenada es una cola para revisar, no un veredicto. Las rutas de investigación tienen tope por minuto por organización, lo que sobra para un pipeline y falta para un crawler masivo. Los prompts y respuestas al modelo no se guardan, aunque los metadatos de cada llamada sí.

Deja que tus scanners escaneen y el modelo lea. Pon una clave y un saldo pequeño en precios, y apunta el paso de triaje de tu pipeline a la API.

Fuentes

  1. NotHoly, Research API
  2. NotHoly, Harness tools
  3. NotHoly, Function calling
  4. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
  5. FIRST EPSS

Más en Agentes de IA para seguridad

Agentes de IA para seguridad

Arma tu hackbot, parte 1: arquitectura

El diseño de un pequeño agente de bug bounty: un LLM, un set de herramientas, memoria y guardrails, en un loop que corre en tu máquina bajo tu aprobación.

Intermedio3 min de lectura

Agentes de IA para seguridad

Arma tu hackbot, parte 2: codea el agente

Un agente de bug bounty en Python con tool calling sobre la API de NotHoly: propone comandos de recon, espera tu aprobación, lee la salida y toma notas.

Intermedio3 min de lectura

Agentes de IA para seguridad

Arma tu hackbot, parte 3: herramientas MCP y CLI

Dale a tu agente herramientas compartidas por MCP, suma un chequeo de scope con notholy engage y corre todo desde la CLI de NotHoly o tu editor.

Intermedio3 min de lectura