Version actuelle : TSD 1.0.0
Dernière mise à jour : 16 décembre 2024

1. Versions Supportées
2. Reporting d'une Vulnérabilité
3. Process de Gestion
4. Divulgation Responsable
5. Best Practices de Déploiement
6. Hall of Fame
7. Ressources
8. Contact

Nous prenons la sécurité de TSD très au sérieux. Voici les versions actuellement supportées avec des mises à jour de sécurité :

Version actuelle (1.x) :

• Correctifs de sécurité pour toutes les vulnérabilités
• Mises à jour régulières et patches mineurs
• Support complet et documentation

Version précédente (0.x) :

• Correctifs uniquement pour vulnérabilités critiques et hautes
• Support limité jusqu'au 30 juin 2025
• Migration fortement recommandée vers 1.0.x

Versions obsolètes (< 0.x) :

• Aucun support
• Aucun correctif de sécurité
• Mise à jour obligatoire

À partir de la version 1.0, nous suivons :

• Version majeure actuelle : Support complet
• Version majeure N-1 : Support de sécurité pendant 6 mois après release N+1
• Versions plus anciennes : Fin de support

Si vous découvrez une vulnérabilité de sécurité dans TSD, merci de NE PAS créer d'issue publique sur GitHub. Cela pourrait mettre en danger les utilisateurs du projet.

Option 1 - GitHub Security Advisory (recommandé) :

1. Accédez à la page Security du projet GitHub
2. Cliquez sur "Report a vulnerability"
3. Remplissez le formulaire privé avec les détails

Option 2 - Email sécurisé :

• Créez une issue privée via GitHub Security Advisory
• Ou contactez directement les mainteneurs du projet via GitHub

Option 3 - Communication directe :

• Contactez directement les mainteneurs du projet
• Demandez un canal de communication privé

Pour nous aider à traiter rapidement et efficacement votre rapport, veuillez inclure :

Template de Rapport :

```markdown Sujet : [SECURITY] [Gravité: Critique/Haute/Moyenne/Basse] Description courte

Brève description de la vulnérabilité (1-2 lignes)

• Gravité : Critique / Haute / Moyenne / Basse (selon CVSS)
• CVSS Score : X.X (si calculé)
• Type : Injection / XSS / CSRF / DoS / Autre
• Vecteur d'attaque : Local / Adjacent / Network / Physical
• Privilèges requis : None / Low / High
• Interaction utilisateur : None / Required

Description de l'impact : [Que peut faire un attaquant ? Quelles données sont compromises ?]

[Description détaillée de la vulnérabilité]

Composants affectés :

• Module : [rete / constraint / auth / autre]
• Fichier(s) : [chemin/vers/fichier.go]
• Fonction(s) : [NomFonction()]
• Ligne(s) : [numéros de lignes]

Prérequis :

• TSD version : X.X.X
• OS : Linux / macOS / Windows
• Go version : 1.21+
• Configuration particulière : [si applicable]

Étapes :

1. [Étape détaillée 1]
2. [Étape détaillée 2]
3. [Étape détaillée 3] ...

Résultat obtenu : [Ce qui se passe actuellement]

Résultat attendu : [Ce qui devrait se passer]

```go // Code de démonstration ```

```bash

```

Logs / Captures d'écran : [Si applicable, joindre logs ou captures]

• TSD v1.0.0 : ✅ Vulnérable
• TSD v0.9.x : ✅ Vulnérable
• TSD v0.8.x : ❓ Non testé
• TSD < 0.8 : ❓ Non testé

[Optionnel : vos idées pour corriger la vulnérabilité]

Patch proposé : ```go // Si vous avez un correctif ```

• [CVE similaires]
• [Documentation technique]
• [Articles de recherche]

• Nom/Pseudo : [votre nom ou pseudo]
• Organisation : [optionnel]
• Email : [pour communication]
• Préférence de crédit : Public / Anonyme / Pseudo uniquement ```

Nous nous engageons à :

• Accusé de réception : Sous 48 heures (2 jours ouvrés)
• Évaluation initiale : Sous 7 jours
• Plan de correction :
  • Critique : 7 jours
  • Haute : 14 jours
  • Moyenne : 30 jours
  • Basse : 60 jours

Note : Ces délais sont des objectifs. Nous communiquerons régulièrement sur l'avancement.

``` J+0 → Réception ↓ J+2 → Accusé de réception + ID de tracking ↓ J+7 → Évaluation (reproduction, gravité CVSS, versions affectées) ↓ J+14-60 → Développement correctif (selon gravité) ↓ → Tests de non-régression ↓ → Review interne sécurité ↓ J+30-90 → Coordination avec reporter ↓ → Validation du correctif ↓ → Planification release ↓ J+45-120 → Publication ↓ → Release version corrigée ↓ → Advisory de sécurité publique ↓ → Notification utilisateurs ↓ → Clôture ```

• Réception du rapport
• Attribution d'un identifiant unique (ex: TSD-SEC-2024-001)
• Assignation à un responsable sécurité

• Confirmation de réception au reporter
• Fourniture de l'ID de tracking
• Demande de clarifications si nécessaire

• Reproduction : Validation que la vulnérabilité existe
• Gravité : Calcul du score CVSS v3.1
• Périmètre : Identification des versions affectées
• Impact : Évaluation de l'impact réel
• Classification : Attribution du niveau de priorité

Selon la gravité :

Processus de développement :

• Création d'une branche privée
• Développement du correctif
• Tests unitaires et d'intégration
• Tests de non-régression complets
• Review de code sécurité (double validation)
• Validation par au moins 2 mainteneurs

• Communication avec le reporter :
  • Partage du correctif pour validation
  • Accord sur le timing de divulgation
  • Discussion sur les crédits
• Préparation de l'advisory :
  • Rédaction de l'advisory de sécurité
  • Identification CVE si applicable
  • Préparation des release notes

• Release :
  • Publication de la version corrigée
  • Tag git avec mention sécurité
  • Build et distribution des binaires
• Advisory :
  • Publication GitHub Security Advisory
  • Entrée dans CHANGELOG.md
  • Notification sur les canaux du projet
• Communication :
  • Annonce sur GitHub Discussions/Issues (pinned)
  • Email aux utilisateurs connus (si liste existe)
  • Mise à jour de la documentation

Pendant tout le processus :

• Mises à jour régulières au reporter (au moins hebdomadaires)
• Transparence sur les délais et obstacles
• Coordination étroite pour la divulgation

Nous demandons aux chercheurs en sécurité de respecter les principes suivants :

• Garder la confidentialité : Ne pas divulguer publiquement la vulnérabilité avant notre accord
• Délai raisonnable : Nous laisser un délai suffisant pour corriger (selon gravité)
• Coordonner : Travailler avec nous pour la divulgation publique
• Communication privée : Utiliser uniquement les canaux sécurisés listés
• Bienveillance : Agir de bonne foi pour protéger les utilisateurs

• Exploitation : Ne pas exploiter la vulnérabilité à des fins malveillantes ou personnelles
• Divulgation prématurée : Ne pas divulguer publiquement avant notre accord
• Accès non autorisé : Ne pas accéder aux données utilisateurs ou systèmes de production
• Déni de service : Ne pas lancer d'attaques DoS ou perturber le service
• Escalade : Ne pas effectuer d'actions au-delà du nécessaire pour démontrer la vulnérabilité

Nous nous engageons à :

• ✅ Ne pas poursuivre légalement les chercheurs qui suivent cette politique
• ✅ Travailler de bonne foi avec la communauté sécurité
• ✅ Respecter les délais convenus pour la divulgation
• ✅ Créditer publiquement les découvertes (sauf demande d'anonymat)
• ✅ Traiter tous les rapports avec sérieux et respect

Activités autorisées dans le cadre de la recherche :

• Tests sur votre propre installation locale de TSD
• Analyse statique du code source
• Review de code pour identifier des vulnérabilités potentielles
• Proof of Concept démontrant la vulnérabilité (sans exploitation réelle)

Activités interdites :

• Tests sur des instances de production sans autorisation
• Accès à des données utilisateurs réelles
• Attaques par déni de service
• Social engineering des utilisateurs ou mainteneurs

Nous créditons publiquement les chercheurs qui :

• Reportent de manière responsable via les canaux appropriés
• Respectent notre processus de divulgation coordonnée
• Le souhaitent (nous respectons l'anonymat si demandé)

Les crédits sont inclus dans :

1. GitHub Security Advisory : Nom/pseudo du reporter
2. CHANGELOG.md : Section dédiée aux contributions sécurité
3. Release Notes : Mention dans les notes de version
4. Hall of Fame : Section ci-dessous de ce document
5. Commit message : Attribution dans le message de commit du correctif

Options de crédit :

• Nom complet + organisation
• Pseudo uniquement
• Lien vers profil GitHub/Twitter
• Anonyme (aucune mention publique)

Nous travaillons avec le reporter pour :

1. Valider le correctif : Le reporter peut tester la version corrigée avant publication
2. Timing : Coordonner la date et heure de divulgation publique
3. Contenu : Rédiger conjointement l'advisory si souhaité
4. Communication : Décider du niveau de détail à divulguer
5. CVE : Coordonner l'attribution CVE si applicable

Délais de divulgation par défaut :

Note : Ces délais peuvent être ajustés en accord avec le reporter.

JWT et API Keys :

```bash

tsd auth generate-api-key

tsd auth generate-jwt --api-key=YOUR_API_KEY --duration=60

tsd auth generate-jwt --api-key=KEY --roles=admin,editor ```

Rotation des secrets :

• Clés API : rotation tous les 90 jours minimum
• JWT secret : rotation tous les 180 jours
• Certificats TLS : renouvellement avant expiration

Toujours utiliser HTTPS :

```bash

tsd auth generate-cert --host localhost --days 365

tsd server \ --tls-cert=/path/to/fullchain.pem \ --tls-key=/path/to/privkey.pem \ --port=8443 ```

Recommandations TLS :

• ✅ TLS 1.2+ uniquement (désactiver TLS 1.0 et 1.1)
• ✅ Cipher suites fortes uniquement
• ✅ HSTS (HTTP Strict Transport Security)
• ✅ Certificats valides (pas auto-signés en production)

Jamais en clair :

```bash

tsd server --jwt-secret=my-secret-123

export TSD_JWT_SECRET=$(cat /secure/path/jwt-secret.txt) tsd server

```

Fichiers de configuration :

• Ne jamais committer les secrets dans Git
• Utiliser `.env.example` avec valeurs factices
• Ajouter `.env` dans `.gitignore`
• Permissions restrictives : `chmod 600 config/secrets.yaml`

Exposition minimale :

```bash

tsd server --host 127.0.0.1 --port 8080

```

Firewall : ```bash

ufw allow 443/tcp ufw enable

iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Redirection HTTP→HTTPS ```

Rate Limiting :

• Limiter les requêtes par IP
• Utiliser un reverse proxy (Nginx, Caddy) avec rate limiting
• Protéger les endpoints sensibles (auth, compilation)

Activer les logs sécurité :

```bash

tsd server --log-level=info --log-format=json --log-file=/var/log/tsd/security.log ```

Surveiller :

• Tentatives d'authentification échouées
• Utilisation suspecte des API keys
• Erreurs de validation JWT
• Accès à des ressources non autorisées
• Patterns de requêtes anormaux

Alertes :

• Configurer des alertes sur les échecs d'authentification répétés
• Notifier sur les erreurs critiques
• Monitorer l'utilisation des ressources (CPU, mémoire, disque)

Maintenir TSD à jour :

```bash

tsd --version

```

Processus de mise à jour :

1. Lire le CHANGELOG et release notes
2. Vérifier les breaking changes
3. Tester en environnement de staging
4. Backup des données et configuration
5. Mise à jour en production
6. Vérifier les logs post-déploiement

Scanner les vulnérabilités Go :

```bash

go install golang.org/x/vuln/cmd/govulncheck@latest govulncheck ./...

make security-vulncheck ```

Analyse statique de sécurité :

```bash

go install github.com/securego/gosec/v2/cmd/gosec@latest gosec -exclude-dir=tests ./...

make security-gosec

make security-scan # Exécute gosec + govulncheck ```

Scanner les dépendances :

```bash

go list -json -m all | nancy sleuth

```

Review de code sécurité :

• Validation de toutes les entrées utilisateur
• Gestion des erreurs robuste (pas de panic)
• Pas d'injection SQL/commande/code
• Gestion des cas nil/vides
• Pas de race conditions
• Pas de fuites mémoire
• Secrets jamais en clair dans le code

Checklist sécurité : ```bash

make validate

```

Utilisateur dédié :

```bash

sudo useradd -r -s /bin/false tsd

sudo chown -R tsd:tsd /opt/tsd sudo chmod 750 /opt/tsd ```

Systemd service :

```ini [Unit] Description=TSD Server After=network.target

[Service] Type=simple User=tsd Group=tsd WorkingDirectory=/opt/tsd ExecStart=/opt/tsd/bin/tsd server --config=/etc/tsd/config.yaml Restart=on-failure RestartSec=10

NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true ReadWritePaths=/var/lib/tsd /var/log/tsd

[Install] WantedBy=multi-user.target ```

Ressources limitées :

```ini

LimitNOFILE=65536 LimitNPROC=512 MemoryLimit=2G CPUQuota=200% ```

```nginx upstream tsd_backend { server 127.0.0.1:8080; }

server { listen 443 ssl http2; server_name tsd.example.com;

# TLS
ssl_certificate /etc/letsencrypt/live/tsd.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/tsd.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

# Headers de sécurité
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;

# Rate limiting
limit_req_zone \$binary_remote_addr zone=tsd_limit:10m rate=10r/s;
limit_req zone=tsd_limit burst=20 nodelay;

location / {
    proxy_pass http://tsd_backend;
    proxy_set_header Host \$host;
    proxy_set_header X-Real-IP \$remote_addr;
    proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto \$scheme;
}

}

server { listen 80; server_name tsd.example.com; return 301 https://$server_name$request_uri; } ```

Sauvegardes régulières :

• Configuration : quotidien
• Données : selon criticité (quotidien/hebdomadaire)
• Secrets : stockage sécurisé hors-ligne

Plan de récupération :

• Documenter la procédure de restauration
• Tester régulièrement les backups
• Conserver plusieurs versions

Merci aux chercheurs en sécurité qui ont contribué à améliorer la sécurité de TSD :

Nous remercions tous les chercheurs en sécurité qui contribuent à protéger TSD et ses utilisateurs.

• Configuration TLS : En-têtes de sécurité HTTP
• Scanner de Vulnérabilités : govulncheck et gosec
• Guide Auth : Authentification JWT et API keys
• CONTRIBUTING.md : Standards de code sécurisé

Sécurité Web :

• OWASP Top 10 - Top vulnérabilités web
• OWASP Go Security Cheat Sheet
• CWE Top 25 - Faiblesses logicielles communes

Scoring et CVE :

• CVSS v3.1 Calculator - Calculateur CVSS
• CVE Program - Programme CVE
• NVD - National Vulnerability Database

Go Security :

• Go Security Policy - Politique de sécurité Go
• Go Vulnerability Database - Base vulnérabilités Go
• Secure Go Guidelines - OWASP Secure Coding Practices

Scanners :

• govulncheck - Scanner vulnérabilités Go
• gosec - Analyseur sécurité statique Go
• Nancy - Scanner dépendances

Analyse Statique :

• staticcheck - Linter Go avancé
• errcheck - Vérification gestion erreurs
• golangci-lint - Meta-linter avec règles sécurité

TLS/Certificats :

• Let's Encrypt - Certificats TLS gratuits
• SSL Labs Test - Test configuration TLS
• testssl.sh - Test TLS en ligne de commande

Guides :

• ISO 29147 - Vulnerability disclosure
• GitHub Security Advisories
• CERT Coordination Center

Pour reporter une vulnérabilité :

1. Accédez à la page Security du projet GitHub
2. Cliquez sur "Report a vulnerability"
3. Remplissez le formulaire privé avec les détails fournis dans la section "Informations à Fournir"

GitHub Discussions : Pour questions générales de sécurité (non sensibles)

Issue Tracker : UNIQUEMENT pour bugs non-sécuritaires

⚠️ Important : Ne jamais reporter de vulnérabilités via issues publiques ou discussions !

Cette politique de sécurité suit les principes de divulgation coordonnée responsable :

Nous nous engageons à :

1. ✅ Traiter tous les rapports sérieusement - Chaque rapport est évalué et traité
2. ✅ Répondre rapidement - Accusé de réception sous 48h, évaluation sous 7 jours
3. ✅ Communiquer régulièrement - Mises à jour hebdomadaires minimum
4. ✅ Travailler de bonne foi - Collaboration transparente avec les reporters
5. ✅ Créditer publiquement - Attribution appropriée (sauf demande d'anonymat)
6. ✅ Ne pas poursuivre - Aucune action légale contre chercheurs suivant cette politique
7. ✅ Divulguer de manière responsable - Publication coordonnée avec le reporter

Nous demandons aux reporters de :

1. ✅ Garder la confidentialité - Jusqu'à la publication du correctif
2. ✅ Donner un délai raisonnable - Permettre la correction avant divulgation
3. ✅ Coordonner la publication - Travailler avec nous sur le timing
4. ✅ Agir de bonne foi - Objectif de protection, pas d'exploitation
5. ✅ Utiliser les canaux appropriés - Rapport privé via GitHub Security Advisory
6. ✅ Fournir des détails - Information suffisante pour reproduire
7. ✅ Respecter les limites - Pas d'accès non autorisé ou DoS

Divulgation coordonnée :

• Nous travaillons avec le reporter pour choisir la date de divulgation publique
• Nous respectons les délais standards de l'industrie (30-90 jours selon gravité)
• Nous publions l'advisory et les crédits simultanément avec la release corrigée

Transparence :

• Publication d'advisories détaillés après correction
• Documentation des vulnérabilités dans CHANGELOG.md
• Notification proactive des utilisateurs affectés

Équité :

• Tous les reporters sont traités équitablement
• Les crédits sont donnés selon les préférences du reporter
• Nous ne discriminons pas selon l'origine du rapport

Nous remercions :

• La communauté sécurité pour leur vigilance et contributions
• Les projets open source dont nous nous inspirons (Go, Kubernetes, Node.js)
• Nos utilisateurs pour leur confiance et leurs retours

Merci de contribuer à la sécurité de TSD ! 🛡️

TSD Security Team
Protéger nos utilisateurs est notre priorité.