Cuando la responsabilidad es unilateral: el dilema de la divulgación coordinada
Una reflexión sobre el modelo actual de seguridad, sus asimetrías y sus consecuencias
Imagina la siguiente situación:
Has pasado semanas, quizás meses, investigando un comportamiento extraño en un sistema ampliamente utilizado. Has reproducido el problema en diferentes dispositivos. Has capturado logs, stacktraces, métricas de sistema. Has documentado cada paso con precisión. Has preparado un informe que cualquier ingeniero podría seguir para verificar el problema por sí mismo.
Envías el reporte al fabricante. Esperas. Recibes una respuesta automática. Semanas después, alguien te pide más información. La proporcionas. Vuelves a esperar.
Finalmente, recibes una respuesta:
“Hemos revisado tu informe y determinado que no cumple con los criterios para ser considerado un bug de seguridad.”
“Este problema pertenece a otro equipo.”
“Está fuera del alcance de nuestro programa de recompensas.”
“Por favor, utiliza el feedback in-product para reportarlo.”
El problema sigue existiendo. Los usuarios siguen expuestos. Pero la responsabilidad ha quedado diluida en un laberinto de equipos, programas y criterios.
Esta historia es más común de lo que muchos creen. Y revela una asimetría estructural en el modelo de divulgación coordinada que merece un análisis profundo.
Este artículo no trata sobre una vulnerabilidad concreta. Trata sobre el sistema que la gestiona o, más precisamente, sobre el sistema que a menudo no la gestiona.
1. El contrato implícito de la divulgación responsable
La divulgación responsable, también llamada coordinada, se ha establecido como el estándar ético en la seguridad informática. Su premisa es sencilla y, en apariencia, incuestionable:
“Si conocemos un problema que puede afectar a otros, debemos dar al fabricante la oportunidad de solucionarlo antes de hacerlo público.”
Esta lógica protege a los usuarios. Permite que las empresas corrijan vulnerabilidades sin exponer a sus clientes a ataques mientras el parche está en desarrollo. Es un modelo que, en teoría, beneficia a todas las partes.
En la práctica, el investigador acepta un conjunto de obligaciones que incluyen:
- Reproducir el problema de forma fiable y documentada.
- Proporcionar evidencia técnica suficiente (logs, trazas, código, pasos).
- Evitar divulgar prematuramente para no poner en riesgo a los usuarios.
- Informar al fabricante a través de los canales establecidos.
- Facilitar la investigación con información adicional cuando se solicita.
- Respetar los plazos de coordinación que la empresa propone.
- Permitir que el proveedor prepare una solución antes de la publicación.
- Documentar sus conclusiones de forma responsable y precisa.
Y, en muchos casos, el investigador hace todo esto sin ninguna garantía de reconocimiento, parche o recompensa. Lo hace porque cree en el modelo. Porque entiende que la seguridad es una responsabilidad compartida.
La lógica es impecable. Pero esa misma lógica debería funcionar en ambas direcciones.
2. El problema aparece cuando nadie es responsable y a la vez, lo son todas las partes inplicadas
Durante una investigación pueden aparecer problemas que atraviesan diferentes capas de un sistema. Un mismo comportamiento puede involucrar:
- Aplicación (el software que el usuario ve)
- Framework (la capa intermedia que soporta la aplicación)
- Biblioteca nativa (código de bajo nivel, a menudo en C/C++)
- Sistema operativo (el núcleo del sistema)
- Fabricante / OEM (personalizaciones del sistema)
Y también:
- Producto A (ej. Chrome, Firefox, Edge)
- Producto B (ej. Android)
- Componente compartido (ej. libminikin)
- Infraestructura común (ej. Binder, IPC)
- Servicio en la nube (ej. Llm's API)
Entonces aparece el fenómeno conocido por muchos investigadores:
“No es nuestro problema.”
Un equipo o vendor, puede indicar: “Esto es un problema de Android.”
Android puede responder: “No está dentro del alcance de nuestro programa.”
Otro equipo puede añadir: “Debe reportarse al producto correspondiente.”
Y el investigador vuelve al punto de partida.
El atacante no necesita saber qué equipo es responsable. El investigador tampoco debería tener que resolver el organigrama interno de una multinacional para encontrar al responsable. Si el problema atraviesa capas, el atacante ve un sistema. El investigador ve un sistema. La organización, sin embargo, puede verlo como tres equipos o más distintos.
3. El caso STA: una investigación transversal
Mi investigación sobre Structured Text Amplification (STA) comenzó en 2022, estudiando comportamientos relacionados con texto estructurado y agotamiento de recursos en Android. Lo que parecía un problema aislado en una biblioteca fue revelando un patrón más amplio.
Con el tiempo, aparecieron diferentes manifestaciones en distintos componentes:
| Componente | Síntoma | Mecanismo |
|---|---|---|
| libminikin.so | ANR, bloqueo del hilo principal | Knuth-Plass O(n²) |
| Binder / SavedState | TransactionTooLargeException, crash loops | Serialización O(n²) |
| Llm's (modelo) | Instruction Drift, generación de contenido sin contexto | Atención O(n²) |
| Llm's (cliente) | ANR, UI freeze | libminikin O(n²) |
| Navegadores | Bloqueo de renderizado | Algoritmos de layout O(n²) |
Lo interesante no era cada fallo individual, sino la posibilidad de que existiera un patrón común:
Entrada estructurada (texto repetitivo, baja entropía)
↓
Transformación (tokenización, layout, serialización)
↓
Amplificación del coste (algoritmo O(n²))
↓
Agotamiento de recursos (CPU, memoria, tiempo)
↓
Pérdida de disponibilidad (ANR, crash, DoS)
Este patrón aparecía en el cliente Android (la apps de Google, Mozilla, Meta, Microsoft, Xiaomi, entre otros). Aparecía en el sistema operativo (libminikin, Binder). Y, más tarde, apareció también en los Llm's, tanto en el modelo (pérdida de contexto) como en el cliente (ANR al renderizar respuestas largas o tareas simples como contar caracteres ).
El problema era real, reproducible y estaba documentado con stacktraces, métricas de sistema y pasos concretos. Pero al intentar reportarlo siguiendo los cauces establecidos, ocurrió lo que muchos investigadores han vivido:
- VRP's: “Fuera de alcance.”
- llm's VRP: “Bypass de guardrail de seguridad. Fuera de alcance.”
- Feedback in-product: Canal adecuado, pero sin garantía de respuesta o mitigación.
El patrón STA existía. Las evidencias eran sólidas. Pero la responsabilidad quedaba diluida entre equipos, programas y criterios.
4. La anatomía de una derivación
Para entender el problema, es útil analizar qué ocurre cuando un reporte atraviesa el sistema de gestión de vulnerabilidades de una gran organización.
Fase 1: Recepción
El investigador envía un informe detallado. Recibe un acuse de recibo automático. El reporte entra en una cola de triaje.
Fase 2: Triaje inicial
Un revisor, a menudo con poco tiempo y muchos reportes, clasifica el problema. Si encaja en un patrón conocido, puede ser asignado a un equipo. Si no, puede ser rechazado por “falta de información” o “no reproducible”.
Fase 3: Análisis técnico
El equipo asignado analiza el problema. Si el equipo es el correcto, la investigación avanza. Si el problema cruza fronteras, aparece la pregunta: “¿Es realmente nuestro?”
Fase 4: Derivación
El problema se traslada a otro equipo. Ese equipo, a su vez, puede derivarlo a otro. Cada derivación reinicia parcialmente el proceso. Cada equipo aplica sus propios criterios.
Fase 5: Decisión final
En algún punto, el problema es clasificado como “fuera de alcance”, “no elegible para recompensa” o “no reproducible”. El investigador recibe una respuesta. El problema sigue existiendo.
Lo paradójico es que cada decisión individual puede ser razonable. Cada equipo puede tener argumentos válidos para no asumir la responsabilidad. Pero el resultado final es que el problema no se soluciona.
Y el investigador, que empezó con la intención de ayudar, se encuentra con un muro de silencio.
5. “Out of scope” no significa “el problema no existe”
Hay una confusión conceptual que conviene aclarar.
Un programa de recompensas puede establecer legítimamente qué tipos de problemas son elegibles para recompensa. Esa es una decisión de alcance. Es razonable que una empresa defina los límites de su programa.
Pero:
Un problema puede quedar fuera de un VRP y seguir siendo:
- Reproducible.
- Técnicamente relevante.
- Peligroso para determinados usuarios.
- Digno de una mitigación.
- Digno de una investigación interna.
- Digno de ser documentado públicamente.
Esta distinción es fundamental. Un programa de recompensas puede rechazar un reporte por alcance, pero eso no significa que el equipo de producto deba ignorarlo.
El problema ocurre cuando “fuera de alcance” se convierte en un sinónimo de “no es responsabilidad nuestra” y cuando esa falta de responsabilidad impide que el problema se solucione.
6. El coste de la investigación independiente
Para entender la asimetría, hay que considerar los recursos de cada parte.
Una gran organización puede disponer de:
- Equipos especializados en diferentes áreas.
- Acceso al código fuente completo.
- Infraestructura de reproducción a gran escala.
- Telemetría para identificar la prevalencia del problema.
- Ingenieros dedicados a tiempo completo.
- Herramientas internas de análisis y depuración.
- Capacidad para parchear millones de dispositivos en días o semanas.
- Departamento legal para gestionar riesgos.
- Presupuesto para recompensas y reconocimiento.
El investigador independiente, en cambio, puede disponer de:
- Un ordenador (a menudo personal).
- Un teléfono (a menudo personal).
- Unos bugreport (obtenidos con esfuerzo).
- Una conexión a Internet.
- Y muchas horas de trabajo no remunerado.
En mi caso, buena parte de esta investigación se ha realizado desde un entorno doméstico. No hay un laboratorio detrás, ni un departamento legal, ni un equipo de ingeniería esperando para validar cada hipótesis. La validación de las evidencias recae enteramente en el investigador.
Y, sin embargo, el investigador debe proporcionar evidencia suficientemente sólida para que una organización pueda tomar una decisión. La exigencia es legítima. La reciprocidad debería serlo también.
7. Cuando la evidencia contradice la respuesta inicial
Una de las situaciones más reveladoras ocurre cuando la primera conclusión de la organización es:
“No reproducible.”
Pero posteriormente aparecen:
- Nuevos dispositivos donde el problema se manifiesta.
- Nuevos dumps con stacktraces adicionales.
- Nuevos ANR traces en el mismo componente.
- Nuevas aplicaciones afectadas por el mismo patrón.
- Nuevas reproducciones que confirman la hipótesis.
- Evidencia del mismo componente en diferentes contextos.
- Comportamiento consistente entre productos.
Entonces la pregunta ya no debería ser:
“¿Por qué el investigador insiste?”
La pregunta debería ser:
“¿Qué hemos aprendido desde la primera evaluación?”
La seguridad no debería funcionar como un juicio que termina con la primera decisión. Debería funcionar como un proceso iterativo:
Hipótesis inicial
↓
Evidencia recopilada
↓
Reproducción en condiciones controladas
↓
Análisis técnico
↓
Nueva evidencia (más dispositivos, más contextos)
↓
Reevaluación de la hipótesis
↓
Actualización de la decisión
Este ciclo es común en la investigación científica. En la seguridad, sin embargo, tiende a ser lineal: una decisión inicial, sin espacio para la reevaluación.
8. La paradoja de la coordinación
Cuando una organización solicita coordinación, el mensaje es claro:
“Danos tiempo para investigar y solucionar el problema.”
El investigador acepta. Pero la coordinación implica una segunda obligación: utilizar ese tiempo de forma efectiva.
La coordinación no debería significar:
Investigador
↓
Reporte (con evidencia)
↓
Espera (semanas o meses)
↓
"No reproducible"
↓
Investigador aporta más evidencia
↓
Espera
↓
"Out of scope"
↓
Investigador apela
↓
Espera
↓
"Pertenece a otro equipo"
↓
Investigador reporta al otro equipo
↓
El ciclo se reinicia
Eso no es coordinación. Es derivación de responsabilidad. Es un laberinto donde el investigador es el único que recorre todas las salas, mientras la organización mantiene sus puertas cerradas.
9. Una contradicción evidente
Al investigador se le dice:
“No publiques todavía.”
Perfecto. Es razonable.
Pero si después de meses o años la respuesta continúa siendo:
“No es nuestro problema.”
¿Durante cuánto tiempo debe permanecer el investigador en silencio?
- ¿Quién protege al usuario durante ese periodo?
- ¿Quién asume el riesgo de que el problema sea explotado?
- ¿Quién decide que el problema merece atención?
- ¿Quién determina si el problema es “suficientemente grave”?
- ¿Dónde termina la responsabilidad del investigador y empieza la responsabilidad del fabricante?
El modelo actual responde a estas preguntas de forma implícita:
“El investigador es responsable de no divulgar. El fabricante es responsable de decidir si el problema existe.”
Pero la decisión de “si el problema existe” no debería ser una decisión unilateral, especialmente cuando el investigador ha aportado evidencia sólida y reproducible.
10. La responsabilidad no puede viajar solo en una dirección
El modelo actual puede resumirse así:
| Investigador | Organización |
|---|---|
| Reproducir el problema | Investigar técnicamente |
| Documentar con evidencias | Validar la información |
| Reportar a través de los canales | Responder en tiempo razonable |
| Coordinar la divulgación | Coordinar la corrección |
| Esperar el tiempo necesario | Actuar sobre el problema |
| No divulgar prematuramente | Mitigar el riesgo |
| Facilitar información adicional | Asumir responsabilidad |
El problema aparece cuando la segunda columna se convierte en:
“No corresponde a nuestro programa.”
“No es elegible para recompensa.”
“Pertenece a otro equipo.”
Entonces la primera columna sigue teniendo todas las obligaciones, mientras que la segunda conserva únicamente la posibilidad de rechazar el caso.
Eso es una asimetría estructural. No es un fallo de una empresa concreta. Es un fallo del modelo.
11. La recompensa tampoco debería ser el centro
Hay una cuestión especialmente importante que suele pasarse por alto.
La investigación de seguridad no debería reducirse a:
Bug → CVE → recompensa
Hay investigadores que buscan dinero. Otros buscan reconocimiento. Otros simplemente quieren que el problema se arregle. Algunos investigan porque quieren comprender cómo funcionan los sistemas y compartir ese conocimiento.
Por eso una respuesta como:
“No es elegible para recompensa”
no debería cerrar necesariamente la conversación técnica.
Podría existir otra respuesta:
“No podemos recompensarlo según las reglas del programa, pero hemos identificado el problema y vamos a mitigarlo.”
“Hemos derivado el problema al equipo de producto para que lo evalúe en futuras versiones.”
Esa sería una respuesta mucho más saludable para el ecosistema.
12. El silencio como estrategia
Hay una realidad incómoda que pocos investigadores mencionan abiertamente.
En algunos casos, el silencio —o la derivación, no es un fallo del sistema, sino una estrategia deliberada.
Si un problema no se clasifica como vulnerabilidad, no hay obligación de parchearlo.
Si el problema se deriva a otro equipo, la responsabilidad queda en suspenso.
Si el investigador se cansa y desiste, el problema desaparece del radar.
Esta estrategia no requiere mala fe. Puede ser simplemente el resultado de equipos que trabajan bajo presión, con recursos limitados, y que priorizan los problemas que encajan en sus métricas.
Pero el efecto es el mismo: el problema no se soluciona.
13. El investigador independiente no tiene voz en la decisión
Una de las asimetrías más profundas es la siguiente:
El investigador aporta el descubrimiento. Aporta la evidencia. Aporta el tiempo. Aporta la paciencia. Aporta la buena fe.
Pero no tiene voz en la decisión final.
- No decide si el problema es “suficientemente grave”.
- No decide si merece un parche.
- No decide cuándo se solucionará.
- No decide si se reconocerá su trabajo.
- No decide si se comunicará públicamente.
La organización tiene todas esas decisiones. El investigador tiene solo la decisión de publicar o no publicar.
Y esa decisión, publicar, está cargada de riesgos: legales, reputacionales, y de relación con futuros reportes.
14. Divulgación coordinada no es silencio coordinado
Existe una diferencia esencial entre ambas cosas:
Divulgación coordinada:
“Tenemos un problema. Trabajemos juntos para entenderlo, mitigarlo y comunicarlo de forma responsable.”
Silencio coordinado:
“El problema está reportado, pero nadie quiere asumir la responsabilidad. El investigador espera. El problema sigue existiendo.”
La primera protege a los usuarios. La segunda protege principalmente al proceso.
La primera es colaboración. La segunda es inacción.
Y la seguridad debería estar diseñada para proteger a los usuarios, no los procesos internos.
15. El caso STA como ejemplo de un problema más amplio
STA no es una excepción. Es un ejemplo de lo que ocurre cuando un comportamiento atraviesa diferentes capas de un ecosistema y la responsabilidad queda fragmentada.
En mi investigación, el mismo patrón apareció en:
- Android (libminikin, Binder, SavedState).
- Llm's (modelo y cliente).
- Aplicaciones de terceros (WhatsApp, navegadores).
- Componentes compartidos (StaticLayout, LineBreaker).
Cada uno de estos dominios tiene sus propios equipos, sus propios programas de recompensas, sus propios criterios y sus propias prioridades.
Pero el patrón subyacente es el mismo. Es la misma entrada estructurada, la misma amplificación de coste, el mismo agotamiento de recursos.
Sin embargo, cuando intenté reportarlo de forma transversal, me encontré con que:
- VRP's lo consideraron “fuera de alcance”.
- llm's VRP lo consideraron “safety guardrail bypass”.
- El feedback in-product no garantiza respuesta ni mitigación.
- El problema sigue existiendo.
STA no es un problema de un equipo. Es un problema de arquitectura. Y los problemas de arquitectura no se solucionan derivando responsabilidades.
16. Lo que debería cambiar
Para que la divulgación coordinada funcione de forma efectiva, se necesitan algunos cambios en el modelo actual:
a. Puntos de entrada transversales
Las grandes organizaciones deberían tener puntos de entrada para problemas que cruzan equipos. Un equipo central de triaje que pueda evaluar un problema técnico sin necesidad de que el investigador conozca el organigrama interno.
b. Distinción clara entre “alcance” y “existencia”
Que un problema no sea elegible para recompensa no debería impedir que el equipo de producto lo evalúe y, si es necesario, lo mitigue.
c. Procesos de reevaluación
Si el investigador aporta evidencia adicional que contradice una decisión inicial, debería existir un proceso para reabrir la investigación sin necesidad de reiniciar todo el ciclo.
d. Comunicación transparente
Si el problema se deriva a otro equipo, el investigador debería ser informado de forma clara, con un punto de contacto o un identificador de seguimiento.
e. Reconocimiento sin recompensa
Si el problema no cumple los criterios de recompensa, pero es técnicamente relevante, la organización debería poder ofrecer un reconocimiento simbólico (mención en los agradecimientos, nota en las release notes, etc.).
17. Una pregunta incómoda (y su respuesta)
Después de años investigando vulnerabilidades, con mas de 400 descubiertas y documentadas y mas de 80 CVE, observando este patrón, hay una pregunta que considero inevitable:
No tengo una respuesta sencilla. Pero sí tengo una conclusión:
Si se espera que el investigador actúe responsablemente para proteger a los usuarios, las organizaciones deben hacer lo mismo. La seguridad no es un juego de trileros donde la responsabilidad se pasa de una mano a otra hasta que el investigador se cansa.
El investigador debe asumir su parte. Pero la organización también.
18. El objetivo final
No se trata de ganar una discusión. No se trata de conseguir una recompensa. No se trata de demostrar que una empresa se equivocó.
Se trata de algo mucho más sencillo:
- Si una vulnerabilidad puede solucionarse, solucionémosla.
- Si no es vulnerable, demostremos por qué.
- Si está fuera del alcance de un programa, derivémosla al equipo adecuado.
- Si el impacto no alcanza el umbral de una recompensa, eso no impide investigarla.
Pero no deberíamos permitir que el último paso sea:
“Este problema pertenece a otro.”
Porque entonces el problema sigue perteneciendo a todos. Y, al final, a nadie.
19. Una llamada a la responsabilidad compartida
La divulgación responsable nació como un pacto de confianza entre investigadores y fabricantes. Ese pacto sigue siendo necesario. Pero la confianza funciona en ambas direcciones.
El investigador debe asumir responsabilidad por lo que descubre.
- Investigar con rigor.
- Documentar con precisión.
- Reportar con buena fe.
- Coordinar con paciencia.
- Divulgar con responsabilidad.
Las empresas deben asumir responsabilidad por lo que construyen.
- Responder con seriedad.
- Investigar cuando exista evidencia suficiente.
- Distinguir entre “fuera de alcance” y “no existe”.
- Evitar derivaciones infinitas.
- Proporcionar puntos de contacto adecuados.
- Informar cuando la investigación continúa.
- Mitigar cuando sea necesario.
Cuando un investigador entrega evidencia reproducible, concede tiempo y respeta los mecanismos de coordinación, la respuesta no debería ser una cadena infinita de derivaciones.
Debería existir una puerta de entrada.
Alguien que diga:
“Entendido. Nosotros nos encargamos de averiguar quién debe solucionarlo.”
Porque esa es precisamente la diferencia entre gestionar un reporte y gestionar un riesgo de seguridad.
Conclusión: la seguridad no es un juego de trileros
La seguridad informática es un campo que se basa en la confianza. Confiamos en que los fabricantes corrigen los problemas que les reportamos. Confiamos en que los investigadores no explotan las vulnerabilidades antes de que se solucionen.
Pero la confianza no es un recurso infinito. Se agota cuando una de las partes no cumple su parte.
La divulgación coordinada no debería ser una excusa para que las empresas trasladen todo el riesgo al investigador. No debería ser un mecanismo para silenciar problemas incómodos. No debería ser un laberinto del que el investigador no pueda salir.
Debería ser un proceso colaborativo donde ambas partes asumen sus responsabilidades para proteger a los usuarios.
El investigador descubre. El fabricante corrige.
Y el usuario, al final, está protegido.
Ese es el objetivo. No deberíamos perderlo de vista.
Como final del artículo diré: si clicar en un enlace causa el crash wn una aplicación y esta aplicación hace caer SystemUI y a su vez causa un loop de reinicios y se la interfaz y obliga al sistema a borrar sus propios datos de estado etc y de la que un usuario normal no sabe recuperarse, no es un problema de seguridad entonces que es?
Manuel García Peña (Lostmon) — Independent Security Researcher
Agosto de 2026
Posts
