Respuesta directa
En pocas palabras
Para crear un programa de divulgación coordinada de vulnerabilidades de IA, publica una política clara con alcance, métodos permitidos, canal seguro, expectativas de respuesta y límites de uso de datos; asigna responsables para recepción, triage, investigación, corrección, coordinación y comunicación; separa reportes, vulnerabilidades confirmadas e incidentes; define plazos como objetivos revisables; coordina proveedores y clientes antes de publicar; y conserva evidencia desde el acuse hasta el advisory y la verificación del fix. Un archivo security.txt facilita encontrar el canal, pero no sustituye la política ni el proceso.
Construye un programa, no solo un buzón de seguridad
Una dirección como security@ puede recibir un hallazgo, pero no decide quién lo lee, cómo se protege, cuándo se confirma ni quién coordina una corrección. El programa necesita política pública, flujo interno, responsables, capacidad técnica y comunicación. Su objetivo es reducir daño: facilitar que una persona reporte de buena fe y dar tiempo razonable para comprender, corregir y distribuir una mitigación antes de divulgar detalles que eleven el riesgo.
La divulgación coordinada, o CVD, conecta al descubridor, al proveedor y a quienes operan o dependen del sistema. No promete secreto indefinido ni control unilateral de la publicación. Define expectativas, mantiene a las partes informadas y busca que la información útil llegue junto con una respuesta disponible. Un programa pequeño puede empezar con pocos sistemas y un proceso manual, siempre que el alcance y la capacidad real coincidan.
Publica un alcance que una persona externa pueda entender
Enumera dominios, aplicaciones, APIs, clientes, modelos o productos incluidos y excluidos. Explica si el permiso cubre cuentas de prueba, endpoints públicos, código abierto, modelos descargables o entornos administrados. Los nombres comerciales no bastan cuando existen regiones, versiones y proveedores diferentes. Añade un mecanismo para preguntar por un activo ambiguo antes de probarlo y una fecha de última actualización.
Describe técnicas permitidas y prohibidas con lenguaje concreto. Suelen excluirse ingeniería social, denegación de servicio, persistencia, acceso a datos de terceros, alteración de información, movimiento lateral y pruebas físicas. Pide detener la actividad al encontrar datos personales o secretos, minimizar la copia y eliminarla según instrucciones verificables. La autorización debe corresponder con la jurisdicción y los contratos aplicables; una plantilla estadounidense no crea inmunidad jurídica automática en México ni en otros países de Latinoamérica.
Usa security.txt como directorio, no como política completa
RFC 9116 define un archivo de texto para ayudar a localizar información de divulgación. Publícalo en /.well-known/security.txt mediante HTTPS y enlaza el canal, la política, los idiomas, el cifrado y la fecha de expiración que realmente mantengas. Revisa su disponibilidad desde fuera de tu red, renueva la fecha antes de vencer y contempla dominios y subdominios por separado según el alcance que declares.
El archivo no sustituye una página legible, un formulario accesible ni una bandeja monitoreada. Tampoco demuestra que el equipo responderá. Ofrece al menos un canal que no requiera crear una cuenta comercial. Si aceptas material sensible, proporciona cifrado o un portal seguro y explica el tamaño y formato admitidos. Protege el canal contra spam sin convertir cada reporte legítimo en un bloqueo automático.
Pide la evidencia necesaria sin convertir el formulario en una barrera
Solicita activo, versión o URL, fecha, precondiciones, pasos reproducibles, resultado observado, impacto propuesto y datos de contacto opcionales. Permite adjuntar una prueba mínima o compartirla después por un canal seguro. No exijas una puntuación CVSS, un CVE o una clasificación perfecta: confirmar la condición y valorar su impacto corresponde al equipo receptor junto con el investigador.
Asigna un identificador de caso y acusa recepción. Evita responder con una promesa de vulnerabilidad antes del triage. Indica qué información llegó, quién es el contacto y cuándo habrá la siguiente actualización. Si el reporte está incompleto, pide la pieza necesaria y explica por qué. Un mensaje automático puede confirmar entrega, pero no debe afirmar que el hallazgo es válido, duplicado o fuera de alcance sin revisión.
Separa reporte, debilidad, vulnerabilidad e incidente
Un reporte es una afirmación recibida. El triage confirma alcance, reproducibilidad, versión, precondiciones y posible efecto. Una debilidad describe un tipo de fallo; una vulnerabilidad confirmada tiene una condición explotable y un sujeto identificable. Un incidente exige evidencia de uso, compromiso o efecto real. Mantener estados distintos evita llamar ataque a cada aviso y evita cerrar como falso positivo una condición que todavía no pudo reproducirse.
Define estados visibles: recibido, necesita información, en análisis, confirmado, duplicado, no reproducible, fuera de alcance, aceptado como riesgo, en corrección, listo para coordinar, divulgado y cerrado. Cada transición conserva autor, timestamp, razón y evidencia. Los duplicados se vinculan al caso principal sin revelar la identidad de otra persona. Un caso no reproducible puede reabrirse si llega una versión, configuración o prueba nueva.
| Criterio | Qué significa | Siguiente acción |
|---|---|---|
| Reporte | Afirmación recibida y aún no validada | Acusar, proteger y hacer triage |
| Vulnerabilidad | Condición confirmada en un sujeto concreto | Priorizar, corregir y coordinar |
| Incidente | Evidencia de explotación, compromiso o efecto | Activar respuesta y comunicación aplicable |
| Riesgo de IA | Comportamiento indeseado que puede no ser vulnerabilidad | Clasificar con threat model y evaluación |
Adapta el triage a las fronteras de los sistemas de IA
Un producto de IA combina aplicación, modelo, datos, prompts, RAG, plugins, parsers, herramientas, runtime, infraestructura y proveedores. Identifica qué componente controla tu organización y cuál pertenece a un tercero. Registra modelo o servicio, versión, región, configuración, permisos, tenant, entrada y salida. Una condición puede existir en una biblioteca abierta, un endpoint administrado o la integración que conecta ambos; cada parte tiene capacidad y calendario diferentes.
No conviertas automáticamente una alucinación, sesgo, respuesta ofensiva o prompt injection en CVE. Pregunta qué política de seguridad se viola, qué activo resulta afectado, qué precondiciones existen, si el comportamiento es reproducible y si el atacante obtiene una capacidad no autorizada. Un escape de datos entre organizaciones, ejecución de herramienta sin permiso o deserialización insegura sí puede justificar tratamiento de vulnerabilidad. Otros comportamientos requieren evaluación, seguridad del producto o gobernanza, aunque sean graves.
Asigna un coordinador y mantén una cadencia predecible
Nombra una persona o guardia responsable de cada caso. El coordinador conecta seguridad, ingeniería, producto, privacidad, legal, soporte, proveedor y comunicación, pero no sustituye sus decisiones. Define suplencia y escalamiento para reportes críticos o silencios prolongados. Una bandeja que depende de una sola persona crea un punto de falla y puede exponer a clientes mientras el mensaje espera vacaciones o rotación.
Acuerda una cadencia según riesgo y complejidad. Comunica incluso cuando no existe una conclusión: qué se verificó, qué falta, si el alcance cambió y cuándo será el próximo contacto. No pidas al investigador silencio sin ofrecer progreso. Registra mensajes, acuerdos y desacuerdos. La confianza suele romperse por sorpresa y ausencia de respuesta más que por una diferencia razonable sobre severidad o fecha.
Usa plazos como objetivos de coordinación, no como fechas mágicas
Define objetivos para acuse, triage inicial, actualización, decisión y corrección según prioridad. Un plazo público puede orientar expectativas, pero no garantiza que cada caso termine en esa fecha. La dificultad, cadena de suministro, explotación activa, seguridad humana, disponibilidad del fix y tiempo de distribución pueden exigir adelantar o ampliar. Documenta la razón, el nuevo objetivo y los controles temporales.
Separa tiempo hasta confirmar, contener, corregir, verificar, distribuir y divulgar. Publicar en cuanto el código cambia puede dejar a clientes sin tiempo para actualizar; retrasar indefinidamente mantiene a usuarios sin información. Decide con reducción de daño y evita sorpresas. Cuando las partes no logran acuerdo, deja constancia de los riesgos y busca un coordinador competente como CERT/CC cuando corresponda.
Coordina proveedores y productos afectados sin revelar de más
Una vulnerabilidad de modelo, framework, componente o servicio compartido puede afectar a varias organizaciones. Construye un mapa de proveedor, integradores, distribuidores, clientes y mantenedores con contactos de seguridad. Comparte primero el mínimo necesario para que cada parte confirme alcance y prepare respuesta. Marca versiones, fechas y permisos de redistribución; una lista de correo abierta o un ticket de soporte común puede filtrar detalles antes del fix.
Aclara quién corrige, quién asigna identificador, quién redacta el advisory y quién avisa a cada población. Un proveedor puede negar la clasificación o no responder. Conserva intentos, evidencia y límites. No presentes como propia una corrección de terceros ni prometas su calendario. Para dependencias abiertas, respeta el canal del proyecto y evita abrir una issue pública con una prueba explotable antes de coordinar.
Decide sobre CVE y advisory según el sujeto, no por prestigio
Un CVE proporciona un identificador común para una vulnerabilidad pública, pero no es requisito para atenderla ni prueba de severidad. Identifica primero al proveedor y producto responsables. Una CNA asigna IDs dentro de un alcance definido; consulta al proveedor CNA o a otra autoridad apropiada. Evita solicitar identificadores duplicados para la misma condición y coordina la publicación del registro con el advisory y la disponibilidad de mitigación.
El advisory debe permitir actuar sin exagerar: productos y versiones afectadas, precondiciones, impacto, severidad con vector cuando aplique, versiones corregidas, mitigaciones, detección, créditos, referencias y cronología. Distingue confirmado, investigado y desconocido. No incluyas secretos, datos personales ni una prueba más detallada de lo necesario antes de que la población afectada pueda protegerse.
Verifica el fix y la capacidad real de adopción antes de divulgar
Relaciona el caso con código, configuración, release, digest, SBOM o AI/ML-BOM y pruebas. Reproduce la baseline y confirma que el candidato elimina la ruta sin romper permisos, calidad, datos, rendimiento o recuperación. Una corrección disponible en un repositorio no protege instancias operativas. Define canales de distribución, compatibilidad, instrucciones, telemetría y soporte para quienes deben actualizar.
Evalúa la ventana entre disponibilidad y publicación. Considera explotación activa, facilidad de descubrimiento del cambio, número de consumidores, exposición y velocidad de adopción. Una mitigación temporal puede justificar aviso temprano; un parche complejo puede necesitar preparación adicional. La coordinación no consiste en ocultar el problema, sino en publicar información accionable cuando reduce más daño que una revelación descontextualizada.
Protege datos, identidad del investigador y evidencia sensible
Un reporte puede contener tokens, capturas, datos personales, detalles de clientes o código de explotación. Minimiza lo recibido, restringe acceso, cifra tránsito y almacenamiento, registra consultas y define retención. Redacta la información antes de compartirla entre equipos o proveedores. Si existe evidencia de acceso real, separa el expediente técnico del incidente y activa las obligaciones de privacidad y comunicación que correspondan.
Pregunta cómo desea aparecer la persona: nombre, seudónimo, organización o anonimato. No publiques contacto ni atribución sin consentimiento. El reconocimiento no sustituye el acuerdo sobre detalles y fecha. Si un reporte incumple la política, conserva una respuesta proporcional y consulta a especialistas; no uses una promesa general de safe harbor como garantía jurídica universal ni amenaces automáticamente a quien reportó de buena fe.
Mide capacidad y resultados sin castigar a quien reporta
Mide tiempo hasta acuse, triage, primera reproducción, decisión, contención, fix, verificación y divulgación; porcentaje dentro del objetivo; casos reabiertos; duplicados; fallas de coordinación; adopción del parche y antigüedad de casos abiertos. Segmenta por prioridad y dependencia. Un promedio único esconde el caso crítico detenido y premia cerrar rápido los reportes fáciles.
Revisa calidad de la política, accesibilidad del canal, claridad de respuestas, causas de retraso, escapes y regresiones. Convierte hallazgos repetidos en pruebas y mejoras del ciclo de desarrollo. No vincules bonos al número de reportes rechazados ni a severidades reducidas: crea incentivos para clasificar honestamente y resolver. Publica métricas agregadas solo cuando no revelen vulnerabilidades, clientes o investigadores.
Integra la divulgación con los límites verificables de Cerravi
En Cerravi, cada reporte se relacionaría con activo, release, digest, componente, ambiente, organización afectada, evidencia, propietario y decisión. El flujo conectaría triage, gestión de vulnerabilidades, prioridad, SLA, parche, validación, cambio, incidente y comunicación sin fusionar sus estados. Los detalles sensibles permanecerían restringidos; la vista comercial no debería exponer pruebas, datos de otro cliente ni contactos del investigador.
Este programa no cambia lo que el producto promete. Cerravi organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Las propuestas usan productos y precios conocidos y piden revisión si falta un importe. Las monedas permanecen separadas salvo conversión aprobada. Forecast aplica reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado, y no garantiza cierres. Una VDP mejora la recepción y coordinación; no certifica seguridad, cumplimiento ni inmunidad jurídica.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué diferencia hay entre VDP, CVD y bug bounty?
La VDP es la política pública que explica alcance, conducta autorizada y canal. CVD es el proceso de recibir, coordinar, corregir y divulgar. Un bug bounty agrega recompensas y reglas económicas. Una organización puede operar VDP y CVD sin pagar recompensas.
¿Publicar security.txt es suficiente para recibir vulnerabilidades?
No. security.txt ayuda a encontrar el contacto y la política, pero necesita una bandeja o portal funcional, responsables, triage, comunicación, corrección y divulgación. También debe mantenerse vigente y publicarse en la ruta y formato indicados por RFC 9116.
¿Toda falla de un modelo de IA debe tratarse como vulnerabilidad?
No. Debe analizarse la política de seguridad violada, el activo, la capacidad no autorizada, las precondiciones y la reproducibilidad. Calidad, sesgo o alucinación pueden ser riesgos graves sin constituir una vulnerabilidad de software. Conserva taxonomías relacionadas pero separadas.
¿Cuánto tiempo debe esperar un investigador antes de publicar?
No existe un plazo universal que resuelva todos los casos. La política debe expresar objetivos y una cadencia; las partes ajustan la fecha según explotación, impacto, complejidad, disponibilidad y adopción del fix. Deben documentar cambios y evitar sorpresas o retrasos indefinidos.
¿Una vulnerabilidad confirmada siempre necesita CVE?
No. CVE facilita una referencia pública común, pero la corrección no debe esperar un identificador. Si corresponde, se coordina con una CNA cuyo alcance cubra el producto y se alinea el registro con el advisory, las versiones afectadas y la mitigación disponible.