Divulgación responsable en España:

cómo reportar un fallo sin acabar imputado

Gobernanza y cumplimiento  |  unfantasmaenelsistema.com

Encuentras una vulnerabilidad en el portal de una empresa —un identificador que puedes cambiar en la URL para ver facturas de otros, una clave de API en el código JavaScript, un panel de administración sin contraseña— y quieres hacer lo correcto: avisar para que lo arreglen. En la mayoría de países existe un camino claro para eso. En España el camino existe, pero está lleno de piedras, porque el Código Penal no distingue entre quien accede a un sistema para robar y quien lo hace para avisar de que la puerta estaba abierta.

Este artículo explica los modelos de divulgación que se usan en el mundo, por qué el marco legal español es especialmente delicado, qué papel juega el INCIBE-CERT como coordinador y qué buenas prácticas reducen —no eliminan— el riesgo cuando decides reportar. No es asesoramiento jurídico: ante un caso concreto, y sobre todo si ya has accedido a algo, habla con un abogado penalista antes de dar el siguiente paso.

1. Tres formas de contar un fallo

1.1 Divulgación coordinada (coordinated disclosure)

El investigador comunica el fallo en privado al responsable del sistema, acuerda con él un plazo razonable para corregirlo —90 días es el estándar de facto que popularizó Google Project Zero— y solo publica los detalles cuando hay parche o cuando vence el plazo. Es el modelo recomendado por ENISA, por el INCIBE y por la norma ISO/IEC 29147 (vulnerability disclosure).

1.2 Divulgación completa (full disclosure)

El investigador publica todos los detalles de inmediato, sin avisar o sin esperar al parche. El argumento a favor es que presiona al fabricante y que, si el fallo ya se conoce en círculos cerrados, ocultarlo solo protege al atacante. El argumento en contra es evidente: deja a todos los usuarios expuestos mientras no hay solución. Hoy se reserva para casos de fabricantes que llevan meses ignorando el reporte.

1.3 Programas de bug bounty

La organización publica una política que invita a buscar fallos dentro de un alcance definido, ofrece una recompensa y —lo importante a efectos legales— se compromete por escrito a no emprender acciones legales contra quien respete las reglas. Se gestionan en plataformas (HackerOne, Bugcrowd, Intigriti, YesWeHack) o directamente por la empresa.

2. El problema español: no hay excepción de investigación

La Directiva 2013/40/UE sobre ataques contra los sistemas de información se traspuso a España endureciendo el Código Penal, pero sin incluir una eximente para la investigación de seguridad de buena fe. Los artículos que entran en juego son:

• Artículo 197 bis CP: castiga acceder o facilitar el acceso al conjunto o una parte de un sistema de información, o mantenerse en él, vulnerando las medidas de seguridad y sin estar autorizado. La pena base es de seis meses a dos años de prisión. No exige ánimo de lucro ni causar daño: basta el acceso no autorizado a un sistema protegido
• Artículo 197 ter CP: castiga fabricar, adquirir o facilitar programas o contraseñas concebidos para cometer los delitos anteriores. Es el artículo que puede rozar a quien comparte una prueba de concepto
• Artículo 264 y siguientes CP: daños informáticos —borrar, dañar, alterar o hacer inaccesibles datos o sistemas— y obstaculización grave del funcionamiento. Un escaneo agresivo o un exploit que tumba un servicio pueden caer aquí
• Artículo 197 CP (descubrimiento y revelación de secretos): si en el proceso accedes a datos personales de terceros, se suma este tipo, con penas más altas

3. El coordinador: INCIBE-CERT y NIS2

NIS2 (Directiva (UE) 2022/2555) obliga a cada Estado a designar un CSIRT como coordinador de la divulgación de vulnerabilidades. En España ese papel recae en el INCIBE-CERT (y en el CCN-CERT para el sector público). Su función es hacer de intermediario de confianza cuando el investigador no consigue contactar con el fabricante, cuando el fabricante no responde, o cuando la vulnerabilidad afecta a varios productos a la vez.

El INCIBE-CERT mantiene un procedimiento y un canal (formulario y PGP) para comunicar vulnerabilidades. Coordina el contacto, ayuda a fijar un calendario y, cuando procede, gestiona la asignación de un identificador CVE. Lo que no hace es concederte inmunidad: reportar a través del CERT es una vía más ordenada y con un tercero que documenta tu buena fe, pero no borra un acceso no autorizado que ya hayas cometido.

4. Safe harbor: qué es y hasta dónde llega

El safe harbor (puerto seguro) es la cláusula de una política de divulgación en la que la organización declara que considera autorizada la actividad de investigación que respete esas reglas y que no ejercerá acciones legales ni presentará denuncia. Es el mecanismo que convierte un bug bounty en algo razonablemente seguro para el investigador.

Sus límites, que conviene leer con lupa:

• Solo cubre el alcance publicado: los dominios, aplicaciones, rangos de IP y tipos de prueba listados. Tocar un subdominio que no está en la lista te saca del paraguas
• Solo vincula a quien la publica: si el fallo afecta a datos de terceros o a un proveedor, esas otras partes no han firmado nada y pueden denunciar por su cuenta
• No desactiva la acción penal pública: en delitos perseguibles de oficio, que la empresa no denuncie no impide que la Fiscalía actúe si la conducta llega a su conocimiento
• Suele excluir: ingeniería social a empleados, ataques de denegación de servicio, pruebas físicas, uso de exploits públicos contra terceros y la exfiltración de datos reales
• Puede exigir confidencialidad: no publicar sin permiso o hasta pasado un plazo

5. Cómo reportar minimizando el riesgo

• Párate en la puerta: si al pulsar el enlace o cambiar el parámetro ves que hay un fallo, tienes bastante para reportar. No enumeres registros de otros, no descargues datos, no pruebes si desde ahí llegas a otro sistema
• No uses datos reales de terceros: si necesitas demostrar el impacto, usa dos cuentas de prueba tuyas; nunca capturas con datos personales de usuarios reales
• Documenta con fecha: guarda de forma privada qué hiciste, cuándo y con qué alcance mínimo. Si algún día tienes que explicar tu buena fe, esto es tu defensa
• Reporta por un canal seguro: security.txt, formulario de la política o el canal PGP del INCIBE-CERT. Evita redes sociales y formularios de «contacto comercial»
• Sé concreto y sobrio: qué, dónde, impacto, pasos mínimos de reproducción. Sin exigencias, sin amenazas de publicar, sin pedir dinero (pedir una recompensa fuera de un programa puede interpretarse como extorsión, artículos 243 y 197.3 CP)
• Propón un plazo razonable (60-90 días) y ofrece ayuda para verificar el parche
• No publiques hasta que haya solución o venza el plazo pactado, y aun así valora publicar solo una descripción de alto nivel

5.1 Si te ignoran

Reenvía el reporte una vez, deja constancia del intento y escala al INCIBE-CERT para que coordine. Si tras el plazo y la intermediación del CERT sigue sin haber respuesta, una divulgación limitada y coordinada con el CERT —sin exploit funcional y sin datos de terceros— es el último recurso, y conviene hacerla con criterio legal.

5.2 Si te amenazan

No respondas a la amenaza por tu cuenta ni borres tus registros. Conserva toda la correspondencia, no publiques nada y busca un abogado penalista con experiencia en delitos informáticos. Organizaciones como la asociación de la comunidad y algunos despachos especializados han asistido a investigadores en esta situación.

Conclusión

La divulgación responsable es un servicio a la comunidad, pero en España se hace en un marco legal que no reconoce la figura del investigador de buena fe. La regla práctica es sencilla: cuanto más lejos llegues dentro del sistema ajeno, peor tu posición, con independencia de tus intenciones.

Si vas a buscar fallos de forma activa, hazlo dentro de un programa de bug bounty con safe harbor y respeta su alcance al milímetro. Si tropiezas con un fallo por casualidad, párate en la puerta, documenta lo mínimo, reporta por un canal seguro o a través del INCIBE-CERT, y no publiques nada hasta que esté resuelto. Y ante cualquier duda seria, consulta con un abogado antes que con el fabricante.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)