セキュリティレポートは、マージされた修正につながってはじめて役に立ちます。CodeAuditAgentのレポートはその前提で設計されています。各指摘事項は素早く検証できる具体性を備え、そのまま調整して使えるパッチが付いています。本稿では、レポートの各部分、専任のセキュリティエンジニアがいない場合のトリアージの方法、そして修正が機能したことを確認する方法を説明します。
監査の対象
監査は、公開GitHubリポジトリか、貼り付けたコードスニペットのいずれかに対して実行されます。リポジトリの場合、CodeAuditAgentはデフォルトブランチを読み取ります。プライベートリポジトリをURLで監査することはできず、プルリクエストへのコメント機能はまだありません。結果はダッシュボードとエクスポートで確認できます。
リポジトリのどこまでを読むかはプランによって決まります。無料プランは1リポジトリ、月3回の監査、1回の監査につき最大20ファイルが対象です。Starterは月49ドルで、5リポジトリ、50回の監査、1回の監査につき40ファイル。Proは月199ドルで、リポジトリ数無制限、500回の監査、1回の監査につき80ファイルです。60KBを超える個別のファイルはスキップされます。月ごとの監査回数は各暦月の初め（UTC）にリセットされます。リポジトリ全体を監査する前に、気になる1ファイルをすばやく確認する手段として、スニペットの貼り付けも便利です。
これらの上限によってファイルが除外された場合、レポートには部分的なスナップショットであることが示されます。この表示は真剣に受け止めてください。部分的なレポートに問題がないということは、読み取られたファイルに問題が見当たらないという意味であって、リポジトリ全体が安全という意味ではありません。最も気にしているコードが除外されていたなら、スニペットとして貼り付けて監査するか、より多くのファイルを対象にできるプランで監査してください。
リスクスコア
すべてのレポートの先頭には0〜100のリスクスコアがあり、Markdownのエクスポートではその隣に全体の深刻度も表示されます。数値が高いほどリスクが大きいという意味です。これはその監査における指摘事項の要約であり、2つのことに役立ちます。どれだけ急いでそのリポジトリを見るべきかを決めること、そして時間の経過とともに改善しているかを追跡することです。
無関係なリポジトリ同士のわずかな差を深読みしないでください。スコアは常に監査した範囲に対する相対的なものであり、部分的なスナップショットではより少ないコードしか見ていません。この数値が最も意味を持つのは、同じリポジトリの修正前と修正後を比べるときです。
深刻度と確信度
各指摘事項には深刻度と確信度が付きます。この2つは別の問いに答えます。深刻度は、その指摘が本物だった場合にどれほど悪い事態になるか。確信度は、それが本物だとレビュー側がどれだけ確信しているかです。
- 緊急：公開エンドポイントへのインジェクション、認証バイパス、本番の認証情報の露出など、直接悪用可能で影響の大きいもの。
- 高：何らかの前提条件を必要とする実在の脆弱性、または影響が大きいものの限定的なもの。
- 中：他のバグと組み合わさったときに問題となる弱点、または中程度の影響を持つもの。
- 低：堅牢化の課題と、多層防御の不足。
- 情報：それ自体は脆弱性ではないものの、知っておく価値のある所見。
確信度は高・中・低の3段階です。確信度の高い指摘事項には、読み取られたコードの中に明確な根拠があります。確信度の低い指摘事項はたいてい、別のファイルにあるミドルウェア、データベースのポリシー、デプロイ時に設定される構成値など、監査からは見えなかったものに依存しています。確信度が低いからといって無視してよいわけではなく、修正の前に不足している文脈を人が確認すべきだということです。
指摘事項の構成
すべての指摘事項は同じ構成に従うため、いつも同じ順序で検証できます。
- タイトルとCWE：弱点の種類です。ユーザーが制御するキーによる認可バイパスならCWE-639といった具合です。CWEから、どんな修正が想定されるかがわかります。
- 位置：ファイルと行番号なので、該当コードを直接開けます。
- 根拠：ファイルから引用した関連コードです。引用が現在のコードと一致するか確認してください。その行がすでに変更されているなら、指摘が古くなっている可能性があります。
- 攻撃シナリオ：攻撃者が実際にその弱点をどう利用するかを、手順を追って示します。自分の状況で本物かどうかを判断する最も速い方法です。
- 修正パッチ：周囲のコードの書き方に合わせた変更案です。
パッチは、そのままマージできるコミットではなく、有力な出発点として扱ってください。監査が読み取ったコードから書かれているため、あなたのヘルパー関数やORMの慣習、コードベースの別の場所にある呼び出し元を把握していない可能性があります。典型的なパッチは小さく、対象を絞ったものです。
--- a/app/api/invoices/[id]/route.ts
+++ b/app/api/invoices/[id]/route.ts
@@
- const invoice = await db.invoice.findUnique({ where: { id } });
+ const invoice = await db.invoice.findFirst({
+ where: { id, userId: session.user.id },
+ });
if (!invoice) return Response.json({ error: 'not_found' }, { status: 404 });良い点の指摘と次のステップ
レポートには、うまくできている点も列挙されます。パラメータ化クエリが一貫して使われている、シークレットが環境変数から読み込まれている、Cookieの設定が厳格である、といった点です。ここも読む価値があります。どのパターンを維持し、新しいコードに広げるべきかがわかりますし、コードベースの状態を誰かに説明するときにも役立ちます。
推奨される次のステップの節は、指摘事項を順序立てた計画に変えます。関連する指摘をまとめてくれることも多く、たとえば所有者チェックの欠落が複数あるなら、5つの個別パッチではなく共有ヘルパー1つで直すのが最善だと示してくれます。
小規模チームのためのトリアージの進め方
セキュリティエンジニアがいないときのリスクは、レポートを無視することではありません。緊急の指摘が待っているあいだに、低い指摘へ1日を費やしてしまうことです。単純な順序でうまくいきます。
- まず緊急と高の指摘事項をすべて読みます。それぞれについて攻撃シナリオを読み、本物か、本物でないか、文脈の確認が必要かを判断します。
- 本物の緊急の指摘はその日のうちに修正します。修正に時間がかかるなら、エンドポイントの無効化やチェックの強化といった一時的な緩和策を入れます。
- 文脈の確認が必要な指摘については、不足している部分を調べます。それをすでに防いでいるミドルウェア、行レベルのポリシー、設定はありませんか。答えは書き留めておきましょう。
- 高の指摘は現在のスプリントに、中はバックログに入れ、低と情報はまとめて堅牢化のまとまった作業にします。
- 本物でないと判断した指摘は、その理由を記録します。そのメモが、次の人が同じ調査を繰り返す手間を省きます。
各指摘事項には担当者を1人割り当ててください。チーム全員のものとされた指摘は、誰のものでもなくなりがちです。
指摘事項エクスプローラーとエクスポート
監査がいくつか溜まってきたら、個々のレポートよりも指摘事項エクスプローラーのほうが作業しやすくなります。複数の監査を横断して指摘事項を一覧し、深刻度、CWE、リポジトリで絞り込めます。特に便利なのがCWEでの絞り込みです。同じ弱点が3つのリポジトリに現れるなら、たいていは共通のパターンかヘルパーの不足を示しており、個々の事例を直すよりパターンを直すほうが安上がりです。
指摘事項はエクスプローラーからCSVでエクスポートでき、課題管理ツールや表計算ソフトへの取り込みに便利です。個々のレポートはMarkdownでエクスポートでき、プルリクエストの説明、社内Wiki、修正を担当する委託先へのメッセージにそのまま読みやすい形で貼れます。
再監査で修正を確認する
修正は、確認するまで完了ではありません。マージしたら、同じリポジトリで新しい監査を実行してください。各レポートは前回の監査と比較できるため、どの指摘が消え、どれが残り、新しいものが出ていないかを確認できます。実在の問題を修正すればリスクスコアは下がるはずです。下がらない場合は、比較を見て理由を確かめましょう。
比較は公平に保ってください。1回目が部分的なスナップショットで、2回目が別のファイルを読んでいたなら、その差は修正だけでなくカバー範囲も反映しています。監査は月ごとの割り当てから消費されるため、コミットのたびに再実行するより、いくつかの修正をまとめてから再監査するほうがたいてい得策です。
レポートが対象としないもの
限界を知っておくと、隙間を埋められます。監査が読むのはソースコードであり、既知の脆弱なバージョンを探して依存関係をスキャンするわけではないため、パッケージマネージャー内蔵のものやGitHubのものなど、依存関係スキャナーも併用してください。監査は、デプロイ時の設定、リポジトリ外のインフラ、スキップされたファイルを見ることはできません。そして人間であれAIであれどのレビュアーとも同じく、監査は誤ることもあります。根拠と確信度が示されているのは、鵜呑みにするのではなく素早く検証してもらうためです。
このように使えば、レポートは根拠の付いた短い優先順位付きの変更リストになります。緊急のものを直し、確信の持てないものを確認し、再監査して、スコアが動くのを見届けましょう。