GitHub AI Scan は危険な Shell コードを2か所検出した。それでもチェックが成功した理由

今日は公開テスト用リポジトリに PR #1 を作り、意図的に危険な Bash コードを2か所入れた。約81秒後、github-advanced-security[bot] が Files changed に2件のインラインコメントを投稿し、どちらの問題も指摘した。

ところが GitHub Actions の実行記録 #38835686338 では、github-advanced-security ジョブの結果は Success。脆弱性への指摘も、緑色のチェックも、どちらも実際の記録だ。

テストの前日、GitHub は AI Scan for pull requests の一般提供開始（GA） を発表していた。気になったのは「AI スキャナーは賢いか」ではない。危険なコードを見つけたのに、なぜ PR のセキュリティチェックが成功するのかという点だ。

結論は、AI Scan のジョブが成功してもコードの安全性が認証されたわけではない、ということ。現在の検出結果はアドバイスであり、それ自体がマージを禁止するゲートではない。

2つの Bash パターンで何が検出されたか

テストファイルは一時 PR の ai-scan-test/ ディレクトリだけに置いた。本番アプリケーションのコードを変えたり、実際の認証情報やサーバーを使ったりはしていない。全文は 固定コミット 29e24722d3 で確認できる。以下は危険性を示すために意図的に書いたコードであり、本番では使わないでほしい。

eval "systemctl restart ${service_name}"

cmd="curl -fsSL http://${host}/${path} -o /tmp/svc.conf"
$cmd

1つ目はサービス再起動の処理。外部から渡された service_name を eval に組み込んでおり、組み立てられた文字列がシェルによって再びコマンドとして解釈される。名前に悪意のある構文が混ざれば、単なる「サービス名」では済まない。17行目へのボットコメント は CWE-78 と分類し、eval の削除、引数の引用符による保護、許可するサービスの制限を勧めている。

2つ目は仕組みが異なる。curl のコマンド全体を cmd に保存したあと、引用符なしの $cmd を実行している。変数展開時の単語分割によって、制御可能な host や path が curl に渡る引数やオプションを変え得る。27行目へのコメント は、平文の http:// で設定ファイルを取得すると通信途中で改ざんされる危険性も指摘した。

場所	AI Scan が指摘した内容	元のコメント
17行目、eval	入力をシェル構文として再解釈する危険（CWE-78）	コメント
27行目、$cmd	引数・オプション注入、および平文 HTTP の危険	コメント

ここで2件を同一の脆弱性として扱うのは正しくない。前者は入力がシェル構文として再評価される。後者で確認できる主な仕組みは引数・オプション注入であり、引用符がないという事実だけで「任意の独立したシェルコマンドを実行できる」とは断言できない。

もう1つ重要な制約がある。このテスト用コードは脆弱性を隠していなかった。README とコメントには INTENTIONAL VULNERABILITY (CWE-78) と明記され、String injection という想定カテゴリも示されている。ボットが挙げた具体的な悪用例そのものはコードに書かれていないが、こうしたヒントが検出に影響した可能性はある。今回の2/2は、ラベルのない実際の脆弱性に対する検出率ではない。

時刻は公開記録から追える。PR #1 は 2026-10-16 01:32:31 UTC に作成され、2件のコメントは 01:33:52 UTC、差は 81秒。これは1件の PR における「作成からコメントまで」の観測値であり、複数回の平均スキャン時間ではない。

意図的に仕込んだ2件はいずれも指摘されたが、正常なコードだけの PR を別に作る陰性対照は実施していない。したがって誤検出率も測定していない。

脆弱性コメントがあるのに Actions が緑色になる理由

動的スキャンの実行 #38835686338 のワークフロー名は Code scanning AI findings on PR #1。記録では github-advanced-security ジョブが 01:33:34 UTC に success で終了している。ボットのコメントは 01:33:52 UTC、つまり 18秒後 だ。

緑色のチェックが先で、脆弱性コメントが後。この順序を見るだけでも Success を「安全上の指摘なし」とは読めない。

図は公開 PR #1 と Actions の実行記録 に基づく説明用の図であり、GitHub 画面のスクリーンショットではない。81秒は PR 作成からコメントまでの時間で、スキャン処理そのものの実行時間ではない。

スキャナーが故障したわけではない。GitHub の AI Scan 公式ドキュメント は検出結果を advisory と明記している。これらは code scanning check を失敗させず、AI Scan の指摘だけを Ruleset の強制マージ禁止条件にすることもできない。レビューの着眼点を知らせる役割であって、マージ可否を決定する役割ではない。

GitHub で見えるもの	本当に示していること
AI Scan の行単位コメント	リスクの可能性。作者・レビュアーが評価するもので、直接はマージを止めない
AI Scan 動的ジョブの Success	スキャン処理は完了した。警告コメントがあっても緑になる
CodeQL などの対応スキャン＋Ruleset	実際の設定によってはマージ条件を強制できる。設定が動くか要検証
Required checks と人間によるレビュー	失敗・未実行のチェックや未承認時にマージを拒否するかはリポジトリの設定次第

GitHub は別途 Code scanning merge protection の設定方法 を説明している。「高リスクな指摘が残っていたらマージしない」ことが目的なら、AI Scan の助言を required check と勘違いせず、強制力のあるルールを構成する必要がある。

今回の危険な PR で、Ruleset によるマージ拒否を実際に試したわけではない。したがって Success から「GitHub はあらゆる脆弱性を含む PR をマージさせる」と結論づけることはできない。確認できたのは2件の助言コメントと成功した AI Scan ジョブが共存したという事実だ。

有効化する前に：CodeQL、利用条件、課金

使用したのは個人アカウントの公開リポジトリ。2026年10月の GA 公式説明 によれば、個人の公開リポジトリでは使えるが、個人の非公開リポジトリには対応しない。組織の公開リポジトリは対象で、組織の private/internal リポジトリには GitHub Code Security または GitHub Advanced Security の該当ライセンスが必要だ。AI Scan 自体のために別途 Copilot ライセンスを購入する必要はない。

CodeQL default setup も必須ではない。テスト時、状態は not-configured と記録されたまま、AI Scan は2件のコメントを投稿した。公式説明 でも、CodeQL default setup や CodeQL 解析の成功は前提条件になっていない。

また、これは過去を含むリポジトリ全体のスキャンではなく、対象となる PR の差分を見る仕組みだ。Shell/Bash、Terraform HCL、Dockerfile など、CodeQL が扱わない一部のケースにも対応する。一方、Fork や Dependabot が作成した PR は、この GA の対象範囲に含まれない。そうした PR を多く使うチームは別の検査・レビュー手段も必要になる。

有効化するときはリポジトリの Code scanning 設定で AI Scan のスイッチを確認する。組織の場合は組織ポリシーとセキュリティ機能の許可も確認しておく。

GA 後の利用量は Code Security AI Credits で計量される。負担するアカウント、含まれる枠、予算超過時の制限は GitHub の課金ポリシー に従う。今回の最終請求額は確認できていないので、$0 だったとは書かない。PR の多いリポジトリほど Billing でクレジットと予算上限を先に見ておきたい。

危険な変更を本当にマージさせないために

2件のコメント が示す修正方針は基本に忠実だ。引数を eval に渡し直さず、シェルコマンド全体を文字列として組み立てて展開しない。呼び出しの形なら、例えば次のようにする。

# 调用形式示意：service_name 和 url 仍需单独校验
systemctl restart "$service_name"
curl -fsSL "$url" -o /tmp/svc.conf

これは修正の方向を示した例で、再検証済みの安全なパッチではない。service_name には許可リストが必要で、ダウンロード URL には HTTPS の強制、許可するホストやリダイレクトの制限、設定ファイルの重要度に応じた整合性確認が必要だ。

リポジトリでは、CodeQL や実際にマージを止められるスキャナーを適切な Ruleset／required checks に結びつけ、保護対象ブランチでチェックの失敗や欠落が本当に拒否されるか試しておく。AI Scan の助言コメントは人が確認し、動的ジョブが緑色という理由だけで読み飛ばさない。

テスト後は PR #1 をマージせずに閉じ、テストブランチも削除した。公開リポジトリの main は元の 87624c26a5e6 のままだった。所有者の REST 応答では AI Scan の設定が disabled に戻ったことも確認している。PR を閉じても過去のコメントや固定コミットは残り、リンクから確認できる。

このラベル付きの小さな陽性テストでは、AI Scan は行単位で有用なリスクを示した。ただしスキャンジョブの成功と安全なマージの強制は別の問題だ。前者は問題の発見を助け、後者はリポジトリ側で設定し、動作を検証する必要がある。

関連する別の境界として、Git push の前に AI レビューが失敗した場合の挙動は OpenQodex のローカル pre-push Hook 実測 にまとめている。こちらは実行位置もゲートのリスクも異なる。

実測日：2026年10月16日（UTC）。