Política de divulgación de vulnerabilidades

Visión general

Esta página establece la política de divulgación coordinada de vulnerabilidades de NextPDF. Indica a la persona que reporta cómo contactar en privado con los mantenedores, qué tiempo de respuesta puede esperar y cómo funciona el embargo.

Límite. Una política de divulgación es un compromiso de proceso, no una garantía de plazo ni de resultado. Los objetivos siguientes son los compromisos de buena fe de los mantenedores con las personas que reportan; describen el proceso que sigue el proyecto, no una promesa contractual de que un informe concreto recibirá acuse de recibo, clasificará, corregirá ni divulgará en una fecha concreta. El momento de la divulgación coordinada se negocia; no se garantiza de forma unilateral.

Instalación

No procede. Reportar una vulnerabilidad no requiere instalar nada. La superficie de contacto legible por máquina se publica en /.well-known/security.txt (RFC 9116). La política autorizada y legible para personas es el archivo SECURITY.md del repositorio.

Descripción conceptual

La política implementa la divulgación coordinada de vulnerabilidades tal como la define ISO/IEC 29147 y el proceso de gestión de ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): recepción privada, clasificación y evaluación de gravedad, una fase de corrección bajo embargo y divulgación pública conjunta. Cuando una vulnerabilidad afecta a varios proveedores, el calendario del aviso se coordina entre las partes afectadas en lugar de fijarse de forma unilateral (iso_iec_29147#x3.x110.p13).

El proceso también está alineado con las obligaciones de gestión de vulnerabilidades del fabricante de la EU Cyber Resilience Act (eu_cra#x1.p191) y con la práctica de «responder a las vulnerabilidades» del NIST Secure Software Development Framework (nist_sp_800_218#x15). En ambos casos, se plantean como obligaciones de proceso repetibles, no como garantía de que cualquier resultado concreto esté asegurado.

Superficie de la API

No procede. La divulgación es un proceso, no una API. La superficie de descubrimiento legible por máquina es el archivo RFC 9116 security.txt; las herramientas analizan sus campos Contact: y Expires:. Esta página no duplica el contenido de ese archivo, salvo por los canales que figuran a continuación.

Ejemplo de código: inicio rápido

No procede. No hay código que ejecutar para reportar una vulnerabilidad. Usar un canal privado:

GitHub Security Advisories (opción preferida: cifrado en reposo, registro de auditoría): abrir un aviso en borrador en la pestaña Security de GitHub del proyecto.
Correo electrónico: enviar a [email protected] con [SECURITY] en el asunto. Si se necesita cifrado de extremo a extremo y todavía no hay ninguna clave OpenPGP publicada en security.txt, usar en su lugar el canal de GitHub Security Advisory.

No reportar a través de incidencias públicas, listas de correo públicas, redes sociales ni chat. La divulgación pública antes de que exista una corrección pone en peligro a los usuarios de versiones sin parchear.

Ejemplo de código: producción

No procede.

Casos límite y trampas

Los objetivos son compromisos, no SLA. El calendario que figura a continuación indica los objetivos del proyecto. Un problema complejo con varios componentes, o uno que requiera coordinación con proyectos upstream, puede tardar más; la persona que reporta se mantiene informada.
La duración del embargo es negociable, con un límite máximo. El embargo predeterminado se extiende desde la clasificación hasta la publicación de la corrección. Si la persona que reporta necesita más tiempo, debe solicitarlo de forma explícita al abrir el aviso. Una vez superado el máximo, el proyecto publicará el aviso, esté disponible o no una corrección, de acuerdo con las normas del sector sobre divulgación coordinada; esto protege a los usuarios frente a avisos retenidos de forma indefinida.
La gravedad determina el calendario. Un problema crítico que se esté explotando activamente se gestiona con un plazo reducido; una sugerencia de refuerzo de baja gravedad no sigue el mismo calendario. La gravedad se evalúa durante la clasificación y puede revisarse.
La emisión de un CVE forma parte de la clasificación. El mantenedor solicita un CVE mediante la inscripción del proyecto como CNA en GitHub Security Advisory como parte del paso de clasificación; la persona que reporta no necesita solicitarlo por separado.

Rendimiento

No procede.

Notas de seguridad

Los objetivos de tiempo de respuesta son compromisos con las personas que reportan y constituyen la base de referencia para la gestión de vulnerabilidades del proyecto. Son objetivos, no garantías:

Etapa	Objetivo
Acuse de recibo	en un plazo de 1 a 2 días hábiles
Clasificación inicial y evaluación de gravedad	en un plazo de ~5 días hábiles / 7 días naturales
Desarrollo del parche y revisión privada	normalmente 14 días hábiles; de 30 a 90 días para CVE confirmados complejos, según la gravedad
Asignación de CVE (si se acepta)	de forma simultánea al parche, a través del canal CNA de GitHub
Divulgación pública coordinada	en la publicación del parche, en una fecha fijada de forma conjunta con la persona que reporta
Embargo (desde la clasificación hasta la publicación)	de forma predeterminada ~90 días, reducido en caso de explotación activa, ampliable previa solicitud explícita hasta un máximo fijo

Reglas del proceso que un revisor puede comprobar:

Lo privado primero. Ningún canal público se acepta como vía de recepción. Los únicos canales aceptados son GitHub Security Advisory y el correo electrónico de seguridad.
Coordinada, no unilateral. El momento de la divulgación se negocia con la persona que reporta y con cualquier proveedor también afectado (iso_iec_29147#x3.x110.p13).
Embargo acotado. El embargo tiene un valor predeterminado y un límite máximo absoluto; un aviso no se retiene de forma indefinida.
Reconocimiento a petición. Se da reconocimiento a los investigadores una vez que se levanta el embargo, salvo que soliciten el anonimato.

Estas afirmaciones describen el proceso que el proyecto se compromete a seguir. No garantizan que un informe concreto derive en una corrección, un CVE ni una divulgación en una fecha determinada.

Conformidad

No es un perfil de conformidad. La política está alineada con ISO/IEC 29147 e ISO/IEC 30111 y con las obligaciones de proceso de la CRA/SSDF citadas anteriormente; «alineada con» es una redacción deliberada: el proyecto no afirma estar certificado conforme a ninguno de estos esquemas. Definen las características de un proceso sólido; esta página documenta el compromiso del proyecto de aplicarlo.

Véase también

Centro de confianza
Modelo de amenazas del motor
Modelo de seguridad de firma y cifrado
Archivo SECURITY.md del repositorio y /.well-known/security.txt (RFC 9116)