jpoindexter/security-skills

Analyse SAST

Les audits de dépendances couvrent le code que vous avez importé ; l'analyse SAST couvre le code que vous avez écrit. Elle effectue une correspondance de motifs (et, avec le mode "taint", trace le flux de données) pour les défauts classiques : injection de commandes/SQL, traversée de chemin, désérialisation non sécurisée, eval/exécution dynamique sur des entrées non fiables, clés cryptographiques en dur, vérifications d'authentification manquantes. Un taux élevé de faux positifs est inhérent — la discipline est le triage par accessibilité, et non l'ignorance en bloc.

Quand lancer l'analyse

• Avant une mise en production, sur le diff ou l'ensemble de l'arborescence.
• Lorsque vous ajoutez du code qui manipule des entrées non fiables (un nouvel outil, un point de terminaison, un analyseur, un appel shell).
• En CI sur les PRs (limité au diff, donc rapide et ne signale que les nouveaux problèmes).

Lancer l'analyse

# semgrep — les règles de sécurité. `auto` sélectionne les règles en fonction des langages détectés.
semgrep scan --config auto --error .

# Règles ciblées, à plus fort signal (moins de bruit que auto) :
semgrep scan --config p/security-audit --config p/secrets --config p/command-injection .

# Uniquement le diff (CI sur une PR — rapide, seulement les NOUVELLES découvertes) :
semgrep scan --config auto --baseline-commit origin/main .

Pour une analyse plus approfondie du flux de données (l'entrée non fiable atteint-elle VRAIMENT le puits ?), CodeQL est plus puissant mais plus lourd :

codeql database create db --language=javascript    # ou rust, python, …
codeql database analyze db --format=sarif-latest --output=results.sarif \
  codeql/javascript-queries:codeql-suites/javascript-security-extended.qls

Triage — tracer, ne pas ignorer

Pour chaque découverte, tracez le chemin source → puits :

1. L'entrée est-elle contrôlée par un attaquant ? Un child_process.exec sur une constante codée en dur est acceptable ; sur un paramètre de requête, c'est un bug d'injection de commandes. semgrep signale le puits ; VOUS confirmez la source.
2. Y a-t-il un assainisseur entre eux ? Si la valeur est validée/échappée (un schéma zod, une liste blanche, une requête paramétrée) avant le puits, c'est un faux positif — marquez-le avec # nosemgrep: <id-règle> en ajoutant une ligne expliquant pourquoi, pas une simple ignorance.
3. Réel ? Corrigez à la source (validez/échappez l'entrée) ou au puits (paramétrez, utilisez l'API sécurisée), pas en supprimant l'avertissement.

Ne désactivez jamais une règle en bloc pour nettoyer le tableau — vous supprimeriez la seule vraie découverte parmi le bruit. Supprimez par ligne, avec une raison.

Ce qu'il faut réellement corriger (par ordre de priorité décroissante)

• Injection (commandes/SQL/modèle) sur tout chemin accessible par l'utilisateur — la classe la plus grave et la plus exploitée.
• Traversée de chemin — chemins non validés atteignant des lectures/écritures de fichiers (un agent qui écrit des fichiers est exactement ce risque ; conditionnez par une vérification de périmètre).
• Exécution/eval non sécurisée de chaînes dynamiques.
• Clés cryptographiques en dur / aléatoire faible dans un contexte de sécurité.

La limite

Le SAST voit le code source d'un dépôt statiquement — il ne peut pas voir la configuration d'exécution, un chemin de code piloté par des variables d'environnement, ou un défaut qui n'émerge qu'à travers une frontière de service. Il complète, sans jamais remplacer, un véritable modèle de menace et [[dependency-audit]]. Pour un environnement d'agent/outil, le contrôle le plus fort est souvent architectural (un noyau qui verrouille chaque action) plutôt que par ligne — le SAST valide le code AUTOUR de cette frontière. Intégrez-le dans [[security-preflight]].