Whack-a-mole en seguridad: por qué los founders pierden

Por qué jugar al whack-a-mole en seguridad ya no funciona

Adrian David, líder técnico en seguridad de productos, lo dice sin rodeos: optimizar por parchar bugs rápido, resolver tickets de bug bounty y mostrar una gráfica de incidentes resueltos subiendo hacia la derecha es una ilusión de victoria. Cada mole que aplastas es una oportunidad para el atacante, y el único gráfico que importa es el de clases enteras de bugs cayendo hacia cero. El ensayo original, publicado en su blog personal, recorre por qué el modelo mental dominante en seguridad, el del “hacker-detective” que encuentra hallazgos sorprendentes, está perdiendo contra la realidad operativa de producir software.

El diagnóstico importa porque llega en un momento en el que el ecosistema ya lo está confirmando con cifras. Según un reporte de Action1 recogido por BleepingComputer, las vulnerabilidades divulgadas en categorías de software empresarial analizadas crecieron 92% en 2025 frente a 2024; las críticas y de severidad alta, 103% cada una; y las que habilitan ejecución remota de código, 128%. La presión no es teórica: en paralelo, Gartner, según Help Net Security, ubica al descubrimiento de vulnerabilidades con IA como el primer riesgo emergente entre 20 amenazas evaluadas por 316 organizaciones, con 76% de los encuestados colocándolo en su top 10 y un horizonte de impacto promedio por debajo de los dos años.

Las dos tribus que se pelean el problema equivocado

David distingue dos perfiles en los equipos de seguridad:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Security as Identity: profesionales cuya carrera gira en torno al hallazgo ingenioso, el reporte impresionante, la conferencia donde se presenta un exploit inesperado. Estéticamente seductor, institucionalmente premiado (DEF CON reúne unas 25.000 personas al año, recuerda el post), pero con un sesgo peligroso: las soluciones que no parecen descubrimiento técnico tienden a ser ignoradas, aunque arreglen el problema de fondo.
Security as Robustness: gente cuya motivación principal es construir sistemas correctos que preserven sus propiedades bajo fallo, en condiciones límite y frente a un atacante. La seguridad como una propiedad emergente del buen diseño, no como una búsqueda sin fin de lo inesperado.

La trampa aparece cuando el primer grupo se convierte en el norte del equipo: el mundo se llena de detectives pero faltan mecánicos. Nadie enseña a cocinar diciéndole a alguien que piense como chef, escribe David. Y sin embargo, eso es exactamente lo que hacemos al pedir a los ingenieros de seguridad que “piensen como atacante” sin darles herramientas para rediseñar el sistema.

Bug bounty no es lo que la mayoría cree que es

Uno de los puntos más operativos del ensayo es la redefinición del rol de un programa de recompensas (VRP). Para David, un bug bounty tiene dos funciones legítimas:

Punto de contacto y parcheo: canalizar reportes válidos que la organización pueda arreglar antes de que los exploten.
Sensor estratégico del equipo de seguridad: alimenta el roadmap con datos reales sobre qué tipos de bugs aparecen, dónde, por qué y qué equipos los poseen.

Aquí está la distinción clave que David usa como test de fuego: ¿el equipo está enumerando bugs o está informandose para reducir la inseguridad a largo plazo? Si lo primero, es whack-a-mole. Si lo segundo, el VRP se convierte en una de las pocas aproximaciones al papel del “cliente” que tiene un equipo de seguridad, comparable al rol del usuario en gestión de producto.

El mercado está reaccionando a este desequilibrio en tiempo real. GitHub, según TechTimes, recortó a la mitad los pagos de su programa público de bug bounty (de US$20.000–30.000+ por crítico a US$10.000) y movió las tasas altas a un tier VIP por invitación, porque la IA abarató el costo de generar reportes creíbles sin hacerlos verificables. HackerOne reportó en mayo de 2026 un aumento de más del 100% en volumen de reportes; Bugcrowd vio crecer su cola de triage 334% en tres semanas y acuñó el término sloptimism; el creador de curl, Daniel Stenberg, cerró el programa pagado en enero de 2026 porque su tasa de vulnerabilidades confirmadas cayó por debajo del 5% — más de 19 de cada 20 reportes eran inválidos. Cuando retiró el incentivo económico y volvió al reporte no pagado en HackerOne, los reportes válidos subieron al 15–16% sobre un volumen aproximadamente doble.

Lo que SRE ya entendió (y seguridad todavía no)

David toma prestada una analogía del mundo de Site Reliability Engineering. Cuando un servicio viola repetidamente su SLO y consume el error budget, un equipo SRE bajo la definición original de Google (introducida en 2003, según InfoWorld) está facultado para detener el desarrollo de features, redirigir recursos hacia fiabilidad y desplegar arreglos sistémicos junto al equipo de producto. Una vez que el SLO vuelve dentro del budget, el trabajo de producto continúa. El objetivo de largo plazo es robustez; la resolución rápida de incidentes es secundaria.

En seguridad, ese equivalente rara vez existe. Es demasiado fácil caer en la comodidad del whack-a-mole: produce gráficos bonitos, requiere menos alineación organizacional y permite que el equipo de seguridad parezca dueño de su destino. Tomar responsabilidad real sobre los resultados de seguridad es aterrador, dice David, porque los atacantes son desconocidos. Pero jugar al whack-a-mole es perder.

La paradoja de Jevons ya está pegando en tu backlog

El ensayo anticipa un riesgo económico que el mercado empieza a confirmar. Cuando los LLMs abaratan el costo de “escanear” vulnerabilidades, pero los ingenieros de software usan agentes para escribir exponencialmente más código, el resultado no es que el problema se vuelva manejable: es que los costos del lado del defensor crecen exponencialmente (escanear un espacio que se expande) mientras los del atacante lo hacen sólo polinómicamente (encontrar un bug útil en ese espacio). El efecto Jevons — más eficiencia lleva a más consumo total, no menos — se aplica directamente al descubrimiento de vulnerabilidades con IA.

CodeRabbit, citado por InfoWorld, encontró que los pull requests asistidos por IA tienen 1,4 veces más issues críticos y 1,7 veces más issues mayores que los hechos a mano. Y un estudio reciente indica que el 41% del código global ya es generado por IA, con Gartner proyectando que el 40% del nuevo software empresarial de producción se creará con técnicas de vibe coding hacia 2028.

¿Qué significa esto para tu startup?

Para un founder técnico o un CTO, el ensayo de David sugiere tres cambios de mentalidad accionables:

Redefinir qué es “progresar” en seguridad. Si tu equipo reporta su trabajo por número de parches aplicados, bugs cerrados o tiempo medio de resolución, incentivas whack-a-mole. Cambia la métrica de norte a algo como “incidencia de esta clase de bug en los últimos 90 días”, con meta cayendo hacia cero.
Codificar invariantes, no cazar monstruos. Las vulnerabilidades son evidencia de que un invariante falta, está mal definido o no se enforce. Las invariantes pueden implementarse en tipos, interfaces, abstracciones seguras y reglas de CI tan simples como grep. Pregunta a tu equipo de seguridad qué invariantes faltan en tu sistema, no cuántos bugs encontraron esta semana.
Usar tu programa de bug bounty como sensor, no como caja de sugerencias. Si tienes VRP, úsalo para validar hipótesis de seguridad y alimentar el roadmap; si la calidad de reportes se degrada, rediseña el programa (rate limiting, verificación de identidad, tiers por reputación) en lugar de tragarte el backlog.

Acciones concretas esta semana

Audita tus métricas de seguridad. Lista las cinco métricas que reporta tu equipo de seguridad hoy. ¿Cuántas premian volumen de hallazgos vs. reducción de clases de bugs? Reescribe al menos una para medir ausencia sostenida.
Mapa de invariantes críticos. Con un ingeniero senior, identifica tres invariantes del sistema (por ejemplo, “ningún input externo llega sin validación de tipo”, “ninguna llamada a una API interna omite autenticación”). Documéntalas y añade una regla de CI que las verifique automáticamente.
Revisa tu política de bug bounty o disclosure. Si tienes VRP público, verifica que tu tasa de reportes confirmados esté sobre 10%; si está por debajo, considera tier de reputación, filtro por señal o alianza con un intermediario (HackerOne, Bugcrowd) que aplique triage con IA.

La conclusión de David es incómoda pero accionable: el rol del defensor es convertir fallos en invariantes nuevos, más amplios y más fuertes, y codificarlos para que ingenieros y agentes no tengan que redescubrir la misma clase de problemas una y otra vez. Si esa meta se siente como una pérdida, escribe David, es porque la identidad ha desplazado a la seguridad como objetivo.