Comment détecter gratuitement les vulnérabilités dans votre dépôt

Pour détecter gratuitement les vulnérabilités dans votre dépôt, superposez trois couches : un scanner de dépendances (npm audit, pip-audit ou OSV-Scanner), un scanner de secrets (Gitleaks) et un scanner de code (Semgrep Community Edition). Exécutez-les sur chaque pull request. Aucun d'entre eux ne repérera l'absence d'un contrôle d'autorisation, il vous faudra donc ajouter un test à l'exécution pour combler ce manque.

npm audit --audit-level=high
pip-audit -r requirements.txt
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off --error

Ce que Vercel Security Review change

Vercel Security Review est une fonctionnalité de Vercel Agent, en version bêta publique depuis le 2 novembre 2026. Elle analyse chaque push vers un dépôt GitHub connecté, examine le diff ainsi que le code environnant, trace l'accessibilité de la modification et vérifie à nouveau chaque résultat avant de le signaler.

L'exemple fourni par Vercel est la raison même de cet article. Une modification apportée à un endpoint de facturation recherchait les factures par ID sans vérifier l'organisation associée ; ainsi, n'importe quel utilisateur connecté pouvait télécharger la facture d'une autre organisation. Il s'agit d'une faille logique, et les scanners basés sur des motifs ont du mal à repérer les failles logiques.

Voici qui peut l'utiliser :

La documentation de Vercel précise également ses limites : l'outil analyse le code et non votre application en cours d'exécution, et il ne s'agit pas d'un test d'intrusion. Si vous n'êtes pas éligible ou si vous lisez ces lignes après la période de gratuité, le reste de ce guide ne vous coûtera rien.

Ce qu'une analyse de vulnérabilités de dépôt doit couvrir

Une analyse complète des vulnérabilités d'un dépôt vérifie quatre points : les failles connues dans vos dépendances, les identifiants commités dans Git, les motifs de code non sécurisés tels que les injections, et la logique d'autorisation. Les trois premiers disposent de scanners gratuits et éprouvés. Le quatrième dépend de la sémantique de votre code et nécessite donc un test sur une API en cours d'exécution.

Une clé supprimée reste présente dans l'historique Git : analysez donc l'historique et renouvelez toute clé réelle. Pour les clés circulant dans le trafic API et les collections de tests, consultez notre guide de vérification des fuites de clés API.

Comparatif des scanners de vulnérabilités gratuits

Les tarifs et licences ont été vérifiés le 5 novembre 2026. Aucun des outils en ligne de commande ne requiert de compte ou de carte bancaire pour exécuter les commandes présentées dans ce guide.

Deux remarques concernant les licences. Les règles communautaires de Semgrep utilisent la licence Semgrep Rules License, qui autorise un usage interne en entreprise, mais interdit leur redistribution ou leur exploitation en tant que service. Et si vous adoptez Trivy, lisez la note CVE-2026-33634 : des attaquants ont brièvement compromis certaines parties de l'écosystème Trivy en mars 2026. Utilisez une version à jour et figez chaque action sur un SHA de commit.

Analyser un dépôt en quelques commandes : nos résultats

Nous avons créé une petite API de facturation avec Express et l'avons commitée dans un dépôt local. Elle comportait quatre dépendances npm et trois dépendances Python dans des versions obsolètes, deux fausses clés (une au format Stripe, une au format AWS), une injection SQL, une injection de commande, ainsi qu'une route renvoyant la facture de n'importe quelle organisation à tout utilisateur connecté.

Nous avons ensuite exécuté chaque outil sous macOS le 5 novembre 2026 :

npm audit
pip-audit -r requirements.txt --no-deps --disable-pip
osv-scanner scan source -r .
trivy fs --scanners vuln,secret .
gitleaks git . --no-banner
semgrep scan --config p/default --metrics=off
semgrep scan --config p/nodejsscan --metrics=off

Trois constats s'imposent :

• Les chiffres ne sont pas comparables. Un package, un bulletin de sécurité (advisory) et une anomalie détectée correspondent à des unités différentes, et chaque outil analyse des données distinctes. Comparez ce qui a été détecté, pas les totaux.
• Un seul scanner de secrets ne suffit pas. Gitleaks et Trivy ont tous deux manqué la clé au format AWS.
• Le choix des ensembles de règles (rulesets) est crucial. Le pack par défaut de Semgrep a ignoré une requête SQL construite par simple concaténation de chaînes. p/javascript, p/nodejs, p/owasp-top-ten et p/sql-injection n'ont rien renvoyé sur ce dépôt, alors que p/nodejsscan l'a repérée.

Aucun outil n'a signalé la route de facturation. Il s'agit d'un petit dépôt de test : considérez ceci comme une démonstration et non comme un benchmark. Nous n'avons pas exécuté CodeQL.

Analyser votre dépôt GitHub à chaque pull request

Les runners standard hébergés par GitHub sont gratuits pour les dépôts publics. Pour les dépôts privés, l'offre GitHub Free inclut un crédit mensuel de 12 $, soit environ 2 000 minutes sur un runner Linux 2 cœurs au tarif en vigueur. Ce workflow repose sur des commandes brutes, ce qui permet aux organisations de se passer de la clé de licence pour la GitHub Action de Gitleaks :

name: repo-scan
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0
      - name: Dependencies (npm)
        run: npm audit --audit-level=high
      - name: Dependencies (Python)
        run: pipx run pip-audit -r requirements.txt
      - name: Secrets
        run: |
          curl -sSL https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz | tar xz gitleaks
          ./gitleaks git . --no-banner
      - name: Code patterns
        run: pipx run semgrep scan --config p/default --config p/nodejsscan --metrics=off --error

Les quatre scanners se sont terminés avec le code de sortie 1 sur notre dépôt de test, et un code de sortie non nul entraîne l'échec du job. Supprimez simplement les étapes superflues pour votre stack. Pour exécuter des tests d'API dans ce même pipeline, consultez notre guide sur Apidog CLI avec GitHub Actions.

Activez également les alertes Dependabot. Elles sont gratuites pour tous les forfaits et n'attendent pas l'ouverture d'une pull request pour vous alerter.

La faille ignorée : les bugs d'autorisation qui échappent aux scanners

Les bugs d'autorisation constituent un défi pour les scanners de motifs, car le code paraît tout à fait valide en surface : une requête correcte, un paramètre valide et un middleware d'auth en amont. La faille réside dans une condition manquante, que seul votre modèle de données permet de déterminer.

// Every scanner passed this
db.query("SELECT * FROM invoices WHERE id = $1", [req.params.id]);

// The fix: scope the lookup to the caller's organization
db.query("SELECT * FROM invoices WHERE id = $1 AND org_id = $2",
  [req.params.id, req.user.orgId]);

Il s'agit de la faille Broken Object Level Authorization (BOLA), classée au premier rang du Top 10 OWASP pour la sécurité des API en 2023. L'OWASP recommande de vérifier les autorisations d'accès pour chaque requête utilisant un identifiant fourni par le client, et d'écrire des tests capables de capturer les défauts d'autorisation avant la mise en production.

Solliciter un agent de codage s'avère utile. Nous avons supprimé les commentaires du dépôt de test et demandé à Claude Code de l'examiner, avec et sans indication concernant les organisations. Il a repéré la route de facturation dans les deux cas. Cette approche n'est toutefois pas totalement gratuite, car elle consomme les quotas ou crédits de votre agent, et les résultats peuvent varier d'une exécution à l'autre.

Un test automatique, en revanche, apporte une réponse binaire et définitive à chaque pull request. Pour une couverture complète côté API, consultez nos ressources sur la détection automatisée des vulnérabilités d'API, notre sélection d'outils d'analyse de sécurité d'API et notre checklist pour les tests de sécurité d'API.

Tester l'autorisation grâce à votre agent de codage et Apidog CLI

Inutile d'écrire ces tests à la main pour chaque route. Laissez votre agent de codage s'en charger avec Apidog CLI : il analyse vos routes, génère un test pour chaque ressource protégée et produit une suite prête à tourner en CI. La version gratuite d'Apidog prend en charge jusqu'à 4 utilisateurs.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Vous aurez besoin d'un environnement de test initialisé avec deux organisations et un utilisateur dans chacune. Transmettez ensuite ce prompt à votre agent :

Read the routes in src/. For each route that returns data owned by an
organization, create an Apidog test scenario in project <id>: log in as
the Org A test user, request an Org B resource by ID, and assert the
status is 403 or 404. Add an Org A request for its own resource and
assert 200, so a broken login can't pass. Group the scenarios in a test
suite, run it against the staging environment, and summarize failures.

L'agent vérifie la structure du payload, génère les scénarios et exécute la suite de tests :

apidog cli-schema get test-scenario-create
apidog cli-schema validate test-scenario-create --file scenario.json
apidog test-scenario create --project <id> --file scenario.json
apidog test-scenario import-steps <scenarioId> --project <id> --source endpoint --ids <endpointIds>
apidog test-suite create --project <id> --file suite.json
apidog run --test-suite <suiteId> --project <id> -e <envId> -r cli,junit

Le test de validation positive est indispensable. Sans lui, une URL de base erronée renverrait également un code 404, et le test réussirait pour une mauvaise raison.

Ajoutez la même ligne apidog run au workflow ci-dessus, en ciblant un déploiement de prévisualisation (preview) ou de staging doté d'organisations de test initialisées — jamais avec des données de production. La documentation de référence de apidog run détaille les autres options, et le guide Apidog CLI dans Claude Code vous guide pas à pas dans la configuration de l'agent.

FAQ

Quelle est la meilleure méthode gratuite pour détecter les vulnérabilités dans un dépôt ? Combinez un scanner de dépendances, Gitleaks et Semgrep Community Edition, puis ajoutez un test à l'exécution pour vérifier les autorisations. Aucun outil n'a été capable de tout couvrir à lui seul sur notre dépôt de test.

Vercel Security Review est-il gratuit ? Uniquement jusqu'au 10 novembre 2026, et exclusivement pour les équipes Pro et Enterprise. Au-delà, l'utilisation est facturée selon les tarifs de tokens du fournisseur, majorés de 0,25 $ par million de tokens. Les dépôts non déployés sur Vercel ne sont pas encore pris en charge.

L'analyse des secrets de GitHub est-elle gratuite sur les dépôts privés ? Non. L'analyse des secrets (Secret scanning) et CodeQL sont gratuits sur les dépôts publics, mais les dépôts privés exigent GitHub Secret Protection (19 $) ou GitHub Code Security (30 $) par committer actif et par mois. Les alertes Dependabot restent gratuites dans les deux cas.

Semgrep peut-il détecter les bugs d'autorisation ? Il n'a pas repéré notre route de facturation avec les ensembles de règles que nous avons exécutés. La version Community Edition ne peut pas suivre le flux de données au-delà d'une seule fonction ou d'un seul fichier, bien qu'il soit possible d'écrire des règles personnalisées pour cibler des motifs propres à votre base de code.

Les scanners remplacent-ils un test d'intrusion ? Non. Les scanners et les tests couvrent les motifs connus ainsi que les cas que vous avez explicitement définis. Un test d'intrusion recherche les failles auxquelles vous n'avez pas pensé, et la documentation de Vercel précise d'ailleurs que sa propre revue ne constitue pas un test d'intrusion.