Planteamiento y alcance
Esta pregunta de entrevista general evalúa si puedes integrar un pequeño archivo público dentro de un flujo de trabajo completo de operaciones de seguridad. El objetivo no es recitar campos de memoria; es conectar el punto de entrada de reportes, el límite de autorización, la propiedad de la respuesta y las promesas de la política.
Qué está evaluando el entrevistador
- Si conoces la ubicación
/.well-known/security.txty los campos obligatorios del RFC 9116. - Si puedes distinguir entre descubrimiento, validación, divulgación coordinada y respuesta a emergencias.
- Si evitas publicar un buzón desatendido, una clave privada o una promesa de tiempo de respuesta sin un responsable asignado.
- Si puedes diseñar la asignación de guardias (on-call), tickets, deduplicación y actualizaciones de estado que hagan funcionar el punto de entrada.
Preguntas de aclaración que se deben hacer
Primero, confirma qué dominios y productos están dentro del alcance, si varios equipos son dueños de los activos, si se aceptan activos alojados por terceros, quién está de guardia para cada canal, qué pruebas están autorizadas y si ya existe una política de divulgación de vulnerabilidades. Aclara también si el objetivo es únicamente la visibilidad o si también incluye recompensas, envíos cifrados y fechas de divulgación coordinada.
Estructura para una respuesta de 30 segundos
Publicaría un archivo de texto plano en UTF-8 en /.well-known/security.txt mediante HTTPS para cada activo público. Mantendría un Contact válido y un Expires en una fecha futura, y luego añadiría Policy, Canonical, Encryption o Acknowledgments solo cuando esos procesos realmente existan. El archivo solo ayuda al investigador a encontrar el punto de entrada; el backend aún requiere alcance de autorización, propiedad de guardia, tickets, deduplicación, evaluación de severidad y comunicación segura del estado. Antes del lanzamiento, verificaría HTTPS, la expiración, los permisos de los enlaces y la rotación de responsables.
Solución paso a paso
1. Definir los activos y el límite del punto de entrada
Haz una lista del dominio principal, los dominios de productos y las API de alto riesgo que necesitan cobertura, en lugar de colocar un único archivo solo en la página principal de marketing. Contact debe apuntar a un buzón o formulario HTTPS que realmente pueda procesar reportes; un buzón personal desatendido no debe ser la única vía. Si diferentes equipos son dueños de los activos, documenta cómo se enruta el reporte.
2. Poblar y validar continuamente los campos del RFC 9116
Contact y Expires son obligatorios; Expires debe indicar una fecha y hora de expiración futura. Policy puede enlazar a las reglas de pruebas autorizadas y divulgación, Canonical puede identificar el archivo canónico, Encryption solo corresponde si existe una clave pública con mantenimiento activo, y Acknowledgments o Hiring son opcionales. Sirve el archivo en HTTPS /.well-known/security.txt como text/plain, sin depender de renderizado HTML.
3. Conectar el archivo al flujo de trabajo de respuesta
Cuando llegue un reporte, crea un identificador de ticket impredecible y registra la hora de recepción, el activo, los pasos de reproducción y la preferencia de comunicación del investigador. La persona de guardia primero comprueba el alcance de autorización, luego deduplica, evalúa el impacto y asigna un responsable. Los reportes de alto riesgo entran en una vía de emergencia; los reportes normales utilizan la cola habitual, con un registro de auditoría para ambos.
4. Redactar una política de divulgación en lugar de inventar un SLA
La política debe explicar las investigaciones permitidas, los comportamientos prohibidos, la transferencia segura de material confidencial, las recompensas si las hubiera, cuándo se permite la divulgación pública y cómo se gestionan las pruebas de buena fe. Pon por escrito únicamente tiempos de acuse de recibo y ritmos de actualización que sean sostenibles. No interpretes un campo del RFC como una promesa de que cada reporte se solucionará en un número determinado de horas.
5. Proteger el punto de entrada y los datos del reporte
El archivo público no debe contener claves privadas, nombres de host internos, números de teléfono personales ni detalles de incidentes no publicados. Limita los tipos y tamaños de los archivos adjuntos, restringe el acceso a los sistemas de correo y tickets, y trata los scripts y enlaces del reporte sin procesar como entradas no confiables. El equipo de seguridad puede mantener un contexto interno más amplio, mientras que las respuestas al reportante divulgan únicamente hechos aprobados.
6. Demostrar que el punto de entrada funciona mediante observabilidad
Monitorea la respuesta 200 del archivo, el certificado HTTPS, el tiempo hasta Expires, la rotación de guardias y la conversión de formularios a tickets. Utiliza reportes de prueba inofensivos para verificar alertas, deduplicación y escalamiento; nunca uses una vulnerabilidad real para un simulacro. Comprueba que las CDN, las redirecciones y los despliegues multirregión no sirvan una copia antigua o expirada.
Respuesta de ejemplo de alta calidad
Primero listaría los dominios públicos que necesitan cobertura y publicaría un archivo de texto plano en UTF-8 en HTTPS /.well-known/security.txt para cada uno de ellos. Contact apuntaría a un buzón o formulario atendido por personal, mientras que Expires se fijaría en el futuro y estaría cubierto por una alerta de expiración. Añadiría Policy, Canonical o Encryption solo cuando esos procesos y claves tengan mantenimiento activo. El archivo no prometería un plazo límite de reparación; la política establecería el alcance autorizado, los comportamientos prohibidos, la transferencia de material confidencial, las recompensas y la divulgación coordinada. Los reportes ingresarían a un sistema de tickets restringido para la verificación del alcance, deduplicación, evaluación de severidad y asignación de responsables, con una vía de emergencia para casos de alto riesgo. Verificaría HTTPS, almacenamiento en caché, permisos, cobertura de guardias y renovación antes del lanzamiento, y luego monitorearía la accesibilidad, la conversión a tickets y los estados de respuesta. El archivo hace que el canal sea localizable; el flujo de trabajo y la propiedad proporcionan la capacidad de seguridad.
Errores comunes
- Crear el archivo sin un responsable de guardia, cola de tickets o vía de escalamiento.
- Omitir
Expires, dejando a los investigadores con información de contacto que tal vez ya no funcione. - Publicar una clave privada, una dirección interna o un número de teléfono personal.
- Prometer un SLA de reparación, un monto de recompensa o una fecha de divulgación que el equipo no pueda sostener.
- Reemplazar un punto de entrada HTTPS estable con HTTP, una redirección a inicio de sesión o una copia desactualizada en CDN.
- Publicar detalles de reproducción antes de haber verificado la autorización y el impacto.
Preguntas de seguimiento y respuestas
¿Puede security.txt reemplazar una política de divulgación de vulnerabilidades?
No. Ayuda a los investigadores a descubrir los enlaces de Contact y Policy; el alcance de autorización, las pruebas de buena fe, las recompensas, la coordinación de la divulgación y las reglas de emergencia aún pertenecen a la política.
¿Por qué es necesario Expires?
Los contactos y los procesos cambian. Expires permite que las comprobaciones automatizadas identifiquen un archivo que podría estar desactualizado para que el equipo lo renueve, en lugar de dejar un buzón antiguo aparentando ser válido indefinidamente.
¿Qué pasa si un grupo tiene muchos dominios de productos?
Publica el archivo correspondiente para cada dominio de propiedad independiente y utiliza enlaces Canonical o de política para explicar la fuente autoritativa. Cada punto de entrada debe llegar a un equipo capaz de enrutar los reportes; copiar una dirección desatendida no es suficiente.
¿Cuál es el primer paso después de que un investigador reporta un presunto zero-day?
Restringe el acceso al reporte, confirma la fuente y el alcance del activo, registra la hora y la evidencia, y notifica al responsable de seguridad para una evaluación de impacto de emergencia. No reenvíes detalles no verificados a un canal público ni le pidas al investigador que amplíe las pruebas solo para hacer el reporte más completo.