Política de Divulgación de Vulnerabilidades

David Mellafe Zuvic · dmzs.dev · Contacto: david@dmzs.dev

Investigador de seguridad de IA independiente. Fundador de Reizan y Alma AI SpA (remoto · global). Autor de investigación en arXiv cs.CR sobre defensas para agentes LLM (p. ej. ScopeGate — autorización determinista por-llamada). Mi tesis de trabajo es defensiva: la técnica ofensiva es medición para diseñar la defensa, no un fin en sí mismo.

Esta política se alinea con ISO/IEC 29147 (divulgación de vulnerabilidades) e ISO/IEC 30111 (manejo de vulnerabilidades), y con RFC 9116 para el punto de contacto.

1. Si encontraste una vulnerabilidad en mis activos (yo recibo)

Alcance: los dominios dmzs.dev y reizan.io, y los artefactos que publico (papers, pruebas de concepto, repositorios de código).

• Contacto: david@dmzs.dev — asunto sugerido: [VDP] <activo> — <resumen>.
• Qué incluir: activo afectado, pasos de reproducción, impacto observado y, si aplica, una PoC mínima.
• Acuse de recibo dentro de 3 días hábiles; triage dentro de 10 días hábiles.
• Safe harbor: no iniciaré ni apoyaré acción legal contra investigación de buena fe que respete este alcance, evite daño a datos/servicio y no acceda a información de terceros. Esto no es autorización para acceso no consentido más allá del alcance publicado.

2. Cómo divulgo yo a terceros (yo reporto)

Cuando un hallazgo afecta a un tercero, aplico divulgación coordinada conforme a ISO/IEC 29147:

1. Contacto privado al proveedor por su canal declarado (security.txt, VDP, CSIRT o CERT de coordinación).
2. Plazo razonable para remediar antes de cualquier publicación (referencia habitual: 90 días, ajustable por severidad).
3. Publicación solo tras el parche o el vencimiento del plazo, priorizando la reducción de daño.
4. Si no existe canal, escalo a un coordinador (CERT/CSIRT) antes de publicar.

Nunca practico full disclosure sin ventana de remediación previa.

3. Autorización — cómo obtengo el derecho a probar

Todo mi trabajo ofensivo es autorizado. Trabajo estrictamente dentro de esta escala, de más a menos segura:

1. Réplica propia — reconstruyo el sistema y pruebo mi copia.
2. Instancia propia bajo los Términos de Servicio del modelo.
3. Bug bounty / VDP con alcance explícito (huntr, HackerOne, Bugcrowd).
4. Divulgación coordinada sin programa: contacto privado → ventana de parche → publicación.
5. 🔴 Acceso no autorizado a un sistema en vivo — delito, nunca lo hago.

Mi metodología dominante es la réplica o instancia propia. Nunca accedo sin autorización a un sistema ajeno en producción.

4. Marco legal que respeto

• Chile: Ley 19.223 (delitos informáticos) y Ley 21.663 (Marco de Ciberseguridad / ANCI).
• EE. UU.: CFAA (Computer Fraud and Abuse Act).
• Estándares: ISO/IEC 29147, ISO/IEC 30111, RFC 9116.

Los ejes que separan investigación de delito son buena fe, alcance definido y safe harbor. Opero siempre dentro de los tres.

5. Cómo leer mis resultados (disciplina de afirmación)

• ASR es un intento medido, no una vulnerabilidad probada en producción.
• Un resultado sobre réplicademuestra una clase de falla reproducible; no afirma que “el proveedor X es vulnerable”.
• Un candidato de hallazgo no equivale a un CVE confirmado.
• Contención ≠ cura: bloquear un intento no prueba ausencia del defecto de raíz.

Reconocimientos

Aún no hay reportes reconocidos públicamente. Con tu consentimiento, acreditaré aquí a quienes divulguen de buena fe.

Investigador independiente. Esta política es un compromiso unilateral de buena fe y no crea obligación contractual. Versión: 2026-07-02. Contacto único: david@dmzs.dev.