security.txt para empresas: cómo recibir avisos de vulnerabilidades
Por Carlos Isidoro De Ayala Diaz ·
security.txt para empresas: cómo publicar un canal de reporte, definir alcance, validar avisos, coordinar correcciones y mantener la información vigente.
Publica un punto de contacto que las personas y las herramientas puedan encontrar
Cuando alguien detecta una posible vulnerabilidad, el primer problema puede ser descubrir quién debe recibir el aviso. Enviar detalles técnicos a un formulario comercial, a una cuenta sin vigilar o a varias personas retrasa la respuesta y aumenta la exposición de la información. El archivo security.txt ofrece un formato legible por máquinas para publicar el canal preferido y enlazar la política de divulgación. Ayuda a encontrar el camino correcto, pero no sustituye el proceso que debe existir detrás.
RFC 9116 sitúa el archivo en `/.well-known/security.txt` bajo HTTPS. Debe servirse como texto plano UTF-8 y contener al menos un campo `Contact` y un único campo `Expires`. El contacto usa una URI, por ejemplo `mailto:` o una página HTTPS. La fecha de caducidad indica cuándo la información debe considerarse obsoleta y el RFC recomienda que quede a menos de un año para forzar revisiones periódicas. Publicar un correo sin responsable o una fecha que nunca se renueva crea una falsa sensación de disponibilidad.
Campos opcionales permiten añadir la URL canónica del archivo, la política, los idiomas preferidos, un mecanismo de cifrado o una página de reconocimientos. `Canonical` ayuda a identificar la ubicación prevista; `Policy` dirige a las reglas completas y `Preferred-Languages` evita incertidumbre sobre el idioma. Una clave de cifrado se enlaza mediante una URI, no se pega como valor del campo. Solo deben incluirse opciones que la organización pueda mantener y atender.
El alcance del archivo merece atención. Según RFC 9116, el documento recuperado para un dominio o dirección se aplica a ese recurso y no automáticamente a sus subdominios o dominios padre. Una empresa con varios portales, marcas o proveedores debe decidir dónde publicar cada archivo y qué política enlazar. También comprueba redirecciones, tipo de contenido y respuesta desde fuera de su red. El objetivo es que una persona llegue a información actual y controlada, no que una ruta técnica exista solo sobre el papel.
Define una política que explique qué se puede reportar y cómo hacerlo
security.txt descubre el canal; la política establece expectativas. Debe identificar sistemas y productos incluidos, elementos fuera de alcance, tipos de prueba aceptados, acciones que podrían causar daño y datos que no deben recopilarse. También explica qué información ayuda a reproducir el problema: activo, versión, precondiciones, pasos, resultado observado, impacto y evidencias depuradas. Esta claridad mejora la calidad del informe sin pedir a quien reporta que amplíe una prueba hasta demostrar el máximo daño.
La política diferencia investigación de vulnerabilidades e incidentes en curso. RFC 9116 está pensado para respuesta a vulnerabilidades; una intrusión, una cuenta comprometida o una filtración activa necesita el canal de incidentes correspondiente. Mezclar ambos puede dejar una urgencia operativa en una cola preparada para análisis de producto. La página debe indicar qué hacer ante riesgo inmediato y cómo evitar enviar contraseñas, tokens, datos personales o copias completas de información afectada.
También se describen las reglas de comunicación y divulgación coordinada. ENISA define la divulgación coordinada como la colaboración entre quien encuentra el problema y las partes responsables para compartir información, preparar una solución y acordar la comunicación pública. La política puede indicar tiempos orientativos para acuse y actualización, pero no conviene prometer una fecha universal de corrección antes de conocer el alcance. Si intervienen proveedores, clientes o coordinadores, la empresa debe poder incorporarlos sin reenviar evidencias a destinatarios innecesarios.
Publicar una política no implica ofrecer una recompensa económica ni autoriza cualquier actividad. Un programa de recompensas necesita reglas, elegibilidad, importes y operación propias. Las condiciones jurídicas también dependen del país, del sistema y de la conducta concreta; una plantilla extranjera no debe copiarse como garantía legal. La organización puede explicar el comportamiento de buena fe que espera y su forma de coordinación, sometiendo el texto definitivo a la revisión interna que corresponda.
Convierte cada aviso en un caso trazable con una primera respuesta útil
El canal necesita vigilancia y una persona suplente. Cada mensaje recibe un identificador, fecha, activo, versión, contacto del remitente, estado y responsable. Un acuse útil confirma que llegó, indica el siguiente paso y evita pedir que se repita la prueba. Si el informe carece de información, se solicita solo lo necesario y por un canal adecuado. FIRST incluye la recepción y clasificación entre las funciones básicas de un equipo de respuesta de seguridad de producto, incluso cuando el volumen es reducido.
La primera revisión separa alcance, autenticidad y urgencia. Se comprueba que el activo pertenezca a la organización o a un producto soportado, que la versión sea relevante y que la evidencia no sea un falso positivo evidente. Después se intenta reproducir en un entorno controlado con datos sintéticos. No se ejecutan archivos, enlaces o instrucciones del mensaje en equipos de producción sin analizarlos. El hecho de que alguien use vocabulario técnico o adjunte una puntuación no convierte la conclusión en válida por sí sola.
La prioridad combina impacto, exposición, facilidad de explotación, usuarios afectados y controles existentes. CVSS puede aportar una descripción técnica, pero la empresa debe relacionarla con su contexto. Un problema de acceso entre clientes puede ser urgente aunque el sistema no esté publicado en Internet; una versión detectada por una herramienta puede no ser explotable en la configuración real. El registro conserva los motivos de la decisión y la información que falta, evitando que una valoración verbal se pierda al cambiar de responsable.
La comunicación con quien reporta debe proteger la evidencia. Se depuran capturas, peticiones y respuestas antes de incorporarlas al gestor interno y se limita su acceso. Si se ofrece cifrado, alguien debe poder descifrar y contestar; una clave abandonada bloquea el canal. También se informa cuando el caso queda duplicado, fuera de alcance o no reproducido, con una explicación suficiente para reducir malentendidos sin revelar detalles internos. La cortesía y la trazabilidad ayudan a conservar una relación de colaboración.
Coordina la corrección, la comprobación y el mantenimiento del canal
Una vez confirmado el problema, se asignan responsables técnicos y de negocio, versión afectada, medida temporal y criterio de aceptación. La corrección se prueba contra la evidencia original y frente a efectos secundarios. Si interviene una biblioteca o un proveedor, se coordina qué parte corrige cada uno y qué información puede compartirse. FIRST recomienda relacionar análisis, remediación y divulgación para que las partes afectadas reciban suficiente información y puedan proteger sus sistemas.
La comunicación pública se prepara según impacto, disponibilidad de solución y usuarios afectados. Puede adoptar la forma de una nota de versión, un aviso de seguridad o una comunicación dirigida. Identifica versiones, riesgo, mitigación, actualización y referencias; no necesita publicar instrucciones que aumenten el daño antes de que exista remedio. El reconocimiento a quien informó se acuerda con esa persona. Cerrar internamente el ticket no sustituye avisar a quienes deben aplicar la corrección.
El propio security.txt forma parte del mantenimiento. Antes de `Expires` se verifica que contacto, política, idiomas, claves y URL sigan vigentes. La comprobación puede automatizar estado HTTP, tipo de contenido, sintaxis y fecha, mientras una revisión humana confirma que la cola se atiende. También se prueba una entrega controlada desde fuera: recepción, ticket, aviso al responsable y respuesta. Un archivo válido que conduce a un buzón sin monitorizar falla en su finalidad aunque supere un validador.
Élite Solutions Tech puede ayudar desde Murcia a definir el canal, documentar el flujo de recepción y preparar informes técnicos para empresas regionales y proyectos nacionales. La propuesta concreta activos, responsables, política, clasificación, coordinación, evidencias y mantenimiento; no presenta security.txt como certificación ni como protección frente a ataques. Para una primera reunión basta indicar qué productos o portales deben cubrirse y quién puede recibir un aviso crítico. Los detalles sensibles se coordinan después por un canal autorizado.