El exploit llega en un día.Su pentest corre una vez al año.

HKr pone agentes sobre su superficie de ataque y dentro de cada pull request, y convierte cada hallazgo en un fix que su equipo puede integrar hoy.

Todo lo que aparece entre pentests queda abierto hasta el siguiente.

Tiempo mediano entre la divulgación y el exploit, a escala.
20211 año
20261 día

A esta escala, un día es una línea fina. Un minuto es más fino todavía.

Fuentes: Epoch.ai, vía a16z, 2026 (1 día); tendencia 2018–2024 (1 año); proyección 2027 (1 min); zerodayclock.com (86,7 %).

La defensa tiene que correr a la velocidad del atacante.

De afuera hacia adentro y de adentro hacia afuera: los agentes atacan lo que ya publicó y revisan lo que está por publicar. Cada hallazgo vuelve como un pull request — o merge request. Su equipo integra.

Caminos explotables, encontrados antes que los atacantes.

Los agentes atacan su superficie en vivo como lo haría un atacante. La evidencia queda guardada. El fix llega como un pull request.

  1. 1

    Pruebe su dominio

    Verifique la titularidad. Nada que instalar.

  2. 2

    Los agentes lo atacan

    Cada host de su superficie, probado como lo haría un atacante. La evidencia queda guardada.

  3. 3

    Un pull request lo arregla

    Listo para que su equipo revise e integre.

  4. 4

    En cada push, otra vez

    Cada cambio se vuelve a probar. Vuelta al paso 1.

app.hkr.chrom.ar/run/8f21c42:47
09:42:01recon47 hosts enumerados
09:42:04reconapi · 443, 8443 abiertos
09:42:15exploitprobando IDOR en /v2/accounts/{id}
09:42:18exploit/v2/accounts/1042 → 200 · datos de otro usuario
09:42:18findingCRÍTICO · IDOR autenticado
09:42:23exploitJWT aceptado con audiencia ajena
09:42:31evidenceevidencia registrada
09:42:47fixpull request abierto · checks en verde
09:42:00 
CríticoIDOR autenticado
AltoAudiencia del JWT no verificada
chrom-ar/payments-apifix/idor-accounts-guard+38 −4, integrable
−return this.accounts.find(id);
+if (req.user.id !== id) throw new Forbidden();
+await this.authz.assertOwner(req.user, id);

Vulnerabilidades detectadas antes del merge.

La IA escribe código a velocidad de máquina y los patrones inseguros llegan con la build en verde. Cada pull request se revisa en línea, antes del merge. La decisión de integrar sigue siendo de su equipo.

  1. 1

    Pull o merge request abierto

    Webhook. Nada que instalar.

  2. 2

    Comentarios inline

    Líneas exactas. Nuevos, heredados, resueltos.

  3. 3

    “@hkr arreglá H-1”

    Reescribe, prueba la build, abre un PR de fix.

  4. 4

    Decide su equipo

    HKr nunca integra.

github.com/acme/orders-api/pull/2814open, +24 −0
Openfeat(orders): add lookup by customer ID#2814 · 2 commits · m.acosta wants to merge into main
src/main/java/com/acme/orders/OrderRepository.java+5 −082 % generado con IA
  1. +public Order findByCustomerId(String customerId) {
  2. + return jdbc.queryForObject(
  3. + "SELECT * FROM orders WHERE customer_id = '" + customerId + "'",
  4. + orderMapper);
  5. +}
hkr-botrevisión sobre OrderRepository.java:19 · hace 38 segundos
Alto · H-1CWE-89 · Inyección SQL

Nuevo: findByCustomerId concatena el parámetro de ID del cliente directamente en el SQL. Una solicitud con ' OR '1'='1 en la ruta devuelve todas las órdenes de la tabla: enumeración completa, sin necesidad de bypass de autenticación. Sugerencia: parametrizar el filtro con ? y un argumento ligado, igual a como JdbcTemplate ya se usa en el resto del archivo.

Nunca integra
HKr propone pull requests. Su equipo decide.
Acceso mínimo
Solo los dominios que demuestre que son suyos. Permisos de solo lectura sobre el repositorio en GitHub, GitLab o Bitbucket. Sin acceso a producción.
Runners efímeros
Se destruyen después de cada ejecución.
Su evidencia
Cada paso queda grabado y guardado en su cuenta. Nada sale de su entorno.

El próximo exploit no va a esperara su próximo pentest.