请不要通过公开 issue 报告安全漏洞。

两个渠道任选其一:

• GitHub 私密漏洞报告(推荐):在仓库的 Security 页面点「Report a vulnerability」。 报告只有维护者可见,修复前不会公开。
• 邮件至 security@threathunter.cn

请包含:

• 漏洞类型与影响范围
• 复现步骤或 PoC
• 你认为的严重程度
• 是否已在公开渠道披露

我们会在 3 个工作日内确认收到,并在 14 天内给出初步评估。修复发布后会在 release notes 中致谢报告者(如你希望匿名请注明)。

项目处于 0.x 阶段,只对最新的 0.x 版本提供安全修复,不做旧版本的向后移植。

关于 1.x 的重要提示:Nebula 1.x 已于 2019 年后停止维护,不再接受任何安全修复。其依赖的 Python 2、OpenResty 1.11、Esper 6、jackson 1.9、commons-collections 3.2.1 等组件均已 EOL 并存在公开的已知漏洞(其中 commons-collections 3.2.1 含经典反序列化利用链)。请勿在生产环境部署 1.x。

1.x 的认证与凭据管理也不符合当前的安全实践。我们不在公开文档中展开这些弱点的细节 —— 1.x 已归档且永远不会再发布补丁,细节只会帮到攻击者,帮不到还在运行它的人。

如果你仍在运行 1.x:迁移路径见从 1.x 迁移;在完成迁移之前,请确保它的管理端口不暴露在可信网络之外,并轮换所有从仓库配置中继承的凭据。需要具体建议可通过上述渠道联系我们。

2.0 在设计阶段就纳入了以下要求,详见 docs/security/:

凭据管理

• 零默认口令。首次启动生成随机凭据,或强制从环境注入;代码中不存在任何可用凭据的 fallback
• 全部配置外置,支持环境变量、文件、Kubernetes Secret 与 Vault
• CI 强制 secret scanning(gitleaks),发现疑似凭据即阻断合并

认证与授权

当前已生效:

• 用户口令使用 Argon2id。不含盐的单次哈希对弱口令没有实质保护,同口令的不同账号 哈希还相同。首个管理员账号的随机口令只在首次启动时打印一次

• 服务令牌只存 SHA-256 哈希,明文仅在签发响应中出现一次;可绑定来源网段,令牌与来源 IP 是 AND 关系。「令牌匹配 或 来源可信」这种 OR 式判定只要满足一个条件就 放行,等于两道防线各自都能被单独绕过

• 人与服务的权限不重叠:管理员不能调 /checkRisk,服务令牌不能访问任何管理接口

• 无状态鉴权,不签发会话 cookie。会话签名密钥若来自静态配置,一旦配置外泄,签名即可 被离线重放

• 未显式放行的路径一律拒绝

• 全部管理操作写入审计日志,记录的是通过认证的真实主体

• 登录失败按「来源 IP + 账号」组合计数,达到上限后锁定;锁定期内即便口令正确也拒绝 —— 否则「是否立刻返回成功」会告诉攻击者哪次猜中了,锁定就退化成延迟

🚧 规划中,尚未生效:OIDC 对接企业身份源、令牌自动轮换、管理接口的全局限流。

供应链

当前已生效:

• 采集器仅 1 个直接依赖(franz-go,Kafka 输出用,连传递依赖共 5 个模块),参考引擎零外部 依赖(仅 Node 内置模块)—— 依赖面仍然很小
  • 采集器此前是零外部依赖的。引入 Kafka 客户端是明确的项目决定,理由与代价见 internal/sink/kafka.go 的说明
• CI 强制凭据扫描(gitleaks)

🚧 规划中,尚未生效:每次构建生成 SBOM、依赖与镜像扫描(Trivy / Grype)接入 CI、依赖版本锁定与自动升级。

隐私

当前已生效:

• 敏感字段在采集端就地脱敏,原文不进入下游(39 个字段已分级并实现)
• 全部事件字段必须标注敏感级别,由测试强制

🚧 规划中,尚未生效:个人标识符的 HMAC / 加密列存储、保留期 TTL 自动执行、数据主体导出与删除接口 —— 这三项都依赖尚未实现的存储层。

星云处理的是业务流量,其中必然包含个人信息。部署前请确认:

1. 已按业务实际情况配置字段脱敏规则(默认规则从严,但无法预知你的自定义字段)
2. 已设置符合当地法规的数据保留期
3. 已限制控制台的网络暴露面,并配置了强认证
4. 已评估合规义务(中国大陆:个人信息保护法、数据安全法、网络安全等级保护)

详见隐私设计与合规。