OpenAI Daybreak Blue テスト：実際のウェブサイトセキュリティ上の発見
私の OpenAI Daybreak Blue テストでは、本番環境の自分のウェブサイトに、最新のブラウザーで再現できるセキュリティ上の問題が見つかりました。ログインページが HTTPS にリダイレクトされず、HTTP のままになっていたのです。また、同じ暗号化されていない接続を通じて、20 個のファーストパーティリソースも読み込まれていました。
この結果が有用だった理由は単純です。意味のある発見を得るために、モデルは特殊なエクスプロイトを必要としませんでした。基本的な通信経路の不備を特定し、優先度を付け、検証可能な具体的主張を提示しました。独立したベースラインテストでも、同じ中心的な問題が見つかりました。
これは、私が所有するサービス Mixanalytic に対して実施した、承認済みかつ非破壊的な評価です。認証情報の送信、ログイン、サイトの悪用、データの変更、永続化の試みは行っていません。
実際のウェブサイトで Daybreak Blue をテストした理由
セキュリティモデルのデモでは、準備されたコードサンプルや既知の脆弱なラボがよく使われます。こうしたテストは管理されていますが、コンテキストが不完全な一般的な本番システムをモデルがどのように扱うかは示しません。
そこで、より範囲を絞ったテストを行い、明確な合格条件を設定しました。自分が所有するサイトの公開領域をモデルが調査し、再現可能な問題を見つけ、証拠と推測を区別できるかどうかです。
また、その結果を独立したベースラインと比較したいと考えました。私は以前、AI チャットボットのセキュリティテスト→でも同様の証拠優先のアプローチで他の AI システムをテストしました。そこでは、劇的な攻撃の物語ではなく、検証済みのエンジニアリング上の変更が有用な成果となりました。
実際に実行したモデルはどれか？
最初の評価は、`gpt-daybreak-blue-latest` モデル識別子を割り当てた、別の Codex ワーカーで実行しました。OpenAI のドキュメントでは、承認済みの提供サービスを GPT-Daybreak-Blue と呼んでいます。
この区別は重要です。後のチャットで選択したモデルを変更しても、以前の実行が遡って Daybreak テストになるわけではありません。評価を実行する処理自体が、承認済みの Daybreak モデルとプロダクトサーフェスを使用する必要があります。
OpenAI は Daybreak Blue を、脆弱性の発見、セキュアコードレビュー、脅威モデリング、検知エンジニアリング、インシデント対応、パッチ検証など、承認済みの防御作業の多くにおける出発点として説明しています。また、機密性の高い操作については、管理された環境、最小権限、明確なスコープ、人によるレビューを推奨しています（Models and Trusted Access）。
OpenAI Daybreak Blue テストの設定とスコープ
モデルには、Mixanalytic とローカルプロジェクトファイルを調査する権限を与えました。外部からのチェックは非破壊的なものに限定しました。
モデルには、ログインフォームの送信、実際の認証情報のテスト、アカウントの作成、ペイロードのアップロード、疑わしい弱点の悪用、本番環境の変更を許可しませんでした。
この境界線により、結果の解釈が容易になりました。すべての発見は、公開された挙動または読み取り専用のソース証拠に基づく必要がありました。
主な発見：ログインページが HTTP のままになっていた
ブラックボックスチェックでは、サイトのルートとログインルートの両方が HTTP 経由で `200 OK` を返していることが示されました。どちらのレスポンスも、ブラウザーを HTTPS にリダイレクトしていませんでした。
その後、新しい Chromium コンテキストでログインページを開きました。ブラウザーにはユーザー名とパスワードの入力欄が表示されましたが、URL は `http://` のままでした。そのページの読み込み中、ファーストパーティの JavaScript、CSS、画像、ドキュメントのリクエストも 20 件、HTTP を使用していました。
| チェック | 観測結果 |
|---|---|
| --- | --- |
| HTTP リダイレクト | テストしたルートまたはログインページで HTTPS へのリダイレクトなし |
| 新しいブラウザー | Chromium は HTTP のログインページにとどまった |
| ファーストパーティリソース | そのブラウザー実行中に 20 件のリクエストが HTTP 経由で読み込まれた |
| 匿名セッション Cookie | `Secure=false`、`HttpOnly=true`、`SameSite=Lax` |
Cookie の結果には文脈が必要です。`HttpOnly` と `SameSite=Lax` は肯定的な属性でしたが、`Secure` フラグがないため、匿名セッション Cookie が暗号化されていない接続を通じて送信される可能性がありました。
ブラウザーテストの後、通信経路の問題を高リスクと評価しました。ネットワーク経路上にいる攻撃者は、HTTP トラフィックを監視または改変できる可能性があります。ユーザーがそのページで認証情報を送信した場合、暗号化されていない接続によって認証情報が露出する可能性があります。認証情報が盗まれた証拠は見つかっておらず、テスト中に認証情報を送信してもいません。
ブラウザーによる検証で重大度の評価が変わった
最初の独立したベースラインでは、HTTP の挙動は中程度の重大度に分類されました。しかし、実行時の検証によって、実際のパスワードフォームが HTTP のままになり、関連するリソースも HTTP 経由で読み込まれていることが示された後、その評価は変わりました。
この変化が示しているのは、モデル同士の違いというより、テスト方法の重要性です。ヘッダーの調査によって設定上の問題は特定できました。ブラウザーの証拠によって、訪問者がその問題にどのように遭遇するかが明らかになりました。追加の証拠により、影響が具体化され、より高い優先度を正当化できるようになりました。
Daybreak Blue も同じ中心的な結論に達しました。どちらの実行も、発見には再現可能な観測結果、範囲を限定した影響の説明、実施しなかった操作の明確な一覧を含めるべきだという同じ原則の恩恵を受けました。
追加チェックで見つかったこと
評価では、優先度の低い結果もいくつか得られました。
最新の TLS バージョンは機能していた
テストしたホストは TLS 1.0 と 1.1 を拒否し、TLS 1.2 と 1.3 を受け入れていました。これは HTTPS エンドポイントにとって肯定的な結果です。ただし、ログイン体験を HTTP のまま許可している問題を補うものではありません。
Content Security Policy がインラインコードを許可していた
観測された Content Security Policy には、スクリプトとスタイルに対する `'unsafe-inline'` が含まれていました。私はこれを、クロスサイトスクリプティングの脆弱性の証拠ではなく、ハードニング上の不足として扱いました。通常、インライン許可の削除にはアプリケーションの変更と回帰テストが必要になるため、通信経路の修正後に行うべきです。
サイトに `security.txt` がなかった
標準の `/.well-known/security.txt` パスは `404` を返しました。これは情報提供レベルに分類しました。セキュリティ連絡先ファイルは、研究者に明確な報告経路を提供しますが、存在しないこと自体が悪用可能な欠陥を生み出すわけではありません。
テストした CORS preflight は外部オリジンを許可しなかった
無関係なオリジンから送信した 1 件の preflight リクエストでは、テストした公開ルートへのアクセス許可が返されませんでした。これは、確認したエンドポイントと preflight に限定された有用な陰性結果です。サイト全体の CORS 監査ではありません。
Daybreak Blue はベースラインを上回ったのか？
このテストから、モデル全般のランキングを導くことはできません。Daybreak Blue と独立したベースラインは、どちらも通信経路の問題を発見しました。ブラウザーによる証拠を追加したことで、ベースラインの重大度評価が改善されました。
Daybreak Blue が有用だったのは、承認済みの防御タスクに集中し、検証可能な発見を提示したからです。1 つのウェブサイト、1 つのスコープ、1 つのテスト日だけでは、ソースレビュー、インシデント対応、マルウェア分析、大規模なペネトレーションテストなどにおいて、別のモデルを上回るかどうかを判断できません。
より強力なベンチマークでは、複数の所有アプリケーションに対して同じ未知のテストケースを繰り返し、各モデルに同じツールと時間枠を与え、再現性、誤検知、見逃した発見、重大度の調整、修正の品質を評価すべきです。
私は How to Benchmark AI Models for Real Work→ で、より広範な評価方法を使用しています。今回の Daybreak の実行は 1 件の現場レポートであり、完全なベンチマークではありません。
OpenAI Daybreak Blue を利用するには？
Daybreak へのアクセスには、OpenAI の Trusted Access for Cyber プログラムを通じた承認が必要です。個人は個人向け Trusted Access 申請から申請でき、組織はエンタープライズ申請フォームを利用できます。
承認は、承認された本人またはサービス、ワークスペースまたは API 組織とプロジェクト、モデル、プロダクトサーフェスに紐づきます。本人確認を完了したりフォームを送信したりしても、アクセスが保証されるわけではありません。Daybreak Red にも別途承認が必要であり、Blue のアクセスに自動的に含まれるわけではありません。
OpenAI のより広範な Daybreak ワークフローは、調査、リポジトリレビュー、証拠、修正案、人による検証を結び付けます。OpenAI 自身のガイダンスでも、重大な変更についてはエンジニアが責任を負うとしています（Scaling cyber defenders with Daybreak）。
情報源とテスト記録
承認済みのチェックは 2026 年 8 月 30 日に実施しました。この記事に記載したブラウザー、ヘッダー、Cookie、TLS、CSP、`security.txt`、CORS に関する観測結果は、そのテスト記録に基づいています。
モデルとアクセスに関する主張は、OpenAI の 2 つの一次情報源に基づいています。
OpenAI のアクセスガイダンスによると、承認は本人、ワークスペースまたは API プロジェクト、モデル、プロダクトサーフェスに固有のものです。私のテスト結果は、上記で説明した Mixanalytic のスコープを超えるものではありません。
次に修正して再テストする内容
通信経路に関する発見には、短い優先順位があります。
再テストでは、ログインページ、フォームの action、ファーストパーティリソース、セッション Cookie のいずれかが HTTP にフォールバックした場合に失敗とすべきです。また、修正済みバージョンに対して Daybreak とベースラインの評価を再度実行し、修正を認識し、同じ発見を繰り返さないことを確認します。
最初のテストは、承認範囲を越えることなく有用な結果を生み出しました。Daybreak Blue は実際の欠陥を発見しました。独立したブラウザーの証拠によって、なぜそれが注意に値するのかが示されました。次に信頼できる主張となるのは、ツールが一度機能したということではありません。同じテストに対して、修正が耐えられるということです。