getedgehq/security-audit-checklist

Checklist d'Audit de Sécurité

Exécutez ces vérifications sur tout système avant de le mettre en production ou après des changements majeurs.

Avant de commencer

La checklist elle-même est en texte simple et ne nécessite rien. Les trois scanners sous scripts/ sont en Python, donc leur exécution nécessite Python 3 sur votre machine (python3 --version). Sans cela, vous pouvez toujours travailler la checklist manuellement ; vous n'obtenez simplement pas le scan automatisé de secrets, la vérification des en-têtes et la lecture IaC.

1. Confidentialité et Gouvernance des Données

• Politique de confidentialité existante si l'application collecte, stocke ou traite des données utilisateur. Lien dans le pied de page et les flux d'inscription.
• Savoir où sont stockées les données utilisateur : documenter la base de données principale, les caches, les journaux, les sauvegardes et les services tiers. Vérifier les exigences de résidence des données (RGPD, CCPA).
• Minimisation des données : ne collecter que ce qui est nécessaire. Supprimer ou anonymiser les données non utilisées.

2. Hygiène des Secrets et des Clés

• Les valeurs .env ne fuient pas : scanner l'ensemble du dépôt à la recherche de secrets codés en dur.
• Ne jamais exposer les clés API dans le code frontend : pas de clés dans les bundles JS, pas de valeurs sensibles dans les préfixes d'environnement publics (REACT_APP_, NEXT_PUBLIC_, VITE_).
• Déplacer les clés côté serveur ou derrière un proxy : tous les appels API tiers nécessitant des secrets doivent passer par un point de terminaison backend.
• Supprimer les secrets des journaux : grep les journaux et les rapporteurs d'erreurs pour les clés, jetons et mots de passe. Les masquer ou les occulter avant la sortie.
• Récupérer immédiatement les informations d'identification divulguées si quoi que ce soit est trouvé.

Commandes de scan rapide :

# Exécuter le scanner de secrets fourni
python3 scripts/scan_secrets.py .

# Modèles ripgrep manuels
grep -rE '(api[_-]?key|secret|token|password)\s*[:=]\s*["\047][a-zA-Z0-9_\-]{16,}' --include='*.{js,ts,py,go,rb,php,java,json,yaml,yml,env,sh,tf,hcl}' .
grep -rE 'AKIA[0-9A-Z]{16}' .  # Clés AWS
grep -rE 'ghp_[a-zA-Z0-9]{36}' .  # Jetons GitHub
grep -rE 'sk-[a-zA-Z0-9]{48}' .   # Clés OpenAI

3. En-têtes de Sécurité

• Content-Security-Policy restreint les sources de scripts et bloque l'exécution en ligne lorsque cela est possible.
• X-Frame-Options ou frame-ancestors empêche le détournement de clic.
• Strict-Transport-Security impose le HTTPS.
• X-Content-Type-Options: nosniff est présent.
• Referrer-Policy limite les fuites de référent.

Vérifier les en-têtes sur une URL en ligne :

python3 scripts/check_headers.py https://votre-app.com

4. Bases de l'OWASP Top 10

#	Risque	Que vérifier
A01	Contrôle d'accès défaillant	Chaque point de terminaison vérifie l'authentification et l'autorisation. Pas de bugs IDOR.
A02	Défaillances cryptographiques	Mots de passe hachés avec bcrypt/Argon2. TLS 1.2+ imposé. Pas de données sensibles dans les URL.
A03	Injection	SQL utilise des instructions paramétrées. Pas de concaténation de chaînes brutes dans les requêtes.
A04	Conception non sécurisée	Limites de débit sur l'authentification et les actions sensibles. La logique métier comporte des vérifications d'abus.
A05	Mauvaise configuration de sécurité	Identifiants par défaut supprimés. Mode débogage désactivé en production. Les messages d'erreur ne divulguent pas de traces de pile.
A06	Composants vulnérables	Audit des dépendances : npm audit, pip-audit, cargo audit, snyk test.
A07	Défaillances d'authentification	Les jetons de session sont aléatoires et pivotés lors des changements de privilèges. MFA pour les comptes sensibles.
A08	Intégrité des données	Fichiers de verrouillage présents, commits signés lorsque possible.
A09	Défaillances de journalisation	Les événements de sécurité sont enregistrés sans secrets.
A10	SSRF	Les requêtes côté serveur utilisent une liste blanche. Aucune URL contrôlée par l'utilisateur n'atteint les services internes.

5. Validation des Entrées et Injection

• Injection SQL : toutes les requêtes utilisent des paramètres ORM ou des instructions préparées.
• XSS : la sortie utilisateur est échappée HTML. dangerouslySetInnerHTML et les contournements similaires sont audités.
• Injection de commandes : pas de exec(), system() ou eval() avec des entrées utilisateur.
• Traversée de chemin : les chemins de fichier sont nettoyés et restreints à un répertoire de liste blanche.
• Injection NoSQL : les requêtes MongoDB utilisent des objets paramétrés.

6. Sécurité des API

• Vérifier les réponses API pour les données sensibles : pas d'ID internes, de hachages de mots de passe, de jetons ou de PII inutiles.
• Authentification sur tous les points de terminaison non publics : pas de routes admin ou de débogage ouvertes.
• Limites de débit avant que quelqu'un ne brûle votre facture API : limitation de débit par IP et par utilisateur sur les points de terminaison coûteux ou d'authentification. Retourner 429 avec Retry-After.
• CORS est strict : Access-Control-Allow-Origin n'est pas *. La pré-vérification est requise pour les méthodes modifiant l'état.

7. Authentification et Session

• Politique de mot de passe : minimum 8 caractères, pas de longueur maximale qui empêche les phrases de passe.
• Protection contre la force brute : backoff exponentiel ou CAPTCHA après des échecs de connexion.
• Gestion de session : cookies sécurisés, httpOnly, SameSite. Les JWT ont une courte durée de validité et une rotation par rafraîchissement.
• Réinitialisation de mot de passe : les jetons sont à usage unique, aléatoires et expirent rapidement.

---

8. Sécurité du Fournisseur Cloud

S'applique à AWS, GCP, Azure et toute autre plateforme cloud.

8.1 Gestion des Identités et des Accès (IAM)

• Aucune clé d'accès de compte racine n'existe. MFA racine activé.
• Principe du moindre privilège : chaque rôle, utilisateur et compte de service dispose des autorisations minimales requises. Pas d'actions ou de ressources génériques (*) sauf si absolument nécessaire.
• Pas de clés d'accès à longue durée de vie pour les utilisateurs. Privilégier les rôles IAM avec des identifiants temporaires (STS, profils d'instance, identité de charge de travail).
• MFA imposé pour tous les utilisateurs humains, en particulier les administrateurs et l'accès à la facturation.
• Identités inactives supprimées : supprimer ou désactiver les utilisateurs, rôles et comptes de service inutilisés depuis 90 jours ou plus.
• Accès entre comptes utilise des hypothèses de rôle explicites avec un ID externe le cas échéant. Pas de politiques de confiance avec Principal: *.

8.2 Stockage (S3 / GCS / Azure Blob)

• Pas de buckets/conteneurs publics sauf pour héberger intentionnellement des actifs statiques publics. Bloquer l'accès public au niveau du compte.
• Chiffrement au repos activé (AES-256 ou KMS). Pas de volumes de stockage ou d'instantanés non chiffrés.
• Chiffrement en transit imposé (HTTPS/TLS uniquement). Pas de http autorisé.
• Politiques de cycle de vie suppriment ou transfèrent les données anciennes. Contrôle de version activé pour les buckets critiques.
• Les politiques de bucket n'accordent pas Principal: * ou AllUsers. L'accès se fait via des rôles IAM, pas des clés codées en dur.
• Journalisation activée pour les journaux d'accès et les événements au niveau des objets (journaux d'accès au serveur S3, événements de données CloudTrail).

8.3 Calcul (EC2 / GCE / Azure VM / Lambda / Cloud Run)

• Pas de groupes de sécurité par défaut autorisant 0.0.0.0/0 sur les ports sensibles (22, 3389, 3306, 5432, 6379, 27017).
• SSM / Session Manager utilisé à la place du SSH direct lorsque possible. Pas de port 22 ouvert sur Internet.
• IMDSv2 requis sur AWS EC2 (désactiver IMDSv1).
• Les métadonnées d'instance ne sont pas exposées aux conteneurs ou au code non fiable.
• L'environnement d'exécution de la fonction utilise des privilèges minimaux. Lambda/GCP Cloud Functions ne s'exécutent pas avec des rôles d'administrateur.
• Les variables d'environnement de la fonction ne contiennent pas de secrets en texte clair. Utiliser un gestionnaire de secrets (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).

8.4 Base de données et Cache

• Pas d'accès public : les bases de données sont dans des sous-réseaux privés ou des VPC. Pas de 0.0.0.0/0 dans les groupes de sécurité.
• Chiffrement au repos et en transit activé.
• Sauvegardes automatisées avec restauration à un point dans le temps.
• Authentification forte : pas de mots de passe par défaut. Utiliser l'authentification de base de données IAM ou des certificats clients TLS lorsque c'est pris en charge.
• Journalisation d'audit activée pour les connexions et les modifications de schéma.

8.5 Réseau

• VPC / segmentation réseau : la production, la préproduction et le développement sont dans des réseaux séparés ou au moins des sous-réseaux séparés.
• Groupes de sécurité / pare-feu sont en mode refus par défaut. Seuls les ports nécessaires sont ouverts.
• Pas de CIDR trop permissifs : 0.0.0.0/0 est évité sauf pour HTTPS (443) sur les équilibreurs de charge publics.
• Sous-réseaux privés pour les bases de données, les caches et les services internes. Passerelle NAT ou points de terminaison VPC pour l'accès Internet sortant.
• Protection DDoS activée le cas échéant (AWS Shield, Cloud Armor, Azure DDoS Protection).
• DNS / Domaine : DNSSEC activé si le registraire le prend en charge. Pas d'enregistrements DNS orphelins pointant vers des IP expirées ou des ressources supprimées (risque de prise de contrôle de sous-domaine).

8.6 Journalisation, Surveillance et Alertes

• CloudTrail / Journaux d'audit / Journaux d'activité activés dans toutes les régions et tous les services.
• Intégrité des journaux : les journaux sont immuables ou stockés dans un compte séparé avec des autorisations d'écriture unique.
• Données sensibles non enregistrées : les journaux cloud n'incluent pas les mots de passe, les jetons ou les PII.
• Alertes configurées pour la connexion racine, les modifications de politique IAM, la création de bucket public, les modifications de groupe de sécurité et les pics d'échec d'authentification.
• Rétention des journaux conforme aux exigences de conformité (généralement 1 an).

---

9. Sécurité des Conteneurs et de l'Orchestration

9.1 Docker / Images de Conteneurs

• Pas de secrets dans les images : scanner les Dockerfiles et les couches pour .env, config.json ou des identifiants codés en dur.
• Images de base minimales : utiliser distroless, Alpine ou scratch au lieu d'Ubuntu/Debian complet lorsque possible.
• Pas d'exécution en tant que root : le Dockerfile définit USER sur un UID/GID non root.
• Scan d'images : activer l'analyse des vulnérabilités dans le registre (ECR, GCR, ACR, Docker Hub) et bloquer les CVE critiques dans le CI.
• Tags immuables : ne pas utiliser latest en production. Épingler sur le digest ou une version sémantique spécifique.
• Constructions multi-étapes : les artefacts de construction et les dépendances de développement ne se retrouvent pas dans l'image finale.

9.2 Kubernetes

• RBAC : rôles et liaisons de rôles avec le moindre privilège. Pas de cluster-admin pour les comptes de service.
• Aucun jeton de compte de service par défaut monté dans des pods qui n'en ont pas besoin (automountServiceAccountToken: false).
• Politiques réseau : refus par défaut pour l'entrée/la sortie, puis autoriser explicitement le trafic requis.
• Normes de sécurité des pods : appliquer le profil restricted ou baseline. Pas de conteneurs privilégiés, pas de hostPath, pas de hostNetwork.
• Chiffrement des secrets : le chiffrement etcd au repos est activé. Pas de secrets en texte clair dans Git.
• Sécurité de l'environnement d'exécution du conteneur : profils seccomp, AppArmor ou SELinux appliqués.
• Contrôleurs d'admission : utiliser OPA/Gatekeeper ou Kyverno pour appliquer les politiques (pas de tag latest, étiquettes requises, limites de ressources).
• Limites de ressources : chaque pod a des limites de CPU et de mémoire pour empêcher les dénis de service par épuisement des ressources.

---

10. Infrastructure en tant que Code (IaC)

• Pas de secrets dans Terraform / CloudFormation / Pulumi / CDK : les fichiers d'état ne contiennent pas de mots de passe ou de clés en texte clair. L'état distant est chiffré et l'accès est contrôlé.
• Le backend d'état Terraform est sécurisé : S3 avec SSE-KMS, verrouillage DynamoDB et aucun accès en lecture publique.
• Scan IaC : exécuter checkov, tfsec ou terrascan sur Terraform/CloudFormation avant la fusion.
• Détection de dérive : des analyses programmées détectent les modifications manuelles de la console qui divergent de l'IaC.
• Les modules sont épinglés à une version : ne pas extraire de modules de branches ou de sources non versionnées.

Scan IaC rapide :

python3 scripts/scan_iac.py .

# Ou utiliser des outils dédiés s'ils sont installés :
checkov -d . --framework terraform,cloudformation,dockerfile
# tfsec .

---

11. Sécurité du Pipeline CI/CD

• Pas de secrets dans les configurations de pipeline : pas de jetons codés en dur dans .github/workflows, .gitlab-ci.yml, Azure Pipelines ou Jenkinsfiles.
• Les secrets sont injectés depuis le gestionnaire de secrets natif de la plateforme CI (GitHub Secrets, GitLab CI Variables, Azure DevOps Library).
• Les autorisations du pipeline sont minimales : les comptes de service CI ont uniquement les autorisations nécessaires pour déployer.
• Protection de branche : les pushs directs vers main/master sont bloqués. Toutes les modifications nécessitent une PR/MR + une revue.
• Commits signés ou exigences de fusion : exiger des commits signés ou au moins des commits de fusion vérifiés pour les dépôts sensibles.
• Analyse des dépendances : les outils SCA (Snyk, Dependabot, Renovate) s'exécutent sur chaque PR.
• SAST : l'analyse statique (Semgrep, CodeQL, SonarQube) s'exécute sur chaque PR.
• Analyse des conteneurs : les images sont scannées pour les CVE avant le déploiement.
• Pas d'exécuteurs auto-hébergés exposés à Internet public sans VPN ou liste blanche IP.
• Le pipeline n'exécute pas de code non fiable provenant de forks sans approbation manuelle (empêcher les demandes pwn).

---

12. Sécurité du Domaine et du DNS

• DNSSEC activé chez le registraire si pris en charge.
• Pas d'enregistrements CNAME / A / NS orphelins pointant vers des services expirés (risque de prise de contrôle de sous-domaine).
• Certificats génériques ou certificats par sujet provenant d'une AC de confiance. Pas de certificats auto-signés en production.
• Surveillance de l'expiration des certificats : alertes 30 et 7 jours avant l'expiration.
• CDN / WAF configuré avec des règles sensées (blocages SQLi, XSS, LFI). Limitation de débit activée en périphérie.

---

Résultat d'Audit

Après avoir exécuté la checklist, produisez un rapport concis en markdown avec :

1. Résumé — Réussi / Échoué / À revoir par catégorie.
2. Résultats critiques — Tout ce qui doit être corrigé avant la production.
3. Correctifs recommandés — Modifications de code spécifiques, mises à jour de configuration ou mises à niveau de bibliothèque.
4. Matrice des risques — Probabilité × Impact pour chaque résultat.
5. Calendrier de correction — Suggérer un ordre de priorité et des délais.