page-agent安全漏洞报告流程解读：SECURITY.md里的正确姿势-开发者社区

page-agent安全漏洞报告流程解读：SECURITY.md里的正确姿势

【免费下载链接】page-agentJavaScript in-page GUI agent. Control web interfaces with natural language.项目地址: https://gitcode.com/GitHub_Trending/pa/page-agent

page-agent是一个运行在网页内的 JavaScript GUI Agent，用一句自然语言就能驱动页面完成点击、填表等操作。正因为 AI 能直接操作你的网页、甚至浏览器标签页，"安全"就格外重要。这篇文章带你完整解读 docs/SECURITY.md 里的安全策略，讲清楚当你发现 page-agent 的安全漏洞时，应该走什么样的报告流程、报告里要写什么、哪些情况维护者会优先处理——新手照着做，一次就能报对。

📁 一分钟了解 SECURITY.md

这份安全策略文件位于仓库根目录，打开路径很简单：

docs/SECURITY.md

它由四个部分组成：支持的版本→漏洞报告渠道→报告内容要求→披露规则。下面逐条拆解。

🧩 支持哪些版本：先升级，再报告

版本	是否提供安全修复
`main`分支	✅ 支持
`page-agent`及 workspace 各包的最新 npm 发布版	✅ 支持
更早的历史版本	❌ 不支持

💡新手提示：如果你发现了一个疑似漏洞，务必先升级到最新版本再验证一次。很多"漏洞"在新版本中已经修复，对旧版本报告问题，维护者通常不会受理（这一点在 Scope 一节里也被明确列为不受理情形之一）。

🚨 报告渠道：千万不要发公开 Issue

这是全文最关键的一句话：

请勿通过公开的 GitHub Issues、Discussions 或 Pull Requests 报告安全漏洞。

正确姿势是使用平台的私有漏洞报告流程：

打开 page-agent 项目仓库的security/policy页面；
点击Report a vulnerability按钮发起私有报告。

为什么必须是私有的？漏洞一旦被公开，攻击者可能抢在修复之前利用它，而你的项目用户会暴露在风险中。只有在私有渠道确实不可用时，才允许开一个极简的公开 Issue——仅用于请求建立私联渠道，且绝对不能包含任何漏洞利用细节。

✍️ 报告里必须包含的 5 个要素

SECURITY.md 对报告内容给出了明确清单，建议直接当成模板使用：

受影响的包或功能—— 是核心库page-agent、Chrome 扩展，还是其他 workspace 包；
精确的版本号、commit 或构建号—— 让维护者能一键复现你的环境；
浏览器、操作系统、运行时环境—— 漏洞可能与特定环境强相关；
复现步骤或概念验证（PoC）—— 能稳定复现的报告，优先级最高；
预期影响—— 说明攻击者能借此做什么，帮助维护者判断严重性。

✅加分项：复现步骤写得越具体（页面地址、操作顺序、截图），响应速度通常越快。

🎯 什么算"真漏洞"：Scope 边界解读

维护者优先处理的是真实的安全边界失效，典型包括：

🔓未授权访问数据、Token 或扩展能力；
🛡️绕过显式的安全约束（如操作黑名单、高危指令限制）；
📄默认行为导致敏感数据泄露。

反过来，以下情形通常不会被受理：

不受理情形	原因
忽略文档说明、自行做的不安全集成	属于使用不当，而非产品缺陷
主动把密钥（secrets）打进客户端构建	客户端本身不保密钥，属于集成方失误
针对不支持的旧版本	无修复义务

⚠️结合产品特性理解：page-agent 提供了元素操作黑白名单（禁止 AI 操作删除、支付等敏感按钮）和 Instruction 安全约束（高危操作完全禁止或需用户确认）等机制。如果你发现这些内置防护可以被绕过（比如 AI 仍操作了黑名单元素），那就是典型的"绕过显式安全约束"，属于优先处理的报告类型。