Configuración de security.txt para cumplimiento del CRA: una guía de 10 minutos

Bajo el CRA, los fabricantes necesitan un canal público accesible para que investigadores y clientes notifiquen vulnerabilidades. El estándar es RFC 9116: un archivo de texto plano llamado security.txt alojado en /.well-known/security.txt. Dos campos obligatorios, algunos recomendados y unos 10 minutos de trabajo.

Esta guía cubre los campos, el alojamiento, los errores comunes y lo que necesitas referenciar en tu expediente técnico.

¿Qué es security.txt?

security.txt es un estándar RFC (RFC 9116) que proporciona una forma legible por máquinas y por personas de publicar información de contacto de seguridad.

El CRA requiere que los fabricantes publiquen un contacto para la notificación de vulnerabilidades. security.txt es la forma estándar de la industria para hacerlo. Las herramientas de análisis automatizado y los investigadores de seguridad lo buscan por defecto, y tenerlo publicado da a los reguladores una señal concreta de que has establecido canales de divulgación adecuados.

El security.txt mínimo viable

El archivo conforme más simple:

Contact: mailto:security@yourcompany.com
Expires: 2027-12-31T23:59:59.000Z

Eso es todo. Dos líneas. Técnicamente cumple.

Pero hagámoslo mejor.

El security.txt recomendado

Un security.txt completo:

# Security Contact Information for [Your Company]
# https://www.yourcompany.com/.well-known/security.txt

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Preferred-Languages: en, de, fr
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/disclosure-policy
Hiring: https://yourcompany.com/careers/security
Acknowledgments: https://yourcompany.com/security/thanks

Explicación campo por campo

Contact (obligatorio)

Cómo deben contactarte los investigadores.

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report

Usa un alias de equipo, no un correo personal. Incluye tanto una dirección de correo como un formulario web si dispones de uno. Se permiten varias líneas Contact, y el formulario te proporciona una entrada estructurada.

Expires (obligatorio)

Cuándo debe considerarse obsoleto este archivo.

Expires: 2027-01-01T00:00:00.000Z

Establécelo con 6-12 meses de margen en formato ISO 8601 con zona horaria. Programa un recordatorio en el calendario antes de que llegue esa fecha. Un archivo obsoleto indica a los investigadores que no lo estás manteniendo.

Encryption (recomendado)

Clave PGP para informes cifrados.

Encryption: https://yourcompany.com/.well-known/pgp-key.txt

Usa una clave de equipo en lugar de una individual, y mantén la clave privada en un HSM si puedes. Incluye la huella digital en los comentarios para que los investigadores puedan verificarla de forma independiente.

Preferred-Languages (recomendado)

Idiomas en los que tu equipo puede gestionar los informes.

Preferred-Languages: en, de, fr

Lista solo los idiomas en los que tu equipo de seguridad puede responder realmente. Ordénalos por preferencia. Si listas alemán y nadie del equipo lee alemán, recibirás informes que no podrás clasificar.

Canonical (recomendado)

La ubicación autorizada de este archivo.

Canonical: https://yourcompany.com/.well-known/security.txt

Previene suplantaciones y aclara si el archivo está replicado. Los investigadores pueden verificar la URL canónica frente a lo que descargaron para confirmar su autenticidad.

Policy (recomendado)

Enlace a tu política completa de divulgación de vulnerabilidades.

Policy: https://yourcompany.com/security/disclosure-policy

Asegúrate de que la página existe y se carga sin autenticación. Un enlace Policy caído durante una revisión de seguridad no es buena imagen.

Acknowledgments (opcional)

Enlace a tu hall de la fama de seguridad.

Acknowledgments: https://yourcompany.com/security/thanks

Los investigadores que encuentran fallos son a menudo buenos candidatos para tu equipo de seguridad. El reconocimiento también fomenta más informes. La mayoría de los investigadores dan prioridad a las organizaciones que reconocen su trabajo.

Hiring (opcional)

Enlace a ofertas de trabajo en seguridad.

Hiring: https://yourcompany.com/careers/security

Vale la pena incluirlo si tienes puestos de seguridad abiertos. Los investigadores que buscan trabajo activamente comprueban estos enlaces.

Configuración paso a paso

Paso 1: crear el archivo

cat > security.txt << 'EOF'
# Security Contact Information for YourCompany
# Last Updated: 2026-01-15

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-15T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/policy
EOF

Paso 2: elegir la ubicación de alojamiento

El archivo debe estar en /.well-known/security.txt

Para sitios web:

https://yourcompany.com/.well-known/security.txt

Para productos con interfaces web:

https://product.local/.well-known/security.txt
https://192.168.1.1/.well-known/security.txt

Paso 3: configurar tu servidor web

Nginx:

location /.well-known/security.txt {
    alias /var/www/security.txt;
    default_type text/plain;
}

Apache:

Alias /.well-known/security.txt /var/www/security.txt
<Files "security.txt">
    ForceType text/plain
</Files>

Express.js:

const express = require('express');
const app = express();

app.get('/.well-known/security.txt', (req, res) => {
    res.type('text/plain');
    res.sendFile(__dirname + '/security.txt');
});

Alojamiento estático (S3, GitHub Pages, etc.): Coloca el archivo en el directorio .well-known.

Paso 4: verificar

curl https://yourcompany.com/.well-known/security.txt

Usa un validador en línea: https://securitytxt.org/

Paso 5: firmar (opcional pero recomendado)

gpg --clearsign security.txt
mv security.txt.asc security.txt

El archivo firmado tiene este aspecto:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@yourcompany.com
Expires: 2027-01-01T00:00:00.000Z
...

-----BEGIN PGP SIGNATURE-----
[signature data]
-----END PGP SIGNATURE-----

Para productos sin interfaces web

No todos los productos tienen servidores web. Así es como gestionar security.txt en esos casos:

Dispositivos embebidos

Opción 1: Si el dispositivo tiene alguna interfaz web (página de configuración, página de estado):

• Aloja security.txt en esa interfaz
• http://device-ip/.well-known/security.txt

Opción 2: Si no hay interfaz web:

• Incluye la URL en la documentación del producto
• Referencia tu security.txt corporativo
• Añade a la guía de inicio rápido: "Notifica problemas de seguridad en: https://company.com/security"

Software de escritorio

• Incluye el contacto de seguridad en Ayuda > Acerca de
• Añade al README/documentación
• Referencia la URL del security.txt corporativo

Aplicaciones móviles

• Incluye en Ajustes de la app > Acerca de > Seguridad
• Enlaza al security.txt corporativo
• Añade a la descripción en la tienda de aplicaciones

Referencia en documentación

## Security Vulnerability Reporting

To report security vulnerabilities in this product:

- Email: security@yourcompany.com
- Web: https://yourcompany.com/security/report
- Policy: https://yourcompany.com/security/policy

Our security.txt file: https://yourcompany.com/.well-known/security.txt

Errores comunes

Archivo vencido

Problema: La fecha de Expires está en el pasado.

Expires: 2024-01-01T00:00:00.000Z  # EXPIRED!

Solución: Establece una fecha futura. Añade un recordatorio en el calendario.

Ubicación incorrecta

Problema: El archivo está en una ruta incorrecta.

/security.txt           # Wrong
/security/security.txt  # Wrong
/.well-known/security.txt  # Correct

Solución: Usa la ubicación estándar.

Formato inválido

Problema: Formato de fecha incorrecto, campos faltantes.

Expires: January 1, 2027  # Wrong format
Contact: security team    # Not a valid URI

Solución: Usa fechas ISO 8601, URIs de tipo mailto: o https:.

Enlaces rotos

Problema: Las URLs de Policy o Acknowledgments devuelven 404.

Solución: Verifica que todos los enlaces funcionan. Compruébalos después de cada despliegue.

Correo personal

Problema: Usar el correo de una persona en lugar de un alias de equipo.

Contact: mailto:john.smith@yourcompany.com  # Bad

Solución: Usa un alias de equipo que sobreviva a los cambios de personal.

Sin HTTPS

Problema: Usar HTTP en lugar de HTTPS en los enlaces Canonical/Policy.

Solución: Usa siempre HTTPS para URLs relacionadas con seguridad.

Lista de verificación de validación

SECURITY.TXT VALIDATION CHECKLIST

REQUIRED FIELDS:
[ ] Contact field present (mailto: or https:)
[ ] Expires field present (future date, ISO 8601)

RECOMMENDED FIELDS:
[ ] Preferred-Languages included
[ ] Canonical URL matches actual location
[ ] Policy link works and points to CVD policy
[ ] Encryption key link works (if included)

HOSTING:
[ ] File at /.well-known/security.txt
[ ] HTTPS accessible
[ ] Content-Type: text/plain
[ ] No authentication required

VERIFICATION:
[ ] curl test successful
[ ] Online validator passes
[ ] Links all resolve (no 404s)
[ ] PGP signature valid (if signed)

MAINTENANCE:
[ ] Calendar reminder set for before Expires date
[ ] Update process documented
[ ] Monitoring for accessibility

Calendario de mantenimiento

Qué incluir en tu expediente técnico

El CRA requiere que los fabricantes mantengan un expediente técnico (Annex VII) que documente su proceso de gestión de vulnerabilidades. El archivo security.txt y la política CVD a la que enlaza son entradas directas a esa documentación.

En concreto, tu expediente técnico debe referenciar:

• La URL de security.txt y los métodos de contacto que expone
• La URL de la política de divulgación a la que enlaza
• Los SLA de respuesta que has comprometido en esa política

Los reguladores que revisan tu expediente técnico buscan evidencia de que existe un proceso de recepción de vulnerabilidades en funcionamiento. Un security.txt activo, no vencido, con un enlace Policy operativo es una señal concreta. Un archivo vencido o enlaces rotos juegan en tu contra.

Añade este bloque a tu documentación de gestión de vulnerabilidades:

Vulnerability Reporting Contact Points:
- security.txt: https://company.com/.well-known/security.txt
- Email: security@company.com
- Web Form: https://company.com/security/report
- Policy: https://company.com/security/policy

Ejemplo completo

# ============================================================
# SECURITY.TXT for AcmeTech Products
# https://acmetech.eu/.well-known/security.txt
# ============================================================

Contact: https://acmetech.eu/security/report
Contact: mailto:security@acmetech.eu
Expires: 2027-06-01T00:00:00.000Z
Encryption: https://acmetech.eu/.well-known/pgp-key.txt
Preferred-Languages: en, de, es
Canonical: https://acmetech.eu/.well-known/security.txt
Policy: https://acmetech.eu/security/disclosure-policy
Acknowledgments: https://acmetech.eu/security/hall-of-fame
Hiring: https://acmetech.eu/careers#security

Cómo ayuda CRA Evidence

security.txt es una pieza del proceso de gestión de vulnerabilidades. La parte más compleja es el proceso completo que hay detrás: la política, los SLA de clasificación, la notificación a ENISA y documentarlo todo en tu expediente técnico. Para eso está CRA Evidence.

Empieza en craevidence.com.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica sobre cumplimiento, consulta con asesores legales cualificados.