Cuando un vector se cierra: pivotar de programa

01Objetivo

Reconocer con criterio objetivo (no por frustración) el momento en que insistir en un programa deja de ser rentable, y decidir hacia dónde pivotar.

02Teoría

La trampa del coste hundido en bug bounty

Haber invertido ya 20 horas en un programa no es razón para seguir invirtiendo la hora 21 si el valor esperado marginal es bajo. El sesgo de coste hundido es especialmente fuerte en bug bounty porque "casi lo tengo" es una sensación frecuente y casi siempre engañosa. El criterio de pivote debe basarse en señales objetivas, no en la sensación de cercanía.

El error contrario: pivotar demasiado pronto ("program hopping")

La trampa del coste hundido tiene un gemelo malo igual de caro: abandonar un programa a las dos horas porque "no se ve nada" y saltar al siguiente, una y otra vez, sin dar tiempo a que la superficie se revele. Es el anti-patrón que en la jerga se llama *program hopping*, y es tan improductivo como insistir sin criterio — simplemente falla en la dirección contraria.

Un objetivo con lógica de negocio real rara vez se entrega en la primera hora de recon. La regla práctica: antes de considerar un programa "mirado" lo suficiente como para evaluar si está agotado (sección siguiente), dale un mínimo de compromiso — algo así como dos semanas de calendario o 30 horas efectivas de trabajo, lo que llegue antes. Por debajo de ese umbral, "no encuentro nada" normalmente significa "no he mapeado lo suficiente", no "el programa está agotado".

Señales objetivas de que un vector/programa está "agotado"

• Los vectores de mayor prioridad identificados en el módulo 5 (autenticación, flujos de dinero, endpoints multiusuario) ya se han probado exhaustivamente contra el checklist de los módulos 7-9 sin resultado.
• El histórico de reportes públicos del programa (cuando la plataforma lo muestra) indica que las categorías obvias ya están ampliamente reportadas por otros hunters.
• El ratio de respuesta de triage se ha vuelto lento o evasivo en los últimos reportes propios, señal de que el programa puede estar despriorizando ese scope internamente.
• La superficie nueva que aparece (funcionalidades añadidas recientemente) es cada vez menor: el programa está "maduro" y ya no genera superficie fresca al ritmo de antes.

Hacia dónde pivotar: mismo scope ampliado vs. programa distinto

No todo pivote implica abandonar el programa entero:

1. Pivote dentro del mismo programa — scope ampliado recientemente, una API distinta de la ya probada (app móvil vs web), o un producto secundario bajo el mismo scope (programa de fidelidad, panel de partners) menos mirado que el producto principal.
2. Pivote a otro programa de la misma plataforma — cuando el scope completo de un programa está agotado, moverse a otro programa con arquitectura de backend distinta reinicia el valor esperado, porque la nueva superficie no comparte los mismos patrones de implementación ya descartados.
3. Pivote de categoría, no de objetivo — a veces el objetivo sigue siendo bueno, pero la categoría probada no. Si se ha agotado IDOR sobre un scope, probar lógica de negocio o JWT sobre el mismo scope puede seguir siendo rentable sin cambiar de programa.

03Caso real (anonimizado) — de e-commerce de electrónica a marketplace de moda

Tras varias semanas trabajando el programa de una cadena europea de electrónica de consumo, los vectores de mayor prioridad (autenticación, API de pedidos, panel de cliente) estaban todos cerrados sin resultado explotable, y el ritmo de superficie nueva del programa se había ralentizado notablemente. La decisión de pivote no fue "cambiar de plataforma de bug bounty", fue moverse a otro programa dentro de la misma plataforma (y del mismo grupo corporativo más amplio): un marketplace de moda online con un backend de arquitectura completamente distinta (motor OXID eShop en vez del stack del programa anterior). Esa diferencia de arquitectura es exactamente lo que reinicia el valor esperado — los mismos patrones de fallo ya descartados en el primer programa no se pueden asumir descartados en el segundo, porque el código es literalmente distinto. El nuevo foco se dirigió a un endpoint de metadatos de usuario con indicios de IDOR y a la lógica de cupones/puntos de fidelidad — ambos, señales de alta prioridad según el módulo 5 que no habían sido agotadas en el programa anterior.

04Resumen operativo

1. El coste hundido no es razón para seguir: decide por valor esperado marginal, no por horas ya invertidas.
2. Pero tampoco pivotes antes de hora: dale a cada programa un mínimo de ~2 semanas/30h antes de evaluar si está agotado — "program hopping" constante es tan improductivo como insistir sin criterio.
3. Agotar un vector no siempre significa abandonar el programa: primero valora scope ampliado o categoría distinta sobre el mismo objetivo.
4. Pivotar a un programa con arquitectura de backend distinta reinicia de verdad el valor esperado; pivotar a uno con stack similar, no tanto.
5. Documenta qué quedó "cerrado sin resultado" al pivotar — esa información vale para no repetir el mismo camino si vuelves a ese programa en el futuro.