OWASP Top 10 をAIで自己診断：自社コードに回した記録
目次
ソースコードを読んで脆弱性を見つける Anthropic の最上位モデル、Fable 5 が戻ってきました。ソースコードを持つ者だけの最先端AI に書いたとおり輸出規制で一度止まっていたもので、再開した2026年7月に PentaTrail のコードベースへ OWASP Top 10 の自己診断を回しました。
10 の観点を 6 体のエージェントに手分けさせ、出てきた指摘を実データに当てて確定させるまでの記録です。
10 の観点を 6 体に分け、互いの結論を見せずに走らせた
OWASP Top 10 は Web アプリで起きやすい弱点を10の型にまとめたもので、これを担当ごとに割り当てました。1 体に「全部見て」と頼むより、観点を絞って役割を固定したほうが、精度が上がって見落としが減ります。
図1：10 の観点を 6 体へ割った内訳（観点の正式な名前は付録の表2）
深掘り：6 体に渡した共通の掟
各担当には同じ掟を渡しました。実在する場所（ファイルと行）の根拠を必ず付けること、想像で書かないこと、同じパターンを 1 か所直して終わりにせず全部を洗うこと。6 体は互いの結論を見ないので、同じコードを別々の角度から独立に読みます。一人の点検者を賢くするより、視点を増やして重ねるほうが、地味な見落としに強いからです。
外から叩くのではなく、直近の修正まで入った最新のソースコードを読ませた
外から叩くブラックボックス検査で触れるのは公開された入口までですが、今回は画面・API・データベース定義・スキャナのソースをそのまま読ませています。
図2：外から叩く検査とソースを読む診断で、届く範囲が違う
深掘り：6 体を並列で走らせ、終わったものから突き合わせる
6 体は背景で同時に走らせ、終わったものから結果を回収して重ね合わせます。ただしコードを読むだけでは、いま本番でその権限がどう設定されているか、鍵が生きているかまでは分かりません。だから指摘はここではまだ仮説のままで、次の照合が要ります。
AI が「危ない」と言った時点では仮説で、実データに当てて初めて確定する
自己申告の「確認済み」を額面どおり数えると、たいてい水増しになります。見にいくのは、過去の変更履歴ではなく、いまその瞬間の状態です。
図3：指摘を実データに当てて、残るものと落ちるものに分ける
深掘り：実際に落ちた指摘がある
見にいったのは、権限の設定、関数の中身、鍵が本当に無効になっているかです。今回も「危なそう」に見えた指摘のいくつかは、実データベースに問い合わせた結果、すでに正しく閉じている、あるいは無効化済みと分かって落ちました。ここを飛ばすと、塞いだつもりの穴が残ります。
Critical と High は、10 の観点すべてでゼロだった
確定した指摘は21件で、内訳は Medium が5件と Low が16件です。
図4：確定した21件の深刻度の内訳（観点ごとの件数は付録の表1）
残った21件は、多層防御を一段厚くする上乗せだった
悪用できる致命傷ではなく、既定をより締まった側へ寄せる類の指摘です。件数が集まったのは設定ミス（A05）の6件で、指摘はいずれも即日修正しました。
図5：21件はすべて、すでにある守りをもう一段厚くする側だった
深掘り：残った指摘の中身
秘密情報の取り回しをより厳格な運用へ寄せること、ヘッダやアクセス許可の既定を締まった側へ寄せること、取り込むデータや実行物の出どころの確からしさを高めること、記録の匿名化と本番で余計な情報を残さないための調整、サーバーの外向き通信の経路をより厳密に固定すること、一部の依存部品を新しい版へそろえることが残りました。アクセス制御（A01）と認証（A07）は、実データベースまで照合しても指摘がゼロです。
同じ診断を、ソースの無い外側の攻撃面へ広げる
自社のコードなら中身まで読めますが、他社から見える攻撃面にはソースがありません。穴が出ないことより、穴を仕組みで見つけ続けられるかのほうが効きます。
図6：ソースが読める内側と、ソースの無い外側で、AI が読むものが変わる
同じ AI で会社の外側の攻撃面を継続的に点検する仕組みは、14日間無料で試せます。
付録：観点ごとの結果と、6 体への割り当て
表1：OWASP Top 10 の観点ごとの指摘件数
| OWASP Top 10 | Critical | High | Medium | Low | 中身（ぼかし） |
|---|---|---|---|---|---|
| A01 アクセス制御 | 0 | 0 | 0 | 0 | 契約（テナント）の境界と権限。実DB照合でも越境なし、指摘ゼロ |
| A02 暗号の失敗 | 0 | 0 | 0 | 2 | 秘密情報の取り回しを、より厳格な運用へ寄せる上乗せ |
| A03 インジェクション | 0 | 0 | 0 | 1 | 外部由来の入力を扱う箇所の防御を、念のため一段ぶ厚く |
| A04 安全でない設計 | 0 | 0 | 0 | 3 | 想定外の使われ方への耐性と、失敗時に安全側へ倒す詰め |
| A05 設定ミス | 0 | 0 | 2 | 4 | ヘッダやアクセス許可の既定を、より締まった側へ寄せる調整 |
| A06 古い・脆弱な部品 | 0 | 0 | 1 | 1 | 一部の依存部品を、より新しい版へそろえる |
| A07 認証の不備 | 0 | 0 | 0 | 0 | パスキー中心の認証まわりは健全、指摘ゼロ |
| A08 整合性の失敗 | 0 | 0 | 1 | 1 | 取り込むデータや実行物の"出どころ"の確からしさを高める |
| A09 ログと監視 | 0 | 0 | 0 | 2 | 記録の匿名化と、本番で余計な情報を残さないための調整 |
| A10 SSRF | 0 | 0 | 1 | 2 | サーバーの外向き通信の経路を、より厳密に固定する徹底 |
| 合計 | 0 | 0 | 5 | 16 |
表2：6 体への割り当てと、それぞれが探したもの
| 担当 | 観点 | 探したもの |
|---|---|---|
| ① | A01 アクセス制御 / A07 認証の不備 | 他人のデータを覗けないか、なりすませないか |
| ② | A02 暗号の失敗 / A08 整合性の失敗 | 秘密の置き忘れや、改竄・供給の信頼 |
| ③ | A03 インジェクション | SQL・画面・命令への注入 |
| ④ | A04 安全でない設計 / A09 ログと監視 | 業務ロジックの穴や、気づけない・追えない状態 |
| ⑤ | A05 設定ミス / A06 古い・脆弱な部品 | ヘッダや許可の緩さ、既知の弱点が残る依存 |
| ⑥ | A10 SSRF | サーバーに内部へ通信させる細工 |
件数は、このときのコードベースで確定した値です。観点の並びと名前は OWASP Top 10 の2021年版に沿っています。
