Divulgar una vulnerabilidad es gestionar una transición de riesgo
Una vulnerabilidad puede descubrirse en minutos y tardar meses en corregirse. Durante ese intervalo, alguien conoce una condición explotable, otros pueden depender del producto afectado y los defensores necesitan decidir qué hacer sin disponer todavía de toda la información. Publicar inmediatamente puede ampliar la capacidad de abuso; guardar silencio indefinidamente puede dejar expuestos a quienes necesitan mitigar. La divulgación responsable no resuelve esa tensión con una fecha universal: la convierte en un proceso coordinado, documentado y revisable.
En este capítulo, vulnerability disclosure significa comunicar la existencia, el alcance y las mitigaciones de una vulnerabilidad a las partes que deben actuar. Coordinated Vulnerability Disclosure (CVD), divulgación coordinada de vulnerabilidades, añade la coordinación entre quien descubre o reporta, quien mantiene el producto, quienes integran el componente y, cuando corresponde, una entidad coordinadora. No es un pacto para ocultar defectos ni un mecanismo para premiar una conducta; es una forma de reducir daño mientras cambia el estado técnico del sistema.
El objetivo profesional no es escoger entre «privado» y «público» como etiquetas morales. Es construir un argumento para cada transición: qué se sabe, quién puede actuar, qué información necesita, qué riesgo crea compartirla y qué condición permite pasar al siguiente estado. Este enfoque conecta el capítulo con alcance, evidencia, causalidad y pruebas: una comunicación precisa no reemplaza la validación técnica, y una validación técnica no decide por sí sola la política de publicación.
El objeto de coordinación: una vulnerabilidad y sus estados
Una vulnerabilidad es una condición de un producto, servicio o sistema que puede ser explotada bajo determinadas precondiciones para afectar una propiedad de seguridad. Un reporte no es todavía una vulnerabilidad confirmada: puede estar incompleto, duplicado, fuera de alcance o describir un comportamiento esperado. La coordinación empieza separando tres afirmaciones distintas:
- el reportante observó un comportamiento y conserva evidencia;
- el mantenedor reprodujo, rechazó o aún no pudo determinar la condición;
- las partes evaluaron qué acciones y qué divulgación reducen el riesgo.
Confundirlas produce dos errores simétricos. Tratar todo reporte como fallo confirmado puede desviar recursos y revelar detalles sin fundamento. Tratar un reporte no validado como ruido puede perder tiempo crítico, especialmente cuando afecta una dependencia común. El criterio profesional es registrar el estado y el motivo de cada transición, no ocultar la incertidumbre detrás de un sí o un no.
Un ciclo operativo útil puede representarse así: recepción → triaje → validación → coordinación de mitigación → preparación de comunicación → divulgación → seguimiento y cierre. No es una máquina de estados universal. Un caso puede volver de validación a recepción si aparecen productos afectados nuevos; puede iniciar contención antes de tener causa completa; y puede divulgarse antes de existir un parche cuando la exposición ya es pública o el proveedor no responde. El modelo sirve para preguntar qué salida está autorizada en cada fase.
En recepción se confirma el canal y se protege la información sensible. En triaje se comprueban alcance, reproducibilidad inicial, impacto plausible y posibles afectados. En validación se identifica la condición técnica y se buscan explicaciones alternativas. En coordinación se comparten datos mínimos con fabricantes, mantenedores, distribuidores y operadores que puedan mitigar. La comunicación pública traduce la evidencia a acciones: versiones afectadas, condiciones, mitigaciones, parche o ausencia de corrección. El cierre conserva decisiones, evidencia y regresiones pendientes.
El error frecuente es confundir el ticket con el estado de la vulnerabilidad. Un identificador interno permite seguir el trabajo; no demuestra que el defecto exista ni que esté corregido. Uso profesional: mantener un registro con estado, responsable, alcance, fechas, evidencia, dependencias, decisiones de divulgación y próximos criterios de revisión. Si una fecha se aplaza, la razón debe quedar visible para las partes autorizadas.
La nueva evidencia puede reabrir un caso; comunicar medidas no requiere siempre esperar al parche.
Reportar con suficiente evidencia y sin convertir el reporte en un exploit
Un reporte accionable describe la condición, no sólo su efecto. Debe indicar producto y versión, configuración y entorno, precondiciones, pasos mínimos para reproducir, resultado observado, resultado esperado, impacto sobre activos o propiedades, evidencia con procedencia y cualquier dependencia conocida. Un caso sintético ayuda a distinguir calidad de cantidad: «un usuario de la organización A puede leer un registro de la organización B al cambiar un identificador en esta solicitud» permite probar autorización y aislamiento; «hay una fuga de datos» no indica qué observar ni cómo contener.
El reportante debe minimizar el impacto de la prueba. Utilizar datos propios o sintéticos, límites de tasa, un entorno autorizado y una prueba de no persistencia reduce la posibilidad de transformar una demostración en incidente. Si demostrar el impacto exige acceder a un dato real, se detiene en la mínima evidencia necesaria y se documenta por qué. La política pública puede definir pruebas permitidas, pero la existencia de una dirección de correo o de un archivo security.txt no concede por sí sola permiso para probar cualquier sistema.
La evidencia debe distinguir observación, inferencia e impacto potencial. Un log que muestra una respuesta HTTP es observación; afirmar que permite leer datos de otro cliente es una inferencia que requiere comparar identidades y controles; la pérdida regulatoria o operacional es un impacto que puede ser posible, no necesariamente observado. Esta separación evita que un mantenedor descarte un informe por una puntuación exagerada y evita que un reportante presente una hipótesis como hecho.
El error frecuente es adjuntar un exploit completo cuando basta una prueba de concepto mínima. El código puede contener credenciales, destruir datos o ser reutilizado fuera del alcance. Otro error es omitir versiones y dependencias, lo que impide diferenciar un defecto del producto de una configuración local. Uso profesional: ofrecer un reproductor determinista, reversible y limitado; separar en anexos la evidencia sensible; y solicitar un canal cifrado cuando el reporte contenga secretos o datos personales.
Diseñar el canal antes de necesitarlo
Una política de divulgación de vulnerabilidades (VDP, Vulnerability Disclosure Policy) convierte el proceso en una interfaz pública. Define alcance, exclusiones, canales, autorización para pruebas limitadas, información esperada, protección de datos, tiempos de respuesta, reglas de coordinación, reconocimiento y método para escalar. La política no puede prometer una respuesta técnica instantánea ni declarar «safe harbor» como inmunidad jurídica universal; sólo puede expresar compromisos operativos y límites que la organización está en condiciones de cumplir.
El archivo security.txt definido por RFC 9116 ayuda a descubrir ese canal. Para un servicio web, el archivo se publica bajo /.well-known/security.txt sobre HTTPS y puede incluir Contact, Policy, Encryption, Acknowledgments, Canonical y Expires. RFC 9116 es una especificación informativa y complementa, no sustituye, una política. Su alcance depende del dominio o dirección donde se recupera: la presencia en example.com no extiende automáticamente autorización a todos los subdominios. La directiva Expires hace visible cuándo revisar la información, y el documento advierte que un archivo manipulado o un redireccionamiento puede desviar reportes.
Estos límites importan a ambos lados. El investigador verifica el dominio, el certificado, los redireccionamientos y, cuando exista, la firma o una fuente alternativa antes de enviar detalles. La organización controla la dirección, la clave y los recursos enlazados; una dirección abandonada no es un canal operativo. La política debe decir qué ocurre si un reporte contiene datos de terceros, si un servicio está gestionado por otro proveedor o si el investigador necesita una coordinación multiparte.
El error frecuente es publicar un buzón sin equipo, alcance ni protección. El resultado es una cola que pierde mensajes y una expectativa de coordinación que nadie puede satisfacer. Uso profesional: probar periódicamente el canal con un informe sintético, medir acuse y escalado, rotar responsables y tratar el VDP como control que también requiere pruebas de regresión.
Roles, autoridad y coordinación multiparte
El finder o descubridor encuentra la condición; el reporter puede ser quien la comunica aunque no la haya descubierto; el proveedor o mantenedor decide sobre el producto que controla; un integrador puede necesitar corregir una configuración o una versión; un operador debe aplicar la mitigación; y un coordinator puede ayudar cuando hay varios proveedores, intereses en conflicto o riesgo sistémico. Una organización puede desempeñar varios roles, pero debe declarar cuándo cambia de autoridad.
La autoridad técnica tampoco es la autoridad para publicar. Un desarrollador puede confirmar el defecto y no tener permiso para divulgar información de clientes. Un coordinador puede sincronizar fechas y no poder prometer un parche. Un investigador puede tener evidencia fuerte y no poder autorizar pruebas sobre un tercero. Registrar quién decide cada acción evita que «el equipo de seguridad» se convierta en un sujeto sin responsabilidad.
La coordinación multiparte aparece cuando un producto incorpora una biblioteca, cuando un servicio depende de un proveedor o cuando una vulnerabilidad afecta una familia de implementaciones. La primera pregunta es el alcance técnico: ¿comparten código, protocolo, configuración, imagen o sólo un nombre? La segunda es la ruta de mitigación: ¿quién puede corregir la causa, quién puede reducir exposición y quién debe informar a sus clientes? La tercera es la dependencia temporal: un proveedor puede tener una versión corregida mientras un integrador necesita pruebas y otro mantiene productos fuera de soporte.
El CERT Guide to Coordinated Vulnerability Disclosure recomienda reducir daño, evitar sorpresas y presumir buena fe como principios de coordinación, no como sustitutos de evidencia. Si una parte deja de responder, se documentan intentos y se busca una ruta alternativa; el silencio no prueba mala fe ni congela indefinidamente la protección de los usuarios. NIST SP 800-216 describe una función de recepción, evaluación, seguimiento y comunicación que puede servir como referencia para un programa, pero su alcance federal no convierte sus pasos en obligación universal.
El error frecuente es enviar el mismo reporte completo a una lista amplia «para acelerar». Cada destinatario añade una posibilidad de filtración y puede interpretar de modo distinto la fecha de publicación. Uso profesional: identificar primero la autoridad con capacidad de corregir, compartir el mínimo que permite actuar, acordar qué información puede circular y mantener un registro de contactos y dependencias. En un caso sin proveedor localizable, un coordinador externo puede ser una escalada técnica y de proceso; no es un permiso para publicar secretos operativos.
Cada parte actúa sobre lo que controla; el coordinador conecta responsables, pero no autoriza acciones sobre activos ajenos.
Validar, clasificar y decidir sin reducirlo todo a una cifra
La validación pregunta si la condición es reproducible, qué versiones afecta, qué precondiciones requiere y qué propiedad puede perderse. La priorización pregunta qué debe hacerse primero dadas exposición, explotabilidad, población afectada, disponibilidad de mitigación, dependencia y consecuencias. Son decisiones relacionadas pero no idénticas. Un defecto difícil de explotar puede ser urgente si está expuesto en una infraestructura crítica; uno fácil de reproducir puede tener poco alcance si sólo existe en un entorno de prueba aislado.
CVSS es un lenguaje para comunicar características y severidad de una vulnerabilidad. En CVSS v4.0, los grupos Base, Threat, Environmental y Supplemental separan propiedades intrínsecas, evolución de la amenaza, entorno concreto y atributos adicionales. El resultado no es una medida completa del riesgo de una organización ni una orden automática de trabajo. El error frecuente es copiar una puntuación base como si describiera el contexto del cliente o usarla para decidir sin comprobar exposición, activos, compensaciones y esfuerzo de remediación. Uso profesional: conservar el vector y los supuestos, explicar qué grupo se usó y combinarlo con evidencia de exposición y consecuencias.
La asignación de un CVE ID tiene otra función: permitir que distintas partes se refieran a la misma vulnerabilidad. Las CVE Numbering Authorities (CNA) son las organizaciones autorizadas por el programa para asignar identificadores y publicar registros dentro de su alcance. Para esta distinción usamos la edición documental CNA Operational Rules v4.1.0, §§1.1 y 3.1, no una afirmación de que sea la última edición. La conclusión práctica es separar identificación, gravedad y corrección: ver un identificador no basta para conocer la severidad ni para comprobar que existe un parche. Esas preguntas requieren consultar la evaluación y el aviso correspondiente. No se debe retrasar una mitigación necesaria sólo por esperar un identificador.
Un aviso técnico debe permitir una acción verificable: producto y versiones, condición y vector de ataque descritos sin ampliar innecesariamente la capacidad ofensiva, impacto, detección, mitigación temporal, corrección disponible, agradecimientos y referencias. Si la causa aún no está confirmada, se dice. Si el parche corrige una ruta pero quedan configuraciones vulnerables, se evita «resuelto» como etiqueta universal. El aviso es un artefacto de coordinación; su texto debe coincidir con la evidencia y con los cambios realmente publicados.
La figura compara funciones, no etapas obligatorias. Un caso puede necesitar varios de estos artefactos; disponer de uno no demuestra que existan los demás.
Tiempo, embargo y publicación
Un embargo es un acuerdo temporal para no divulgar públicamente cierta información mientras se prepara una corrección o mitigación. No es un derecho automático del proveedor ni una obligación de silencio ilimitada del investigador. Su razón debe ser operacional: permitir que los afectados reciban una acción antes de que los detalles aumenten el riesgo. El acuerdo debe registrar participantes, información cubierta, fecha o condición de revisión, excepciones de emergencia y qué ocurre si la corrección no llega.
No existe una duración que sea correcta para todos los casos. Un defecto en una biblioteca ampliamente distribuida, una vulnerabilidad ya explotada, un servicio de emergencia y un producto sin mantenedor tienen ritmos y riesgos distintos. La fecha debe revisarse cuando cambian la explotación observada, la disponibilidad de mitigación, el número de afectados o la capacidad de las partes para responder. Una fecha vencida no convierte el caso en falso; cambia la decisión de comunicación.
La publicación coordinada debe llegar a quienes pueden actuar: proveedor, integradores, operadores y usuarios. Si ya hay explotación pública, filtración o una divulgación no controlada, la prioridad puede pasar de sincronizar un parche a publicar medidas defensivas mínimas. Eso no justifica divulgar indicadores o pasos de explotación sin evaluar su utilidad y daño. El criterio es qué información permite reducir riesgo ahora y qué detalles pueden esperar a una versión corregida.
El error frecuente es tratar el plazo como contrato rígido que prevalece sobre evidencia nueva, o como amenaza para forzar al proveedor. Uso profesional: acordar hitos, avisar cambios, preparar comunicación por capas y conservar la decisión y su justificación. Si no hay acuerdo, el reportante comunica con precisión el estado y sus límites; no atribuye una corrección inexistente ni presenta el silencio como validación.
Safe harbor, conducta y límites de autorización
Una política puede ofrecer compromisos de protección condicionados al cumplimiento de su alcance. Un ejemplo concreto es la política de divulgación de GSA, «What you can test» y «Your legal protections»: excluye servicios no enumerados, incluidos servicios conectados, y condiciona su compromiso de no iniciar o recomendar acciones legales al cumplimiento de la política. También advierte que otras entidades pueden decidir independientemente sobre sus propias acciones. Este ejemplo permite entender el límite de un safe harbor sin convertirlo en una regla jurídica universal: hay que leer quién ofrece el compromiso, bajo qué condiciones y sobre qué activos. El capítulo no determina la licitud de una conducta en una jurisdicción concreta.
Por esa razón, la política debe separar «autorización para probar» de «promesa de no reclamar». Debe señalar activos excluidos, límites de automatización, pruebas destructivas, ingeniería social, denegación de servicio y acceso físico. El investigador documenta cómo interpretó la autorización y detiene la actividad si una nueva evidencia amplía el impacto. El mantenedor no debe exigir pruebas que impliquen daño para aceptar un reporte: puede pedir una demostración alternativa, telemetría o un entorno controlado.
El error frecuente es usar una etiqueta de buena fe como argumento para ignorar el alcance, o exigir al investigador una confidencialidad sin límite y sin canal seguro. Uso profesional: leer la versión vigente de la política, conservarla junto al reporte y escalar ambigüedades antes de actuar. Cuando el caso implica datos personales, infraestructuras de terceros o riesgo físico, se necesita asesoría institucional y controles adicionales; este capítulo no ofrece una conclusión jurídica.
Cuando la coordinación falla
Los fallos de proceso suelen ser visibles antes que el defecto técnico. Un canal que no acusa recibo oculta si alguien está trabajando. Una política sin alcance invita a pruebas incompatibles. Un mantenedor que no distingue «no reproducido» de «no vulnerable» comunica certeza falsa. Un proveedor que parchea sin avisar a integradores deja una exposición residual. Un aviso que contiene una receta de explotación pero no una mitigación aumenta capacidad ofensiva sin mejorar defensa.
La respuesta no es añadir más reuniones. Hay que localizar la transición que falló y la evidencia que faltó. Si se perdió la dependencia, mantener un inventario de componentes y una autoridad de contacto. Si el parche no se pudo probar, preparar un entorno de regresión y comunicar la mitigación temporal. Si un reportante publicó antes de tiempo, separar el riesgo creado por la publicación del riesgo original y ofrecer a defensores datos accionables. Si el caso está duplicado, vincular reportes y explicar qué evidencia comparte cada uno.
La coordinación tampoco debe retrasar la contención de un sistema propio. Si existe evidencia de explotación, se activan las prácticas de respuesta a incidentes y se preservan datos con procedencia. Un proceso CVD trata el defecto; un incidente trata una situación de compromiso. Pueden compartir personas y evidencia, pero no son sinónimos: un reporte válido no prueba explotación, y un incidente confirmado no espera a que termine la negociación de un aviso.
Un procedimiento defendible para el trabajo diario
Ante un reporte nuevo, el profesional puede construir una ficha que responda, en orden, estas preguntas:
- ¿Qué se observó? Registrar mensaje, versión, configuración, momento y procedencia; separar hecho de interpretación.
- ¿Qué está autorizado? Comprobar política, activo, identidad del receptor y límites de prueba; detener acciones ambiguas.
- ¿Qué condición se propone? Formular precondiciones, mecanismo, propiedad afectada y resultado esperado; conservar hipótesis alternativas.
- ¿Quién debe actuar? Identificar mantenedor, proveedor ascendente, integradores, operadores y posibles usuarios afectados.
- ¿Qué evidencia falta? Pedir la mínima reproducción segura y comprobar versiones, exposición y controles compensatorios.
- ¿Qué riesgo cambia al compartir? Evaluar filtración, explotación, privacidad, urgencia, reversibilidad y utilidad defensiva.
- ¿Qué transición se autoriza? Aceptar, pedir información, rechazar con razón, coordinar mitigación, publicar o escalar; cada salida requiere un motivo y una fecha de revisión.
- ¿Qué queda después? Confirmar parche o mitigación, publicar límites, probar regresión, actualizar dependencias y cerrar sólo cuando la evidencia sostenga el estado comunicado.
Este procedimiento no elimina el juicio. Hace explícitos los puntos donde una decisión puede revisarse y facilita que otra persona reconstruya el caso. La calidad se mide por correspondencia entre condición, evidencia, autoridad y comunicación, no por el número de reportes cerrados ni por la cantidad de identificadores asignados.
Síntesis
La divulgación responsable es una práctica de reducción de daño bajo incertidumbre. Empieza por un reporte reproducible y limitado, pasa por validación y coordinación con las autoridades relevantes y termina —cuando corresponde— en una comunicación que permite actuar. security.txt, una VDP, un CVE ID o una puntuación CVSS son piezas distintas: descubren un canal, describen un proceso, identifican una vulnerabilidad pública o comunican características; ninguno por sí solo prueba seguridad, corrige el defecto o autoriza una prueba.
El mecanismo central es la transición controlada entre estados de conocimiento y exposición. Cada paso debe declarar qué se sabe, qué se infiere, qué queda fuera, quién puede decidir y qué nueva evidencia obliga a cambiar el plan. El embargo es temporal y justificado, no silencio ilimitado. La coordinación multiparte distribuye responsabilidades, no la evidencia. El safe harbor reduce incertidumbre operativa, no sustituye autorización ni asesoría jurídica. Y una publicación eficaz sirve para mitigar: no convierte una historia incompleta en certeza.
Comprobación de comprensión
Un reporte afirma que existe una fuga entre tenants, pero sólo contiene una captura de pantalla y una puntuación CVSS. ¿Qué separarías como observación, inferencia e impacto potencial antes de validarlo?
Criterio de respuesta: Debe pedir contexto de versión, cuentas, solicitud y respuesta, procedencia y reproducción segura; debe tratar la fuga y el impacto como hipótesis hasta comprobar el mecanismo y las precondiciones, y explicar que CVSS no valida el defecto.
¿Por qué publicar un archivo security.txt no autoriza por sí mismo una prueba de denegación de servicio ni se extiende automáticamente a todos los subdominios?
Criterio de respuesta: Debe citar el alcance del dominio o dirección donde se recupera según RFC 9116 y distinguir descubribilidad de canal, política de autorización y límites de pruebas; debe reconocer que la presencia del archivo no reemplaza permiso explícito.
Una vulnerabilidad afecta una aplicación, una biblioteca upstream y varios integradores. ¿Cómo asignarías roles y qué información mínima compartirías en la primera ronda?
Criterio de respuesta: Debe identificar quién mantiene cada componente, quién puede corregir o mitigar y si hace falta un coordinador; debe compartir condición, versiones, precondiciones, evidencia mínima y límites de impacto, sin distribuir secretos o un exploit innecesario.
Compara qué responde una VDP, security.txt, un CVE ID y una puntuación CVSS. ¿Qué conclusión no autoriza ninguno por sí solo?
Criterio de respuesta: Debe distinguir VDP como política y alcance, security.txt como descubrimiento de canal, CVE ID como identificador cuyo estado puede ser preasignado o publicado, y CVSS como comunicación de características/severidad; debe negar que cualquiera pruebe seguridad, corrección, autorización general o ausencia de explotación.
El proveedor propone un embargo de 120 días, pero ya se observa explotación pública y aún no hay mitigación. ¿Qué variables revisarías y qué comunicación sería defendible?
Criterio de respuesta: Debe considerar exposición, capacidad de acción de afectados, explotación, dependencia, reversibilidad y fecha de revisión; debe priorizar medidas defensivas y comunicar límites, sin convertir la fecha en silencio indefinido ni publicar una receta innecesaria.
Una política ofrece safe harbor para pruebas de buena fe dentro del alcance. ¿Qué acción sigue siendo ambigua o peligrosa y cómo la tratarías?
Criterio de respuesta: Debe señalar que safe harbor no es inmunidad universal y comprobar activos excluidos, datos de terceros, automatización, ingeniería social, denegación de servicio y jurisdicción; debe pedir autorización o detenerse cuando el alcance no sea claro.
El proveedor confirma un parche para la API, pero la biblioteca de autorización sigue vulnerable en una integración antigua. ¿Qué significa cerrar el caso y qué pruebas faltan?
Criterio de respuesta: Debe rechazar cierre universal; debe probar versiones y rutas afectadas, validar mitigación y regresión, comunicar riesgo residual a integradores y conservar evidencia de qué componente y configuración quedaron cubiertos.
Tras dos semanas sin confirmación de alcance, redacta criterios de escalado o publicación que no conviertan el silencio en prueba de vulnerabilidad ni de buena fe.
Criterio de respuesta: Debe documentar acuses e intentos, buscar contacto alternativo o coordinador, preservar evidencia y límites, valorar explotación y capacidad de mitigación, fijar revisión y comunicar sólo afirmaciones sustentadas; el silencio no confirma ni refuta el defecto.
Problema de transferencia
Un investigador descubre que un servicio multi-tenant permite consultar un identificador perteneciente a otra organización. La prueba usa dos cuentas propias y no extrae datos reales. El servicio se compone de una API del proveedor, un componente de autenticación externo y una biblioteca de autorización mantenida por un tercero. La VDP sólo ofrece un formulario web, no publica security.txt, y el proveedor acusa recibo pero no confirma alcance tras dos semanas.
Redacta una ficha de coordinación. Separa observaciones, hipótesis y consecuencias potenciales; identifica la autoridad técnica de cada componente; propone la evidencia mínima adicional y una mitigación reversible; define qué información compartirías con el tercero y en qué orden; y establece criterios para escalar o publicar sin presentar como confirmado lo que todavía no se ha validado. Explica cómo cambiarían tus decisiones si aparece explotación pública o si el proveedor corrige sólo la API sin que la biblioteca tenga una versión actualizada.
Fuentes principales
- NIST. SP 800-216: Recommendations for Federal Vulnerability Disclosure Guidelines, versión final de 2023, marco para recepción, evaluación, seguimiento y comunicación de reportes.
- E. Foudil y Y. Shafranovich. RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, 2022, §§2–5, formato, alcance y consideraciones de seguridad de
security.txt. - CERT/CC, Software Engineering Institute. The CERT Guide to Coordinated Vulnerability Disclosure, edición web basada en el informe 2017-SR-022, principios, roles, fases y coordinación multiparte.
- GSA. Vulnerability disclosure policy, apartados «What you can test» y «Your legal protections»; ejemplo de política institucional, no legislación universal.
- CVE Program. CNA Operational Rules v4.1.0, §§1.1 y 3.1; edición documental de 2025 para identificación y alcance de CNA, no afirmación de última versión.
- FIRST. CVSS v4.0 Specification Document, 2023, grupos de métricas y límites de la puntuación.