GitHubは、CodeQLの組み込み分析が対応していない言語やframeworkにも対象を広げるAI-powered security detectionsをpublic previewとして提供した。findingはpull requestへ直接表示されるが、informationalでありmergeを自動的には止めない。導入時は「検出されたか」ではなく「誰が、いつ、どの基準で判断するか」を決める必要がある。
何が変わったか
pull requestが開かれるか更新されるとAI detection engineが分析を開始し、結果が返り次第PRへ表示する。AI由来のfindingにはAIラベルが付き、CodeQL結果と区別できる。enterprise policyで許可し、organizationで有効化し、repositoryでCodeQL default setupが動いていることが前提となる。
変更前後の差
従来のcode scanning coverageはCodeQL対応言語と設定した外部SARIF toolに依存していた。新機能はその外側をAIで補完する。一方、静的解析ruleのように再現性が固定されるとは限らず、findingはmerge protectionのblocking resultではない。レビュー担当が見落とせば、そのままmergeできる。
誰に影響するか
github.comでGitHub Code Securityを利用し、Copilot licenseを持つ顧客が対象である。public preview中は分析実行時にorganizationのAI Creditsを消費する。Enterprise owner、organization security manager、repository administrator、PR reviewerの設定と責任分担が必要になる。
期限
強制導入期限はない。previewであるため、全repository同時展開ではなく、言語・risk・teamを限定したpilotから始める。
必要な対応
Enterprise policyとorganization settingの変更者を限定する。AI findingを「修正必須」「security review必須」「参考」のどれへ分類するか基準を作る。重大度が高いfindingは、AI表示だけでなく再現手順、data flow、認可境界、実際の到達可能性を確認する。AI Creditsにはbudget alertを設ける。
実装・移行手順
- CodeQL default setupが安定しているpilot repositoryを選ぶ
- enterpriseで機能を許可し、organizationで限定有効化する
- 既知の脆弱・安全なPRを使って検出傾向を確認する
- AIラベルfindingのtriage ownerとSLAを定める
- merge前checklistまたはreview templateへ確認項目を追加する
- AI Credits、finding数、誤検知、見逃しを計測する
- 4週間程度の結果から対象拡大を判断する
失敗しやすい点
CodeQLをAI分析本体と誤認する、AI findingがmergeを止めると思い込む、AIラベルを低信頼として無視する、逆に全findingを即時修正する、credits上限を設けず全repositoryへ展開する、といった問題が起きやすい。
リスク
誤検知によるreview負荷、見逃しによる過信、同じ差分で結果が変わる可能性、機密code contextのAI機能利用policyとの不整合、credits消費の増加がある。preview仕様の変更も想定する必要がある。
評価方法
- PR当たりAI finding数
- security reviewerが有効と判定した割合
- false positive率
- 既存CodeQL・外部toolとの重複率
- finding確認に要した時間
- merge後に判明した見逃し件数
- repository当たりAI Credits
- PR lead timeへの影響
ロールバック
organizationまたはenterprise settingで機能を無効化し、CodeQL default setupと既存toolへ戻す。AI findingを根拠に追加したbranch ruleやreview templateは設定履歴からrevertする。無効化前に、未処理findingをexportまたはissue化して取りこぼしを防ぐ。
編集部分析
AI security detectionはCodeQLの代替ではなく、coverage gapを探す追加sensorである。価値は検出件数ではなく、従来見えていなかった有効な問題をどれだけ早く発見できたかで測るべきだ。blockingではない設計上、運用責任はGitHubではなく導入組織側に残る。
実務チェックリスト
- [ ] Enterprise policyの変更者を限定した
- [ ] pilot repositoryを限定した
- [ ] AI findingのtriage基準を定めた
- [ ] informationalでmergeを止めない点を共有した
- [ ] AI Credits budgetを設定した
- [ ] false positiveと見逃しを評価する
- [ ] 無効化手順を確認した