Un lugar fácil de encontrar
Alguien observa un posible problema en su web y quiere comunicarlo. Tener que buscar entre ventas, soporte y varios proveedores introduce retrasos evitables. Un canal claro ayuda a ambas partes: quien informa encuentra un destinatario y la empresa recibe un aviso que puede evaluar.
El RFC 9116 describe security.txt. Para servicios web, el archivo se publica mediante HTTPS en /.well-known/security.txt. Contact y Expires son campos obligatorios.
Empiece con un inventario sencillo: qué dominios públicos pertenecen a su empresa, quién los opera y adónde deben llegar los avisos de cada uno. Acuerde el contacto publicado con las personas que realmente tramitarán los mensajes. [1]
Asignar una persona responsable del buzón
Designe un responsable y un sustituto. Acuerde quién revisa los mensajes, quién evalúa las cuestiones técnicas y quién cubre las ausencias. Si participan varios proveedores, deje claro qué servicio corresponde a cada uno.
Organice una prueba de entrega inocua y expresamente acordada, con un asunto reconocible. Compruebe algo más que el éxito del envío: ¿llega el mensaje al buzón previsto, entra en el proceso de gestión y puede responder el responsable? Un archivo accesible no demuestra por sí solo estas condiciones.
Puede bastar un ticket compartido o una referencia interna. Registre la hora de recepción, el servicio afectado, la persona responsable y la siguiente acción. Evite reenviar información sensible a listas de distribución innecesariamente amplias.
El recorrido de un aviso
La ilustración distingue cuatro tareas. El archivo publicado indica el contacto. La entrada recibe el aviso. Una persona asignada comprueba si afecta a los sistemas de la empresa. Una respuesta permite continuar la conversación.
También un equipo pequeño puede trabajar así. Cada traspaso debe ser explícito: quién tiene el caso, qué pregunta sigue abierta y cuándo se revisará la siguiente acción. Si un proveedor opera el servicio afectado, incluya el traspaso a ese proveedor.
/.well-known/security.txt
Accesible públicamente
Contact:Dirección o formulario de notificación
Expires:Fin de validez de los datos publicados
Recepción
Registrar el aviso y confirmar su recepción.
Responsabilidad
Identificar el servicio afectado y su responsable.
Respuesta
Registrar el siguiente paso y un canal de respuesta.
El archivo permite encontrar el canal. La asignación y el seguimiento se organizan dentro de la empresa.
Un contacto acompañado de reglas claras
Publicar una dirección de contacto no equivale, por sí mismo, a encargar una evaluación de seguridad. Separe la comunicación de una observación del permiso para realizar pruebas adicionales.
El NCSC recomienda una política de divulgación clara: canales de contacto, información requerida, respuesta prevista y límites de las investigaciones permitidas.
Para el primer mensaje recomendamos la dirección afectada, una descripción breve y el momento de la observación. No hacen falta contraseñas ni grandes conjuntos de datos personales. Si se necesitan más pruebas, acuerde un medio de transferencia apropiado. Publique únicamente plazos de respuesta que su equipo pueda cumplir. [2]
Revisarlo cuando cambian las responsabilidades
Trate el contacto de seguridad como un dato operativo. Incluya su revisión en las listas de control de migraciones de dominios, cambios de proveedor y salidas de personal. Programe una revisión antes de que caduquen los datos publicados.
Una comprobación periódica puede ser breve: consultar el archivo público, contrastar los datos con las responsabilidades internas y revisar el canal acordado. Anote el resultado y la fecha. Así, un archivo publicado una vez se convierte en un canal mantenido para recibir avisos útiles.
Compruebe los campos y la respuesta HTTP
Para servicios web, el archivo debe servirse por HTTPS en /.well-known/security.txt como texto UTF-8 con el tipo text/plain. Una página de error HTML con estado 200 no es un security.txt válido. Revise el contenido y las cabeceras de respuesta juntos.
El alcance es específico: un archivo en example.com no cubre automáticamente sus subdominios. Inventaríe cada host previsto. Los campos siguientes son una selección, no una comprobación completa de conformidad con RFC 9116. [1]
Deslice la tabla horizontalmente para leerla.
| Campo | Requisito | Comprobación práctica |
|---|---|---|
| Contact | Obligatorio; al menos una URI de contacto. | Use mailto: para correo; acuerde y verifique antes una prueba de recepción. |
| Expires | Obligatorio; una sola marca temporal RFC 3339. | Compruebe la vigencia y programe la renovación; se recomienda menos de un año en el futuro. |
| Preferred-Languages | Opcional; idiomas realmente admitidos. | Incluya solo idiomas en los que puedan tramitarse avisos. |
| Canonical | Opcional; dirección HTTPS prevista del archivo. | Compárela con la dirección real de consulta. |
| Policy | Opcional; enlace a la política de divulgación. | Explique el canal, el alcance autorizado y el seguimiento. |
Documente la revisión y asigne responsables
La lista editable conecta el archivo público con el proceso interno. Utilice una copia por dominio, anote resultados observados y programe otra revisión. No es un escáner automático ni certifica por sí sola una configuración segura.