GitHub AppSec使い方2026 本番脆弱性優先の運用テンプレ

GitHub AppSecを入れたのに、DependabotとCodeQLのアラートが多くて「どれから直せばいいの？」で止まっている人に向けた記事です。この記事を読むと、本番影響の高い脆弱性だけを先に直す運用を、今日から回せる形で作れます。僕は福祉事業のIT全般を担当しつつ、複数のAI×SaaS案件を並行で保守しているので、少人数でも回る優先順位設計をかなり重視しています。

なぜ今「本番影響あり」優先なのか（2026年版GitHub AppSecの前提）

2026年のGitHub AppSec運用は、重要度ラベルを上から順に消すやり方だと回りづらいです。理由はシンプルで、開発依存や未デプロイ成果物のアラートまで同じ画面に並ぶからです。つまり、危険度の「見た目」は高くても、今すぐ本番に影響しないものが混ざりやすいんですよね。

GitHub公式でも、DependabotとCode scanningを「本番に出ている成果物」基準で絞る考え方が明確になっています。artifact-registry-url、has:deployment、runtime-riskを使うと、デプロイ有無と実行時リスクを掛け合わせて見られます。イメージとしては、救急外来で軽症と重症を同じ列に並べず、まず重症の患者さんを優先する運用です。

• 判断軸1 — その依存関係は本番で実行されるか（scope:runtime）
• 判断軸2 — そのパッケージは直接依存か（relationship:direct）
• 判断軸3 — 実際に悪用されやすいか（EPSS）

最初にやることは「重大度を見る」ではなく「本番影響の有無を切る」です。

僕の現場でも、ここを先に切るだけで毎週の確認件数がかなり減りました。通知を減らすというより、修正対象を先に細くする感覚です。結果として、少人数でも修正サイクルを崩さず回せるようになります。

Dependabot側の優先順位付け設計（scope・EPSS・direct依存）

GitHub AppSec 使い方で最初に固定するフィルタ

Dependabot CodeQL 運用を揃えるなら、Dependabot側は「scope:runtime × relationship:direct × epss_percentage」を基準にすると迷いません。公開リポジトリでは、開発依存の低影響アラートを抑えるpreset（Dismiss low impact issues for development-scoped dependencies）が既定で有効なので、ノイズ削減の初速が出ます。

注意点は、重大度だけでP1にしないことです。 重大度が高くても開発依存なら、今すぐユーザー影響にはつながらないケースが多いです。

is:open tool:dependabot scope:runtime relationship:direct epss_percentage:>=0.5
has:patch is:open tool:dependabot scope:runtime

custom auto-triage rules（公開プレビュー）を使えば、EPSS・severity・scope・patch availabilityをルール化できます。1リポジトリ最大10ルールなので、最初はP1判定に直結する3〜5ルールから始めるのがおすすめです。チーム立ち上げ時は、公式ドキュメントと自社の運用ルールを並べて読み合わせると、認識合わせが速いです。

CodeQL側の優先順位付け設計（security-extended・query-filters・PRゲート）

CodeQLは「たくさん検出する」設定にしがちですが、運用では検出量よりも修正完了率が大事です。なので、security-extendedで重要な検出を広めに取りつつ、query-filtersで自チームに不要なタグやCWEを外し、PRゲートで重大アラートを止める構成が安定します。

name: "codeql"
on:
  pull_request:
  push:
    branches: [main]

jobs:
  analyze:
    permissions:
      security-events: write
      contents: read
    uses: github/codeql-action/analyze@v3
    with:
      queries: security-extended
      query-filters: |
        - exclude:
            tags contain: "experimental"
        - exclude:
            problem.severity: "note"

ポイントは、PRで止める基準を先に決めることです。 ここが曖昧だと、検出だけ増えてレビュー負荷が跳ねます。ルールセットで「High以上はマージ前に要修正」と決めると、開発者の行動が揃いやすいです。

実データでも、Autofix提案付きの脆弱性は全体で3倍速、XSSで7倍速、SQLiで12倍速で修正されたという公表があります。つまり、CodeQLは「検出ツール」だけでなく、修正の初速を作る運用パーツとして見ると強いです。

linked artifactsで本番コンテキストを付与する実装（deployment metadata）

ここが2026年運用の分かれ目です。DependabotとCodeQLを別画面で見ても、linked artifactsのdeployment metadataが入っていないと「本番で使われているか」の判定が弱くなります。逆にここを入れると、has:deploymentやruntime-riskで本番影響の高いものをすぐ抽出できます。

gh api -X POST orgs/${OWNER}/artifacts/metadata/storage-record \
  --input create-record.json

gh api -X POST orgs/${OWNER}/artifacts/metadata/deployment-record \
  --input create-deployment-record.json

{
  "artifact_url": "ghcr.io/org/app@sha256:...",
  "environment": "production",
  "runtime_risks": ["internet-exposed", "sensitive-data"]
}

登録時のruntime_risksは4種類です。critical-resource、internet-exposed、lateral-movement、sensitive-dataを使い分けます。たとえば外部公開APIならinternet-exposed、個人情報を扱うバッチならsensitive-dataを付けるだけでも、トリアージ精度が上がります。

• 抽出クエリ例 — has:deployment AND runtime-risk:internet-exposed AND epss > 0.5
• 狙い — 悪用されやすく、本番影響も高いアラートを先頭に集めること

この連携が入ると、脆弱性 優先順位付けが「勘」から「データ」に変わります。 僕の感覚だと、運用の納得感が一段上がります。

失敗しない導入手順（PoC→段階展開→メトリクス改善）

最後に、今日から動ける導入テンプレを置いておきます。いきなり全リポジトリへ展開すると設定差分で詰まりやすいので、PoCで1サービス回してから横展開が安全です。ここは急がず、でも止めずに進めるのがコツです。

1. PoC対象を1つ選ぶ — 本番トラフィックがあり、依存関係が多すぎないサービスを選びます
2. Dependabotルールを3本に絞る — runtime/direct/EPSS高だけ先に運用します
3. CodeQLゲートを設定 — High以上をPRで止め、例外フローをテンプレ化します
4. linked artifactsを接続 — deployment recordとruntime_risksを送信します
5. SLAを定義 — P1は72時間、P2は14日など期限を明文化します
6. 月次レビュー — 未対応件数、平均修正日数、再発率を追います

テンプレから始めたい人は、まず自社用の優先度判定表を小さく作ると初期設計がかなり楽になります。

この運用を入れないまま1年進むと起きやすいこと

この情報を知らないままだと、修正優先度が毎回ぶれて、結果的に「時間を使ったのに本番リスクが下がっていない」状態になる可能性があります。怖がる必要はないですが、放置コストは静かに増えます。

• 開発速度の低下 — PRレビューでセキュリティ判断が毎回止まります
• 運用疲れ — 低影響アラート対応で本当に危ないものが後回しになります
• 説明負荷の増加 — 監査や顧客説明で「なぜそれを後回しにしたか」を話しづらくなります

本番影響ベースのルールを先に決めるだけで、この3つはかなり避けやすいです。

この記事を書いている理由

僕自身、2025年に結婚式Web招待状サービスを継続運用して、90日以上ログイン継続率を追いながら改善してきました。そのとき実感したのが、ユーザー影響のあるリスクを先に潰す判断が、機能開発より先に価値を生む場面が多いということです。

今は福祉事業のIT全般を担当しつつ、複業でAI×SaaS案件も同時進行しています。体制が潤沢じゃない現場で回る方法を探し続けた結果、「本番影響あり」優先に絞る運用がいちばん再現性が高いと感じています。だからこそ、同じ悩みを持つ人に具体的な形で共有したいんです。

次のアクション

まずは1リポジトリでPoCして、P1条件だけ運用してみてください。回り始めたら横展開で十分です。進捗や詰まりポイントは、SNSでコメントしてもらえたらめっちゃ助かります。