Skill d'audit de sécurité
La méthodologie exacte que nous utilisons pour exécuter nos audits de sécurité mensuels — traçable publiquement.
Avis de traduction — La version allemande de ce document est l'original juridiquement contraignant. Cette traduction est fournie à titre informatif uniquement. En cas de divergence entre cette traduction et la version allemande, le texte allemand prévaut. Voir la version allemande de référence.
De quoi s'agit-il ?
Cette page documente rankion-security-audit — un skill Claude Code que nous exécutons en interne pour vérifier mensuellement les problèmes de sécurité de Rankion (et de manière ad-hoc avant chaque déploiement majeur). Les résultats — sous forme expurgée — aboutissent sur /fr/trust/security-audits.
Nous publions méthodologie, checklist et règles de redaction afin que vous puissiez comprendre ce que nous vérifions et pourquoi certains détails ne sont pas publics (responsible disclosure : les vulnérabilités concrètes restent privées jusqu'à ce qu'elles soient corrigées).
Comment nous l'exécutons
L'audit est un skill Claude Code — un workflow versionné de prompts et de commandes bash qu'un ingénieur déclenche dans une session Claude Code. C'est intentionnellement pas un cron boîte noire :
- chaque étape est documentée dans le markdown du skill (voir ci-dessous)
- chaque sortie est vérifiée par l'ingénieur par rapport à la checklist
- les findings sont écrits dans deux fichiers : un rapport JSON privé (pour le pipeline de patch interne) et un Markdown public expurgé (pour le journal du Trust Center)
Cadence : mensuel le 15 (ou jour ouvrable suivant) plus ad-hoc avant chaque déploiement touchant l'authentification, les sessions, les dépendances ou la configuration d'environnement.
Définition du skill
Le skill se compose de trois fichiers Markdown (définition du skill + deux fichiers de référence). Les étapes les plus importantes :
- Setup — vérifier le répertoire de travail + git status, capturer la date, charger les fichiers de référence.
- Audit des dépendances —
composer audit+npm audit --omit=dev, compter les résultats par gravité. - Vérification des en-têtes HTTP — requête live contre rankion.ai, vérifier les six classes d'en-têtes de sécurité.
- Vérification de configuration — tests d'exposition contre `.env`, routes de debug et répertoires VCS.
- Scan des patterns de code — diff des 30 derniers jours, plus greps statiques pour les patterns dangereux.
- Vérification de version — releases PHP et Laravel par rapport à la matrice de support.
- Génération de sortie — JSON structuré (privé) plus Markdown expurgé (public).
- Validation de la redaction — greps automatisés contre la liste d'autorisation de confidentialité (voir ci-dessous).
Checklist d'audit — les 7 domaines
A · Dépendances
composer audit + npm audit (production uniquement). Versions Laravel et PHP par rapport à la matrice de support.
B · En-têtes HTTP
HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy, Permissions-Policy. L'en-tête Server ne doit pas divulguer de versions.
C · Configuration
Fichiers d'environnement non récupérables, mode debug désactivé, aucune route dev accessible, aucun répertoire VCS exposé.
D · Authentification / session
Tokens CSRF sur les formulaires POST, cookies de session avec Secure + HttpOnly + SameSite, tokens Sanctum hachés, coût bcrypt >= 10.
E · Patterns de code
Aucun risque d'injection SQL, aucun mass-assignment ouvert, aucun unserialize/eval sur saisie utilisateur, validation sécurisée des uploads de fichiers, échappement des sorties.
F · Spécifique IA
Liste de sous-traitants alignée entre l'inventaire de code, la page de confidentialité et le trust center ; appels LLM strictement scopés par équipe ; prompts contenant des données personnelles signalés.
G · Opérationnel
Sauvegardes à jour et restaurables, queue workers en bonne santé, utilisation disque < 80 %, aucune anomalie de force brute.
Règles de redaction
Le skill écrit deux fichiers par audit : un JSON complet (interne) et un Markdown expurgé (public, sur /fr/trust/security-audits). Cette liste d'autorisation sépare les deux :
Publié
- Date d'audit, auditeur, périmètre
- Comptes agrégés par gravité (critique / haute / moyenne / faible)
- Agrégats de statut (p. ex. « tous les findings High corrigés sous 24 h »)
- Aperçu de la méthodologie et date du prochain audit
JAMAIS publié (jusqu'à correction + 14 jours)
- Chemins de fichiers du codebase
- Numéros CVE des findings ouverts
- Noms et versions des bibliothèques actuellement vulnérables
- Chemins ou paramètres HTTP des endpoints vulnérables
- Étapes de reproduction d'exploits
- Contenu des champs JSON internes « details » et « remediation »
La validation s'exécute automatiquement avant chaque commit : un ensemble de greps vérifie le Markdown public par rapport aux patterns de refus. En cas de correspondance, le fichier public est re-expurgé avant que le commit/push ne soit autorisé.
Cadence
- Mensuel le 15 (ou jour ouvrable suivant) — audit baseline régulier ; le Markdown public arrive sur /fr/trust/security-audits.
- Ad-hoc avant chaque déploiement majeur ayant un impact sur l'authentification, les sessions, les dépendances ou la configuration d'environnement.
- Délais de patch : CVE critiques sous 72 heures, hautes sous 7 jours, moyennes dans le sprint en cours.
Vous avez trouvé une vulnérabilité ? Veuillez utiliser notre procédure de divulgation responsable. Nous accusons réception sous 2 jours ouvrables.
Dernière mise à jour : 03/05/2026 · Skill version 1.0