Configurer security.txt pour la conformité CRA : un guide de 10 minutes

Sous le CRA, les fabricants doivent disposer d'un moyen publiquement accessible pour que les chercheurs et les clients puissent signaler des vulnérabilités. La norme en vigueur est RFC 9116 : un fichier texte brut appelé security.txt, hébergé à /.well-known/security.txt. Deux champs obligatoires, quelques champs recommandés, et environ 10 minutes de travail.

Ce guide couvre les champs, l'hébergement, les erreurs courantes, et ce que vous devez référencer dans votre dossier technique.

Qu'est-ce que security.txt ?

security.txt est une norme RFC (RFC 9116) qui fournit un moyen lisible par machine et par l'homme de publier des informations de contact sécurité.

Le CRA exige des fabricants qu'ils publient un contact pour le signalement des vulnérabilités. security.txt est la façon standard de le faire dans l'industrie. Les outils de scan automatisés et les chercheurs en sécurité le vérifient par défaut, et sa présence donne aux régulateurs un signal concret que vous avez mis en place des canaux de divulgation appropriés.

Le security.txt minimum viable

Voici le fichier conforme le plus simple :

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

C'est tout. Deux lignes. Vous êtes techniquement conforme.

Mais faisons mieux.

Le security.txt recommandé

Un security.txt complet :

# 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

Explication champ par champ

Contact (obligatoire)

Comment les chercheurs doivent vous joindre.

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

Utilisez un alias d'équipe, pas une adresse personnelle. Incluez à la fois une adresse e-mail et un formulaire web si vous en avez un. Plusieurs lignes Contact sont autorisées, et le formulaire vous permet une collecte structurée des signalements.

Expires (obligatoire)

À partir de quand ce fichier doit être considéré comme périmé.

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

Fixez la date à 6-12 mois dans le futur, au format ISO 8601 avec fuseau horaire. Mettez un rappel dans votre calendrier avant l'échéance. Un fichier périmé indique aux chercheurs que vous ne le maintenez pas.

Encryption (recommandé)

Clé PGP pour les rapports chiffrés.

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

Utilisez une clé d'équipe plutôt qu'une clé individuelle, et gardez la clé privée dans un HSM si possible. Incluez l'empreinte de la clé dans les commentaires pour que les chercheurs puissent la vérifier hors bande.

Preferred-languages (recommandé)

Les langues dans lesquelles votre équipe peut traiter les signalements.

Preferred-Languages: en, de, fr

Listez uniquement les langues que votre équipe sécurité maîtrise vraiment. Classez-les par ordre de préférence. Si vous listez l'allemand et que personne dans l'équipe ne lit l'allemand, vous recevrez des rapports que vous ne pourrez pas trier.

Canonical (recommandé)

L'emplacement faisant autorité de ce fichier.

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

Prévient l'usurpation et clarifie si le fichier est dupliqué. Les chercheurs peuvent vérifier l'URL canonique par rapport à ce qu'ils ont récupéré pour confirmer l'authenticité.

Policy (recommandé)

Lien vers votre politique complète de divulgation des vulnérabilités.

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

Assurez-vous que la page existe et se charge sans authentification. Un lien Policy mort lors d'un audit de sécurité ne fait pas bonne impression.

Acknowledgments (optionnel)

Lien vers votre Hall of Fame sécurité.

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

Les chercheurs qui trouvent des bugs sont souvent de bons candidats pour votre équipe sécurité. La reconnaissance encourage aussi davantage de signalements. La plupart des chercheurs privilégient les organisations qui reconnaissent leur travail.

Hiring (optionnel)

Lien vers vos offres d'emploi en sécurité.

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

Vaut la peine d'être inclus si vous avez des postes ouverts en sécurité. Les chercheurs en recherche active d'emploi consultent ces liens.

Configuration étape par étape

Étape 1 : créer le fichier

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

Étape 2 : choisir l'emplacement d'hébergement

Pour les sites web :

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

Pour les produits avec interfaces web :

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

Étape 3 : configurer votre serveur 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');
});

Hébergement statique (S3, GitHub Pages, etc.) : Placez simplement le fichier dans le répertoire .well-known.

Étape 4 : vérifier

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

Utilisez un validateur en ligne : https://securitytxt.org/

Étape 5 : signer (optionnel mais recommandé)

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

Pour les produits sans interfaces web

Appareils embarqués

Option 1 : Si l'appareil dispose d'une interface web :

• Hébergez security.txt sur cette interface
• http://device-ip/.well-known/security.txt

Option 2 : Si pas d'interface web :

• Incluez l'URL dans la documentation produit
• Référencez votre security.txt d'entreprise
• Ajoutez au Guide de Démarrage Rapide : "Signalez les problèmes de sécurité à : https://company.com/security"

Logiciels de bureau

• Incluez le contact sécurité dans Aide > À propos
• Ajoutez au README et à la documentation
• Référencez l'URL du security.txt d'entreprise

Applications mobiles

• Incluez dans Paramètres > À propos > Sécurité
• Liez vers le security.txt d'entreprise
• Ajoutez à la description de l'app store

Référence documentation

## 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

Erreurs courantes

Fichier expiré

Problème : La date Expires est dans le passé.

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

Correction : Fixez une date future. Ajoutez un rappel calendrier.

Mauvais emplacement

Problème : Fichier au mauvais chemin.

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

Correction : Utilisez l'emplacement standard.

Format invalide

Correction : Utilisez des dates ISO 8601, et des URIs mailto: ou https:.

Liens morts

Correction : Vérifiez que tous les liens fonctionnent. Vérifiez après chaque déploiement.

Email personnel

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

Correction : Utilisez un alias d'équipe qui survit aux changements de personnel.

Pas de HTTPS

Correction : Utilisez toujours HTTPS pour les URLs liées à la sécurité.

Liste de contrôle de validation

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

Calendrier de maintenance

Ce qui doit figurer dans votre dossier technique

Le CRA exige des fabricants qu'ils maintiennent un dossier technique (Annex VII) documentant leur processus de gestion des vulnérabilités. Votre fichier security.txt et la politique CVD vers laquelle il pointe sont des éléments directs de cette documentation.

Concrètement, votre dossier technique doit référencer :

• L'URL du security.txt et les méthodes de contact qu'il expose
• L'URL de la politique de divulgation vers laquelle il renvoie
• Les SLA de réponse auxquels vous vous êtes engagé dans cette politique

Les régulateurs qui examinent votre dossier technique cherchent des preuves qu'un processus de collecte des vulnérabilités fonctionnel existe. Un security.txt actif, non expiré, avec un lien Policy opérationnel est un signal concret. Un fichier expiré ou des liens morts jouent contre vous.

Ajoutez ce bloc à votre documentation de gestion des vulnérabilités :

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

Exemple complet

# ============================================================
# 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

Conseil : La configuration de security.txt prend 10 minutes et satisfait une exigence clé du CRA pour le contact de vulnérabilité publié. Faites-le aujourd'hui.

À noter : Votre security.txt doit inclure une méthode de contact, une langue préférée et une date d'expiration. Il doit se trouver à /.well-known/security.txt sur votre domaine.

Comment CRA Evidence aide

security.txt n'est qu'une pièce du processus de gestion des vulnérabilités. La partie plus difficile, c'est tout ce qui se trouve derrière : la politique, les SLA de triage, le signalement à ENISA, et la documentation dans votre dossier technique. C'est pour cela que CRA Evidence existe.

Commencez sur craevidence.com.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié.