安全
SkillFlaw 是一个应用平台，它可以运行用户编写的流程、调用外部服务、处理文件，并在某些场景下执行自定义代码路径。
这意味着：安全首先是一项部署责任，而不只是功能清单上的一项勾选。
SkillFlaw 提供了认证、鉴权、可见性与管理边界，但你不应把一个共享的 SkillFlaw 运行时，当成执行不受信任代码或承载恶意租户的安全沙箱。
注意
你需要为 SkillFlaw 所运行环境的整体安全姿态负责，包括：
- 基础设施隔离
- 网络暴露边界
- Secret 管理
- 传输安全
- 自定义代码、导入资源与用户输入的安全处理
用实际运维语言理解安全模型
对于当前版本的 SkillFlaw，请默认以下事实都成立：
- 流程可能会根据启用的组件触发对外网络访问
- 自定义代码与“接近代码”的工作流，应该按应用代码同样谨慎对待
- 公开 API、webhook 与 MCP 端点都必须像其他公网服务那样被保护
- 部署拓扑会直接影响攻击面：仅 backend、完整 Web，以及 docs 暴露，攻击面都不同
如果你要把 SkillFlaw 暴露到互联网，请尽量把公网面收缩到最小。
安全的本地开发
在本地开发与调试时：
- 只运行你信任的流程与组件
- 不要在本地环境复用生产 Secret
- 把
SKILLFLAW_SECRET_KEY_FILE放在仓库外部 - 在测试不受信任的自定义代码或导入资源时，使用隔离或一次性环境
如果你在实验第三方代码，容器化或其他隔离执行方式会更安全。
安全面向公网的部署
对于任何真实公网部署：
- 在可控入口层（如 Nginx 或 Kubernetes ingress）终止 TLS
- 对
/health、/api/*和/api/v1/mcp/streamable保持明确路由 - 只有在确实需要浏览器 UI 时才公开 frontend
- 只有在确实需要公开文档时才公开 docs
- 把凭据与 API Secret 放在镜像外部
- 把
SKILLFLAW_SECRET_KEY_FILE挂载为真实的 secret 文件 - 把
SKILLFLAW_CONFIG_DIR放在可写持久化存储上
关于反向代理的具体建议，请参阅 在 Nginx 与 HTTPS 后部署 SkillFlaw。
面向托管或多租户场景的安全建议
如果你要为多个客户、多个团队，或其他不受信任工作负载运行 SkillFlaw，不要只依赖单个共享运行时作为唯一安全边界。
至少应规划这些基础设施级隔离：
- 对彼此不可信租户使用独立进程或独立工作负载
- 使用隔离的可写存储
- 限制其访问私有服务的网络可达性
- 为数据库凭据设置受控范围
- 为不同环境划分 Secret 边界
应用层权限很重要，但在涉及自定义代码、文件处理或外部集成时，它不能替代基础设施隔离。
认证与 API 暴露
SkillFlaw 的 API 与 MCP 端点，应遵循与你其他服务相同的认证预期。
实践上：
- 在公网环境中保持 API 认证开启
- 保护使用
/api/v1/mcp/streamable的 MCP 客户端 - 把 webhook 与 run 端点视为正式生产 API 面
- 公开分享自动生成或复制的客户端代码片段前，先审查其中的安全信息
关于 MCP 的专项说明，请参阅 将 SkillFlaw 用作 MCP 服务器。
运维加固检查表
在称某个部署“可用于生产”之前，请至少确认：
- 使用的是当前受支持版本
- 对真实用户流量强制启用 TLS
- PostgreSQL 与 Redis 没有被广泛暴露
- 除非你在受控环境中明确需要，否则
SKILLFLAW_ENABLE_SUPERUSER_CLI=false - 已经具备备份与回滚流程
- 持续监控日志与健康检查
安全通告与漏洞报告
关于已报告漏洞、修复版本与披露流程，仓库安全策略是唯一事实来源：
如果你发现了漏洞，请优先通过仓库 GitHub Security 页签私下报告，不要先公开披露。