仓库仍处于早期阶段。安全修复默认进入最新的受支持版本，不保证向旧版本回移植。

请优先使用仓库 Security 页面中的 Report a vulnerability 创建私有安全公告。报告中请包含：

• 受影响的版本或提交；
• 最小复现步骤；
• 实际影响与可能的攻击前提；
• 已验证的缓解方法（如有）。

如果仓库暂未启用 GitHub 私有漏洞报告，请只创建一个不含漏洞细节的普通 Issue，请求维护者提供私下沟通渠道。不要在公开 Issue、讨论、PR、日志或截图中粘贴利用代码、真实 API Key、Token、个人会话或数据库内容。

若发现凭据已经暴露，请立即在对应供应商处撤销并轮换；仅从当前分支删除并不能让已进入 Git 历史的凭据恢复安全。

Visualized Exp 当前是本地优先、单用户应用：

• Windows companion 仅监听回环地址，并将默认 DeepSeek Key 保存到 Windows Credential Manager；
• Java 后端加密保存模型覆盖与搜索供应商 Key，API 只返回“已配置”状态，不回显密钥；
• 浏览器通过同源 BFF 和 HttpOnly owner cookie 访问 Java 数据；该 cookie 是设备级隔离，不是账号认证；
• 模型与搜索请求 URL 会经过协议、地址和私网解析限制，但这些应用层限制不能代替网络层出站控制；
• 联网开关与搜索供应商配置相互独立，默认不会因为存在搜索 Key 就自动联网。

当前仓库不能直接视为安全的公共多用户 SaaS。公开部署方至少应自行提供并验证：

• 身份认证、授权、租户隔离和会话生命周期管理；
• 速率限制、并发控制、配额、费用预算和滥用检测；
• TLS、服务端 Secret Manager、最小权限与密钥轮换；
• 数据库备份、恢复、保留和删除策略；
• 出站防火墙或代理、审计日志、告警和依赖漏洞管理。

请勿将 APP_ALLOW_PRIVATE_PROVIDER_ADDRESSES 等放宽网络边界的选项用于不受信任用户可访问的公开环境。

• 不要提交 .env、数据库文件、运行日志或构建产物中的环境绑定。
• 测试必须使用明显的伪密钥，并阻止真实供应商网络请求。
• 不要给服务端密钥添加 NEXT_PUBLIC_ 前缀。
• 发布前应同时扫描当前文件与完整 Git 历史；发现历史泄露后应轮换凭据，并按 GitHub 的敏感数据清理流程处理所有可达引用。