请通过邮件私下报告，不要开公开 Issue：

• 邮箱：security@sectl.cn

请在报告中包含：影响范围、复现步骤、可能的利用方式。我们会在 7 天内确认收到，并尽快给出修复计划。 如果你是 SECTL 组织成员，也可以直接通过内部渠道联系维护者。

如果你的报告针对的是自建实例（你自己部署的那套），请先确认问题出在本仓库的代码里而不是你的部署 配置（反向代理、证书、暴露面）。这两类我们都会看，但处理方式不同。

服务端源码在本仓库可见、可审计（Elastic License 2.0），但它仍然是 一个可能被攻破、也可能被替换的组件——自建部署里它由部署者控制，官方云里它由我们控制，对设备而言 两者没有区别。因此下面四条是设计前提，任何改动都不得削弱：

1. 权力在设备手上：改变设备行为的操作必须能被设备本地授权拒绝；账号权限只决定"谁能下发"， 不决定"设备必须接受"。
2. 下发内容必须签名：策略与名单包以 Ed25519 签名，客户端验签后才应用。服务端身份本身不构成信任。
3. 命令必须可过期：动作型命令带 expiresAt，过期即丢弃，绝不补执行。
4. 可断连、可审计：客户端可本地一键断连且断网生效；所有远程操作留下审计记录。

自建模式引入本地账号与设备接入凭据后，第 1、2、3 条不变；第 4 条加强为"凭据可单独撤销"——撤掉一台 设备的接入凭据，只影响那台设备。

• 越权：绕过集控组角色或设备本地授权执行操作；
• 命令注入与重放：伪造、重放、篡改命令或期望状态；
• 策略包签名绕过；
• 节点身份冒充（nodeId 接管、重放注册、盗用或伪造接入凭据）；
• 跨组数据泄漏（A 组读到他组节点或数据）；
• 会话与凭据缺陷（会话伪造、重放、越权提升、撤销后仍可用）；
• 会导致远程执行任意代码的输入处理缺陷。

• 已获授权管理员的合法操作；
• 客户端被本地攻陷（能改本地文件的人本来就能改本地授权表）；
• 拒绝服务级别的流量攻击（由入口层处理）；
• 自建部署者的环境问题：明文 HTTP 暴露到公网、弱口令、把管理端口直接开到互联网、未按 deploy/ 的说明设置反向代理与 TLS。

协议的公开面是实现（src/SecRandom.Control/）；规范正文只在私有仓库维护， 不随本仓库发布。字段名一旦发布不再改名；新增能力不得改变既有字段语义。若你发现实现与规范不一致， 请按上面的方式报告。