OpenAI Daybreak Blue 测试：一个真实的网站安全发现
我的 OpenAI Daybreak Blue 测试在我自己的生产网站上发现了一个安全问题，而且我可以在全新的浏览器中复现：登录页面停留在 HTTP 上，而没有重定向到 HTTPS。该页面还通过同一个未加密连接加载了 20 个第一方资源。
这个结果之所以有用，原因很简单。模型不需要利用复杂或罕见的漏洞，就能得出有意义的发现。它识别出了一个基本的传输安全故障，对其进行了评级，并给出了一个可以验证的具体结论。一次独立的基线测试也发现了同一个核心问题。
这是一次针对我拥有的服务 Mixanalytic 进行的授权、非破坏性评估。我没有提交凭据、登录、利用网站、修改数据，也没有尝试建立持久化访问。
为什么要在真实网站上测试 Daybreak Blue
安全模型演示通常使用准备好的代码样例或已知存在漏洞的实验环境。这些测试是受控的，但无法展示模型如何处理一个上下文不完整的普通生产系统。
我想进行一次范围更窄、通过条件明确的测试：模型能否检查我拥有的网站的公开界面，发现一个可复现的问题，并区分证据与推测？
我还希望将其结果与独立基线进行比较。我曾使用类似的证据优先方法测试其他 AI 系统，例如在我的 AI 聊天机器人安全测试→中，最终有用的结果是一次经过验证的工程变更，而不是一个戏剧性的攻击故事。
我实际运行的是哪个模型？
第一次评估在一个独立的 Codex worker 中运行，该 worker 被分配给 `gpt-daybreak-blue-latest` 模型标识符。OpenAI 的文档将获批准的产品称为 GPT-Daybreak-Blue。
这个区别很重要。更改后续聊天中选择的模型，并不会追溯性地将之前的运行变成 Daybreak 测试。执行评估的运行本身必须使用获批准的 Daybreak 模型和产品界面。
OpenAI 将 Daybreak Blue 描述为大多数授权防御性工作的起点，包括漏洞发现、安全代码审查、威胁建模、检测工程、事件响应和补丁验证。该公司还建议对敏感操作使用受控环境、最小权限、明确范围和人工审查（Models and Trusted Access）。
OpenAI Daybreak Blue 测试设置与范围
我允许模型检查 Mixanalytic 及其本地项目文件。对外部检查，我保持了非破坏性范围：
模型不被允许提交登录表单、测试真实凭据、创建账户、上传 payload、利用疑似弱点或修改生产环境。
这一边界让结果更容易解读。每个发现都必须来自公开行为或只读源代码证据。
主要发现：登录页面停留在 HTTP 上
黑盒检查显示，网站根路径和登录路由都通过 HTTP 返回了 `200 OK`。两个响应都没有将浏览器重定向到 HTTPS。
随后，我在全新的 Chromium 上下文中打开了登录页面。浏览器停留在 `http://` URL 上，同时显示用户名和密码字段。在该页面加载期间，还有 20 个第一方 JavaScript、CSS、图像和文档请求使用了 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 预检请求不允许外部来源
来自无关来源的一次预检请求没有获得访问测试公开路由的许可。这是一个有用的否定结果，但仅限于我检查的端点和预检请求，并不是对整个网站的 CORS 审计。
Daybreak Blue 是否优于基线？
这次测试不支持对模型进行普遍排名。Daybreak Blue 和独立基线都发现了传输问题。加入浏览器证据后，基线的严重性评级有所提高。
Daybreak Blue 的价值在于，它专注于授权的防御性任务，并产出了我可以验证的发现。一个网站、一个范围和一个测试日期，无法证明它在源代码审查、事件响应、恶意软件分析或更大规模的渗透测试中会胜过其他模型。
更强的基准测试应在多个自有应用程序上重复相同的隐藏测试用例，为每个模型提供相同的工具和时间预算，并评估可复现性、误报、漏报、严重性校准和修复质量。
我在如何为真实工作评估 AI 模型→中使用了更广泛的评估方法。这次 Daybreak 运行是一份现场报告，而不是完整的基准测试。
如何获得 OpenAI Daybreak Blue？
Daybreak 访问权限需要通过 OpenAI 的 Trusted Access for Cyber 计划获得批准。个人可以通过个人 Trusted Access 申请进行申请，组织则可以使用企业申请表。
批准权限与获批准的身份或服务、workspace 或 API 组织和项目、模型以及产品界面绑定。完成身份验证或提交表单并不保证能够获得访问权限。Daybreak Red 也需要单独批准；Blue 访问权限不会自动包含它。
OpenAI 更广泛的 Daybreak 工作流将调查、代码仓库审查、证据、拟议修复和人工验证连接起来。其自身指南要求工程师对具有后果的变更负责（Scaling cyber defenders with Daybreak）。
来源与测试记录
我于 2026 年 8 月 30 日运行了这些授权检查。本文中的浏览器、标头、cookie、TLS、CSP、`security.txt` 和 CORS 观察结果均来自该测试记录。
模型和访问权限相关的说明来自 OpenAI 的两个一手来源：
根据 OpenAI 的访问指南，批准权限仍具体绑定到身份、workspace 或 API 项目、模型和产品界面。我的测试结果不超出上述 Mixanalytic 范围。
接下来我会修复并重新测试什么
传输问题的优先顺序很短：
如果任何登录页面、表单 action、第一方资源或会话 cookie 回退到 HTTP，重新测试就应当失败。我还会针对修复后的版本再次运行 Daybreak 和基线评估，以检查它们是否能够识别修复，并避免重复报告该问题。
第一次测试在没有越过授权边界的情况下产生了有用结果。Daybreak Blue 发现了一个真实缺陷。独立的浏览器证据说明了为什么它值得关注。下一个可信的结论不应是工具曾经成功运行过一次，而应是修复能够经受同样的测试。
---