リポジトリの脆弱性を無料で検出する方法

リポジトリの脆弱性を無料で検出するには、依存関係スキャナー（npm audit、pip-audit、OSV-Scanner）、シークレットスキャナー（Gitleaks）、コードスキャナー（Semgrep Community Edition）の3層を組み合わせるのが効果的です。これらをすべてのプルリクエストで実行しましょう。ただし、いずれのツールも認可チェックの不備までは検出できないため、別途ランタイムテストを追加する必要があります。

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

Vercel Security Reviewで何が変わるのか

Vercel Security Reviewは、2026年11月2日よりパブリックベータが開始されたVercel Agentの機能です。連携されたGitHubリポジトリへのプッシュごとにスキャンを実行し、差分とその周辺のコードを読み取り、変更への到達可能性を追跡した上で、各検出事項を再確認してから報告します。

本記事を執筆した背景には、Vercelが提示した事例があります。請求書エンドポイントの変更において、組織（オーガニゼーション）の検証を行わずにIDだけで請求書を検索していたため、ログイン済みのユーザーなら誰でも他組織の請求書をダウンロードできてしまう状態になっていました。これはロジック上の欠陥（ロジックエラー）であり、一般的なパターンスキャナーが最も苦手とする領域です。

利用条件の概要は以下のとおりです。

Vercelの公式ドキュメントでも限界が明記されています。分析対象はコード自体であり、稼働中のアプリケーションそのものではなく、ペネトレーションテスト（侵入テスト）の代わりにもなりません。利用条件に該当しない場合や無料期間が過ぎてからこの記事を読んでいる場合でも、以降で紹介する手順なら一切コストをかけずに実施できます。

リポジトリの脆弱性スキャンで網羅すべき4つの領域

完全なリポジトリ脆弱性スキャンでは、依存関係の既知の脆弱性、Gitにコミットされた認証情報、インジェクションをはじめとする安全でないコードパターン、そして認可ロジックという4つの要素を検査します。最初の3つには成熟した無料のスキャナーが存在します。一方、4つ目の認可ロジックはコードの意図や仕様に依存するため、稼働中のAPIに対するテストが不可欠です。

コード上からAPIキーを削除してもGitのコミット履歴には残り続けるため、履歴全体をスキャンし、有効なキーがあれば必ずローテーション（再発行・失効）を行ってください。APIトラフィックやテストコレクションに紛れ込んだキーの検出については、こちらのAPIキー漏洩チェックガイドをご覧ください。

無料の脆弱性スキャナー比較

料金およびライセンス情報は2026年11月5日時点のものです。本ガイドで紹介するコマンドラインツールは、いずれもアカウント登録やクレジットカードの登録なしでコマンドを実行できます。

ライセンスに関して2点注意が必要です。まずSemgrepのコミュニティルールにはSemgrep Rules Licenseが適用されており、社内業務での利用は許可されていますが、ルールの再配布やサービスとしての提供は禁止されています。また、Trivyを採用する場合はCVE-2026-33634をご確認ください。2026年3月に攻撃者がTrivyエコシステムの一部を一時的に侵害する事案が発生しました。常に最新リリースを使用し、Actionsを利用する際はコミットSHAでバージョンを固定してください。

数コマンドでリポジトリをスキャン：検証結果

検証用として、Expressで構築した小規模な請求書APIをローカルリポジトリに用意しました。このリポジトリには、古いバージョンのnpm依存関係4点とPython依存関係3点、ダミーのキー2点（Stripe形式とAWS形式）、SQLインジェクション、コマンドインジェクション、そしてログイン済みユーザーなら誰でも他組織の請求書を取得できてしまうルーティングが含まれています。

この環境に対し、2026年11月5日にmacOS上で各ツールを実行しました。

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

この結果から、特に重要なポイントが3つ見えてきます。

• 検出件数は単純比較できない。 パッケージ数、アドバイザリ数、検出箇所（Findings）はそれぞれ単位が異なり、各ツールが参照するデータも違います。合計数ではなく「何を検出できたか」で比較してください。
• シークレットスキャナー1つでは不十分。 GitleaksとTrivyは、どちらもAWS形式のキーを検知できませんでした。
• ルールセットの選定が成否を分ける。 Semgrepのデフォルトパックは、単純な文字列連結によるSQLクエリを見落としました。また、今回のリポジトリではp/javascript、p/nodejs、p/owasp-top-ten、p/sql-injectionのいずれも反応しませんでしたが、p/nodejsscanは正しく検出できました。

なお、請求書エンドポイントの認可不備を指摘できたツールは1つもありませんでした。これは小規模なリポジトリによる検証例であり、厳密なベンチマークではない点にご留意ください。また、今回はCodeQLでの検証は実施していません。

すべてのプルリクエストでGitHubリポジトリを自動スキャンする

標準のGitHubホストランナーは、パブリックリポジトリであれば無料で利用できます。プライベートリポジトリの場合でも、GitHub Freeプランには月額12ドル分の無料枠が含まれており、標準料金換算で2コアLinuxランナーを約2,000分実行可能です。以下のワークフローはプレーンなコマンドで構成しているため、組織（Organization）アカウントでもGitleaks Actionのライセンスキーを要求されることなく利用できます。

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

テスト用リポジトリでは4つのスキャナーすべてが終了コード1を返し、このゼロ以外の終了コードによってジョブが確実に失敗します。お使いの技術スタックに不要なステップは適宜外してください。同じパイプライン内でAPIテストを実行する方法については、GitHub ActionsでApidog CLIを活用するガイドをご覧ください。

あわせてDependabot alertsも有効にしておきましょう。全プランで無料で利用でき、プルリクエストの作成を待たずに継続して脆弱性を監視してくれます。

スキャナーが見落とす盲点：認可の不具合

認可（Authorization）のバグは、パターンスキャナーにとって検出が極めて困難です。正しいクエリ、正しいパラメータ、手前のauthミドルウェアなど、コードの構文自体には一切不備が見当たらないためです。欠陥の本質は「あるべき検証条件の欠落」であり、それが不可欠であることはデータモデルや業務ロジックを理解していなければ判断できません。

// 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]);

これは、OWASP API Security Top 10 2023で1位に挙げられている「オブジェクトレベルの認可の不備（BOLA: Broken Object Level Authorization）」に該当します。OWASPでは、クライアントから渡されたIDを使用するすべてのリクエストでアクセス権限を検証すること、そしてデプロイ前に認可の不備を検出できるテストを作成することを推奨しています。

コーディングエージェントの活用も有効です。テストリポジトリからコメントを除去し、組織に関するヒントを与えた場合と与えなかった場合の両方でClaude Codeにレビューを依頼したところ、どちらの条件でも請求書ルートの問題を的確に指摘しました。ただし、エージェントの利用プランに応じた費用が発生するため完全無料とはいかず、実行ごとに回答がブレる可能性もあります。

その点、自動テストならプルリクエストごとに明確な合否判定（Yes/No）が得られます。API側のセキュリティ対策については、API脆弱性の自動検出、APIセキュリティスキャンツールまとめ、およびAPIセキュリティテストチェックリストもあわせてご覧ください。

Apidog CLIを使ってコーディングエージェントに認可テストを作成させる

すべてのルートに対して手作業でテストを作成する必要はありません。Apidog CLIを使えば、コーディングエージェントにルートを解析させ、保護対象リソースごとにテストを作成させ、CIでそのまま実行できるテストスイートを自動構築できます。Apidog Freeプランなら最大4ユーザーまで利用可能です。

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

テスト環境には、2つの組織と各組織に所属するテストユーザーをシードデータとしてあらかじめ登録しておきます。準備ができたら、エージェントに以下のプロンプトを渡すだけです。

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.

エージェントはペイロードの構造を精査し、テストシナリオを自動生成してテストスイートを実行します。

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

ここで自組織のリソースに対する正常系テスト（ステータス200の確認）を入れておくことが極めて重要です。これがないと、ベースURLの設定ミスで404が返ってきた場合でも、テストが誤ってパス（成功）してしまうためです。

先ほどのCIワークフローに上記と同じapidog runのコマンドを追加し、テスト用組織のデータが投入されたプレビュー環境やステージング環境に対して実行します（本番データに対しては絶対に実行しないでください）。その他のオプションフラグについてはapidog runコマンドリファレンスを、エージェントのセットアップ手順についてはClaude CodeでのApidog CLI活用ガイドをご参照ください。

よくある質問（FAQ）

リポジトリの脆弱性を無料で検出する最善の方法は何ですか？ 依存関係スキャナー、Gitleaks、Semgrep Community Editionを組み合わせ、さらに認可チェック用のランタイムテストを追加することです。今回のテスト用リポジトリでも、単一のツールですべてを網羅できたものはありませんでした。

Vercel Security Reviewは無料ですか？ 無料で利用できるのは2026年11月10日までで、対象もProおよびEnterpriseチームに限定されています。それ以降はプロバイダーのトークン料金に加え、100万トークンあたり0.25ドルが課金されます。また、Vercelにデプロイされていないリポジトリは現時点でサポートされていません。

GitHubのシークレットスキャンはプライベートリポジトリでも無料ですか？ いいえ、無料ではありません。シークレットスキャンとCodeQLはパブリックリポジトリであれば無料ですが、プライベートリポジトリではアクティブコミッター1人あたり月額19ドルのGitHub Secret Protection、または月額30ドルのGitHub Code Securityの契約が必要です。なお、Dependabot alertsはどちらのリポジトリでも無料で利用できます。

Semgrepで認可のバグを検出できますか？ 今回試したルールセットでは、請求書ルートの脆弱性は検出されませんでした。Community Editionでは単一の関数やファイルを超えてデータを追跡することはできません。ただし、プロジェクト固有のコードパターンに合わせたカスタムルールを作成して対応することは可能です。

スキャナーを導入すればペネトレーションテスト（侵入テスト）は不要になりますか？ いいえ、代わりにはなりません。スキャナーや自動テストがカバーできるのは、既知のパターンやあらかじめ記述したテストケースに限られます。ペネトレーションテストは開発者が想定していなかった死角を見つけ出すものであり、Vercelの公式ドキュメントでも自社のレビュー機能は侵入テストの代替ではないと明記されています。