Una página de política de seguridad no es un proceso de divulgación

Todo proyecto serio tiene una página de seguridad, y una página es barata. La pregunta útil es si un informe enviado por el canal documentado produce una versión corregida que los usuarios normales puedan instalar. Eso exige cuatro pruebas en lugar de una afirmación, y todas son verificables desde fuera sin sondear nada. Ninguna requiere una prueba contra el servidor de otra persona. Todas caben en una página de notas.

Encuentre el canal y compruebe que existe

Empiece por la ruta documentada: una página de política de seguridad, una dirección dedicada o un archivo /.well-known/security.txt cuyo campo Contact esté definido por RFC 9116.

Después lea el párrafo del alcance en lugar de la introducción amable. ¿Qué productos se cubren, qué versiones y qué trato pide el proyecto?

Un canal que pertenece a otro proyecto, o a un proveedor de alojamiento en lugar del mantenedor, no es un proceso de divulgación para el software que evalúa.

Rastreador público o canal privado

Los defectos ordinarios van a un rastreador público y se benefician de él. Un informe con un detalle explotable no, y presentarlo en público expone a los usuarios mientras el mantenedor todavía lo lee.

Un proyecto que solo ofrece un rastreador público no ha proporcionado un canal de divulgación, diga lo que diga su documentación.

Nada de esto autoriza a probar sistemas que no posee. Una dirección de denuncia es una invitación a enviar información, no un permiso para sondear servidores públicos no relacionados.

Siga una corrección de principio a fin

Elija un aviso anterior y rastréelo: ¿nombra las versiones afectadas y la versión que las corrige, y puede un usuario instalar realmente esa versión?

Ese rastro es la diferencia entre un acuse de recibo y una reparación. Una respuesta amable que nunca produce una versión es un resultado de relaciones públicas. Un aviso breve con un número de versión y un enlace de descarga es un proceso que funciona. Un buen aviso responde rápido a cuatro cosas: qué está afectado, cuál es el impacto, qué versión lo corrige y dónde conseguirlo.

El historial de versiones completa el resto. Las versiones regulares con notas claras sugieren un proyecto que puede entregar una corrección, lo que importa más que una política elocuente.

Mantenedor del cliente u operador del servicio

Para una VPN, las personas que escriben el cliente y las que operan una puerta de enlace suelen ser organizaciones distintas. Un problema en el código del cliente y un error de despliegue del servidor necesitan destinatarios diferentes.

Decida a cuál de los dos afecta su hallazgo antes de enviarlo, porque dirigirlo a la parte equivocada suele acabar en silencio en lugar de en un rebote.

Qué prueba la ausencia y qué no

Una lista de avisos vacía no demuestra que un producto esté libre de defectos. Puede significar un proyecto joven, una superficie pequeña o que nadie está mirando.

Igualmente, una página de política ausente no es prueba de mala fe. Es prueba de que no puede verificar el proceso, y esa es la conclusión honesta que conviene anotar.

Qué anotar

Anote cuatro hechos: un contacto que pueda verificar, un alcance que cubra su versión, avisos que nombren versiones corregidas y un historial de versiones que muestre que las correcciones salen.

Luego anote qué queda desconocido. Una revisión que lo dice es más útil que una que convierte una política ausente en una afirmación de seguridad.