Examen de sécurité du code

Effectuer un examen de sécurité approfondi des modifications dans une pull request ou issue GitHub, en produisant un rapport structuré avec des verdicts par catégorie.

Prérequis

• gh (GitHub CLI) doit être installé et authentifié.
• git doit être disponible.
• Accès réseau pour cloner les dépôts et récupérer les métadonnées des PR.

Quand l'utiliser

• Examiner une pull request avant fusion pour détecter les vulnérabilités de sécurité.
• Trier une issue GitHub qui signale une faille de sécurité potentielle.
• Auditer les modifications de code pour les secrets codés en dur, les failles d'injection, les contournements d'authentification ou les configurations non sécurisées.

Étape 1 : Analyser l'URL GitHub

Si l'utilisateur a fourni une URL de PR ou d'issue, extraire le propriétaire, le dépôt et le numéro. Sinon, en demander un.

Formats d'URL supportés :

• https://github.com/OWNER/REPO/pull/NUMBER
• https://github.com/OWNER/REPO/issues/NUMBER

Étape 2 : Récupérer le code

Déterminer si vous êtes déjà dans le dépôt cible (comparer gh repo view --json nameWithOwner -q .nameWithOwner avec l'URL). Si c'est le cas :

gh pr checkout <number>

Si vous examinez un dépôt différent, le cloner d'abord dans un répertoire temporaire :

TMPDIR=$(mktemp -d)
gh repo clone OWNER/REPO "$TMPDIR"
cd "$TMPDIR"
gh pr checkout <number>

Étape 3 : Identifier les fichiers modifiés

Lister tous les fichiers modifiés par rapport à la branche de base :

git diff main...HEAD --name-status

Si la PR cible une branche autre que main, utiliser la base correcte. Vérifier avec :

gh pr view <number> --json baseRefName -q .baseRefName

Étape 4 : Lire chaque fichier modifié et son diff

Lire le contenu complet de chaque fichier modifié et le diff pour ce fichier :

git diff main...HEAD -- <file>

Pour les PRs volumineuses (plus de 30 fichiers modifiés), prioriser les fichiers dans cet ordre :

1. Fichiers qui gèrent l'authentification, l'autorisation ou les identifiants.
2. Fichiers qui traitent l'entrée utilisateur (gestionnaires d'API, analyse d'arguments CLI, analyse d'URLs).
3. Fichiers de configuration (Dockerfiles, politiques YAML, configurations d'environnement).
4. Nouvelles dépendances (modifications dans package.json, requirements.txt, go.mod).
5. Tout le reste.

Étape 5 : Analyser par rapport à la liste de contrôle de sécurité

Pour chacune des 9 catégories ci-dessous, attribuer un verdict :

• PASS — aucun problème détecté (justification brève).
• WARNING — préoccupation potentielle (décrire le risque et la correction suggérée).
• FAIL — vulnérabilité confirmée (décrire l'impact, la gravité et la correction).

Catégorie 1 : Secrets et identifiants

• Aucun secret codé en dur, clé d'API, mot de passe, token ou chaîne de connexion dans le code, les configs ou les fixtures de test.
• Aucun secret commité dans le contrôle de version (vérifier les fichiers .env, PEM/clés, JSON d'identifiants).
• Les tokens et identifiants sont passés via des variables d'environnement ou des magasins de secrets, pas en tant que littéraux de chaîne.

Catégorie 2 : Validation des entrées et assainissement des données

• Toutes les entrées contrôlées par l'utilisateur (APIs, formulaires, URLs, en-têtes, paramètres de requête, téléchargements de fichiers) sont validées par rapport à une liste blanche des types, longueurs et formats attendus.
• Encodage et échappement appropriés pour prévenir les failles XSS, injection SQL, injection de commande, traversée de répertoires et SSRF.
• La désérialisation de données non fiables utilise des parseurs sûrs (pas de pickle.loads, yaml.unsafe_load, eval, new Function ou similaires).

Catégorie 3 : Authentification et autorisation

• Tous les nouveaux endpoints ou endpoints modifiés appliquent l'authentification avant de traiter les requêtes.
• La logique d'autorisation garantit que les utilisateurs ne peuvent accéder ou modifier que les ressources qu'ils possèdent ou qu'ils sont autorisés à utiliser.
• Aucun chemin d'escalade de privilèges (horizontal ou vertical).
• La validation des tokens (expiration, signature, scope) est correctement implémentée.

Catégorie 4 : Dépendances et bibliothèques tierces

• Les dépendances nouvellement ajoutées vérifiées pour les CVEs connues (OSV, Snyk, GitHub Advisory DB).
• Les dépendances épinglées à des versions spécifiques et sécurisées (pas de plages flottantes en production).
• La compatibilité des licences OSS n'est pas violée.
• Les dépendances sont extraites uniquement de registres de confiance.

Catégorie 5 : Gestion des erreurs et journalisation

• Les réponses d'erreur ne divulguent pas de traces de pile, de chemins internes ou de données sensibles.
• La journalisation n'enregistre pas de secrets, tokens, mots de passe ou données personnelles.
• Les exceptions sont capturées à des limites appropriées ; aucun crash non géré qui exposerait l'état.

Catégorie 6 : Cryptographie et protection des données

• Algorithmes standard et à jour (AES-256-GCM, RSA-2048+, SHA-256+).
• Pas d'MD5 ou SHA-1 à des fins de sécurité. Pas de cryptographie personnalisée.
• Les données sensibles sont chiffrées au repos et en transit selon le cas.

Catégorie 7 : Configuration et en-têtes de sécurité

• Défauts sécurisés (mode debug désactivé, permissions restrictives, exposition minimale des ports).
• Si des endpoints HTTP sont présents : CSP et CORS configurés correctement. Pas d'origines wildcard dans les contextes authentifiés.
• Les images de conteneur utilisent des utilisateurs non-root, des images de base minimales et des digests épinglés.

Catégorie 8 : Tests de sécurité

• Les tests couvrent les cas limites de sécurité : entrées malveillantes, valeurs limites, tentatives d'accès non autorisé.
• La couverture de test de sécurité existante n'est pas dégradée par la modification.
• Les cas de test négatifs vérifient que les actions interdites sont refusées.

Catégorie 9 : Posture de sécurité holistique

• Les modifications ne dégradent pas la posture de sécurité globale.
• Pas de fausse impression de sécurité (validation côté client uniquement, contrôles incomplets).
• Le principe du moindre privilège est suivi pour le code, les services et les utilisateurs.
• Aucune condition de course TOCTOU dans les chemins critiques pour la sécurité.
• Aucune concurrence non sécurisée qui contournerait les contrôles de sécurité.

Étape 6 : Produire le rapport

Structurer la sortie comme suit :

Verdict

Un paragraphe résumant l'évaluation du risque global et si la PR est sûre à fusionner.

Tableau des résultats

Une ligne par résultat :

Si aucun résultat, déclarer explicitement que l'examen est satisfaisant.

Analyse détaillée

Ventilation par catégorie (catégories 1 à 9), chacune avec son verdict PASS, WARNING ou FAIL et sa justification.

Fichiers examinés

Lister tous les fichiers analysés.

Notes importantes

• Si la PR n'a pas de fichiers modifiés ou est un brouillon sans code, le déclarer et ignorer l'analyse.
• Pour les PRs NemoClaw, faire particulièrement attention aux vecteurs d'échappement de bac à sable : contournements SSRF, injection de Dockerfile, contournement de politique de réseau, fuite d'identifiants et altération de blueprint.
• Ne pas ignorer les catégories. Si une catégorie ne s'applique pas aux modifications (par exemple, pas d'opérations cryptographiques), la marquer PASS avec « Non applicable — aucune opération cryptographique dans cette modification. »
• En cas de doute sur la gravité, préférer WARNING plutôt que PASS.