Fable 5 が使えるようになったので、PentaTrailのコードにOWASP Top 10セキュリティ診断を実施
目次
検証に強いモデルが手に入ったら、まず自分たちのコードに向ける
「超人的なAIには、ソースコードが要る」で書いたとおり、ソースコードを読んで脆弱性を見つける Anthropic の最上位モデル（Fable 5 / Mythos）は、輸出規制で一度止まっていました。その Fable 5 が、また使えるようになりました。
さっそく PentaTrail のコードベースへ OWASP Top 10 の自己診断を回しました。この記事は、その実際の記録です。
実施手法
OWASP Top 10 の10観点を、6体のエージェントに手分けさせて並列で走らせ、Critical / High / Medium / Low の観点で指摘させました。 1体に「全部見て」と頼むより、観点を絞って役割を固定したほうが、精度が上がって見落としが減ります。
- 静的診断：外から叩くブラックボックス検査ではなく、直近の修正まで反映した最新のソースコード(画面・API・データベース定義・スキャナ)を、そのまま読ませる方式です。
- 並列・バックグラウンド実行：6体を同時に走らせ、終わったものから結果を回収して突き合わせます。
- 深刻度で分類：各指摘を Critical / High / Medium / Low の4段階に仕分けさせます。
各担当には共通の掟を渡しました。指摘には必ず実在する場所(ファイルと行)の根拠を付ける。想像で書かない。同じパターンは1か所直して終わりにせず全部を洗う。 6体は互いの結論を見ません。同じコードを別々の角度から独立に見る ―― 一人の点検者を賢くするより、視点を増やして重ねるほうが、地味な見落としに強いからです。
10観点をどう割ったか
OWASP Top 10 は、Web アプリで起きやすい弱点を10の型にまとめました。
- 担当①：アクセス制御(A01)＋認証(A07) ―― 他人のデータを覗けないか、なりすませないか
- 担当②：暗号(A02)＋整合性(A08) ―― 秘密の置き忘れ、改竄や供給の信頼
- 担当③：インジェクション(A03) ―― SQL・画面・命令への注入
- 担当④：安全でない設計(A04)＋ログと監視(A09) ―― 業務ロジックの穴、気づけない／追えない
- 担当⑤：設定ミス(A05)＋古い部品(A06) ―― ヘッダや許可の緩さ、既知の弱点が残る依存
- 担当⑥：SSRF(A10) ―― サーバに内部へ通信させる細工
「見つけた」で止めない ―― 実データで裏を取る
ここがいちばんの勘所です。AI が「これは危ない」と言っても、それは仮説にすぎません。自己申告の「確認済み」を額面どおり数えると、たいてい水増しになります。
大事なのは、過去の変更履歴(差分)ではなく、いまその瞬間の状態を見にいくことです。権限の設定、関数の中身、鍵が本当に無効になっているか ―― それを推測ではなく事実で確定させる。実際、今回も「危なそう」に見えた指摘のいくつかは、実データベースに問い合わせた結果、すでに正しく閉じている／すでに無効化済みと分かって落ちました。ここを飛ばすと、塞いだつもりの穴が残ります。
結果 ―― Critical / High / Medium / Low で
| 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 |
Critical と High は、どの観点でもゼロ。 残ったのは Medium が5件、Low が16件 ―― いずれも多層防御をもう一段厚くするための"上乗せ"で、悪用できる致命傷ではありません。指摘事項については、いずれも即日修正を行い、対応しました。
まとめ
話題になっているだけあって、指摘の深度も内容も性能を裏付ける結果だったと思います。穴が出ないことではなく、穴を仕組みで見つけ続けられるかだと思うので、定期的に実行する仕組みを実装しようと思います。