Encontrar vulnerabilidades es la mitad del trabajo. Conseguir que se arreglen es la otra mitad.
La experiencia técnica importa. Obviamente. Pero si quieres tener un impacto real, necesitas conocer a tu público y hablar su idioma.
A menos que trabajes en un puesto puramente técnico sin comunicación con el negocio, esto se aplica a ti.
Te lo explico:
Los reportes de bug bounty van a triagers que tienen conocimientos técnicos. Bueno, la mayor parte del tiempo. Puedes profundizar en los detalles técnicos. Mostrar tu PoC. Explicar el payload. Referenciar CVEs. Lo entienden.
Los reportes de pentesting a menudo van al negocio. Gestores de IT, desarrolladores, a veces incluso ejecutivos. No les importa tu elegante payload SQL. Les importa qué se rompe y cuál es el riesgo para el negocio.
Aquí está la diferencia en la práctica.
Para la misma vulnerabilidad, puedes escribir:
"Esta es una inyección SQL que un atacante puede usar para inyectar consultas SQL."
O puedes escribir:
"La aplicación web contiene una vulnerabilidad de inyección SQL que permite a un actor malicioso acceder a la base de datos, comprometiendo potencialmente los datos de clientes y violando el cumplimiento GDPR."
Misma vulnerabilidad. Diferente lenguaje. Una se ignora. La otra se prioriza.
Lo aprendí por las malas. Al principio de mi carrera, escribía reportes técnicamente perfectos que no iban a ninguna parte. Cadenas de explotación detalladas. Pasos de reproducción limpios. Todo lo que un investigador querría ver.
Se quedaban en el backlog durante meses.
Luego empecé a traducir los hallazgos técnicos en impacto de negocio. Brecha de datos. Multas regulatorias. Daño reputacional. De repente, las cosas se arreglaban.
Tu trabajo no es solo encontrar bugs. Es hacer que la gente entienda por qué deberían importarles.
Cuando escribes para triagers en programas de bug bounty, ve a lo técnico. Necesitan entender el exploit, validar tus hallazgos y evaluar la severidad basándose en el vector de ataque. Dales los detalles que necesitan.
Cuando escribes para stakeholders de negocio en trabajos de pentesting, ve a lo estratégico. Necesitan entender el riesgo, el daño potencial y por qué esto importa para la empresa. Dales el contexto que necesitan para tomar decisiones.
Los mejores pentesters no son solo técnicamente hábiles. Son traductores. Transforman problemas de seguridad complejos en decisiones de negocio.
Esto no va de simplificar las cosas. Va de enmarcar el impacto en términos que a tu público le importen. A los equipos técnicos les importan las técnicas de explotación. A los equipos de negocio les importan las consecuencias.
Ambos son válidos. Ambos importan. Necesitas saber cuál usar y cuándo.
He visto a investigadores brillantes tener problemas porque no podían comunicar el impacto de forma eficaz. Encontraban vulnerabilidades críticas que nunca se arreglaban porque sus reportes no calaban en la gente que controlaba el presupuesto.
Por otro lado, he visto hallazgos medianos recibir atención inmediata porque se enmarcaban en términos de riesgo de negocio. El investigador entendía quién estaba leyendo el reporte y qué necesitaban escuchar.
Esa es la habilidad que separa a los buenos investigadores de los efectivos.
Conoce a tu público. Habla su idioma. Consigue que se arreglen las cosas.
