Penpot爆红背后：开源设计工具的安全账怎么算

Penpot 今天新增了 52814 stars，这个数字在 GitHub 上并不多见。一个开源设计工具能引发如此关注，说明开发者对现有闭源设计工具（Figma、Sketch）的“数据主权”问题已经到了忍无可忍的地步。

但作为安全工程出身的人，我要追问的是：开源设计工具真的更安全吗？如果不是，开发者应该注意什么？

一、闭源 SaaS 设计工具：你的设计稿归谁管？

先不讨论 Penpot 的功能能否替代 Figma，单说安全层面，闭源 SaaS 设计工具有几个结构性问题：

• 数据管控权在服务商手里。 Figma 的 ToS 允许它在必要时候访问你的设计数据（比如为了提供支持或改进产品）。虽然它们有合规承诺，但对于金融、医疗、军工等受监管行业，将完整的 UI 设计稿（往往包含业务逻辑、API 路径、敏感字段）放在第三方云上就是合规违规。
• 攻击面在第三方。 Figma 的插件系统、协作 API、第三方集成都是攻击入口。2022 年 Figma 就发生过因为第三方 Cookie 泄露导致用户 Figma 文件被导出的攻击（虽然后来修补了）。
• 供应链风险不可控。 你签的是 Figma 的合同，用的是 AWS/Azure 的服务器。如果 Figma 内部人员作恶，或者 AWS 配置错误导致数据泄露，你连追责都很困难。

Penpot 的走红恰恰回答了这一点：要么自己掌控所有基础设施，要么接受别人的规则。 很多开发者厌倦了“信任但要核查”，他们要的是“不信任，直接自己管”。

二、Penpot 自托管：安全收益与隐藏代价

Penpot 是开源软件，后端用 Clojure，前端用 ClojureScript，数据存储支持 PostgreSQL + S3（或本地文件系统）。你可以把它部署在你的 VPC 内，数据不出你的网络。这是巨大的安全收益。

但自托管不等于自动安全。根据 OWASP 自托管应用安全基线，任何自行部署的 Web 应用都会引入三个需要开发者额外承担的责任：

1. 资产暴露面由你负责。 Penpot 默认监听 0.0.0.0:9000，很多新手直接暴露公网 IP 不设防火墙，导致管理后台、数据库端口可被扫描。
2. 版本更新靠你手动。 开源项目的漏洞披露到修复补丁发布之间有窗口期，你需要跟踪 CVE 并及时升级。Penpot 目前没有自动更新机制。
3. 认证与授权配置风险。 Penpot 支持 OIDC/OAuth2 集成，但如果你只配置了简单的密码登录，用户密码强度、会话管理、2FA 都需要你自己加固。

我的判断： 对于团队规模小于 20 人的工作室，自托管 Penpot 比使用 SaaS 设计工具更安全（因为减少了第三方数据暴露面）。但对于大型企业，需要专门的 SRE 团队维护，否则安全风险可能反而比使用 Figma Enterprise 更高。

三、Penpot 的攻击面分析（PoC 思路）

这里不是要攻击 Penpot 本身，而是从攻击者视角看自托管 Penpot 可能有哪些弱点：

• 未授权文件访问。 Penpot 将设计文件中的图片/矢量图存储在对象存储中。如果对象存储配置了公开读权限（比如配置错误的 S3 桶），任何知道文件 URL 的人都能直接下载设计稿。
• SSRF 风险。 Penpot 支持通过 URL 导入图片或 SVG。历史上很多开源协作工具（Mattermost、Jira）都因为未对 URL 来源做校验而被用作 SSRF 跳板。攻击者可以构造恶意 URL 探测内网服务。
• XSS through SVG design elements. 设计文件中的 SVG 可以包含 JavaScript。如果 Penpot 在导出或预览时未对 SVG 做适当的消毒（sanitization），用户打开设计稿就可能触发 XSS。这是设计工具类的经典漏洞。
• 协作 WebSocket 未授权订阅。 Penpot 使用 WebSocket 实时同步编辑状态。如果未验证用户对项目 room 的访问权限，攻击者可以通过劫持 WebSocket 连接窃听或注入编辑操作。

这些不是 Penpot 独有的问题，而是所有自托管协作工具的通用问题。开发者不能把“开源”等价于“安全”，需要主动进行安全配置。

四、防护方案：部署 Penpot 时的安全检查清单

以下是我基于生产环境经验整理的 Penpot 安全加固清单，可以直接用于部署前检查：

1. 网络隔离

• 将 Penpot Web 服务放在内网，通过反向代理（Nginx/Caddy）暴露 443 端口，禁止直接访问 9000。
• 数据库（PostgreSQL）只监听 127.0.0.1 或容器内网 IP，不暴露公网。
• S3 存储桶设置私有读写，只有 Penpot 应用服务器有访问权限。使用预签名 URL 提供下载。

2. 认证加固

• 强制使用 OIDC 或 SAML 集成企业身份认证 SSO，避免本地密码。
• 如果必须使用本地密码，配置密码复杂度策略（长度 >12，包含大小写数字特殊字符）。
• 启用会话有效期（默认 Penpot 会话不过期，需要自行配置）。

3. 输入过滤

• 在反向代理层（如 Nginx）配置 proxy_ignore_client_abort on 防止慢速攻击。
• 对 SVG 导入做消毒：可以使用 DOMPurify（前端）和 svg-sanitizer（后端）过滤 <script>、<onload> 等事件属性。
• URL 导入功能限制可解析的协议为 http/https，并配置白名单域名（如果允许的话）。

4. 日志与监控

• 开启 Penpot 的访问日志（默认关闭，需配置 PENPOT_HTTP_LOG 环境变量）。
• 将日志导入 SIEM（如 ELK），对异常访问模式（短时间内大量文件导出、来自未知 IP 的 WebSocket 连接）设置告警。
• 定期审计 S3 桶访问日志，检查是否有非预期的 GET 请求。

5. 更新策略

• 订阅 Penpot 的 GitHub Release 通知，或使用 Dependabot/greenkeeper 监控依赖漏洞。
• 建立一个“每月第一周升级”的规则，除非有 Critical 漏洞需立即升级。

五、开发者现在应该做的技术判断

Penpot 的火爆是一个信号：开发者对设计工具的数据主权要求已经从“可选项”变成了“必选项”。 如果你在评估是否将 Figma 替换为 Penpot，以下是我的建议：

• 如果你是个人开发者或微小团队： 直接用 Penpot 的官方云版本（penpot.app）即可，他们的云端安全投入比你自托管强。只有当你需要完全内部数据合规时才自托管。
• 如果你是中小规模企业（50-500人）： 自托管 Penpot 是一个可行的选择，但需要至少投入 0.5 个运维人力来负责部署、监控和升级。不要低估配置 HTTPS、OIDC、备份恢复的成本。
• 如果你是大企业： 先做安全评估。Penpot 目前没有完整的 SOC2/ISO 27001 认证，如果你需要这些合规才能使用，可能需要等 Penpot 企业版推出。

最后一个冷思考： 开源设计工具解决了“数据被第三方看到”的问题，但没有解决“设计文件本身的安全风险”。你团队成员之间的数据共享、设计稿中包含的 API Key（比如截图里的测试环境凭证）依然可能泄露。安全是系统工程，工具只是其中一环。

安全加固清单（可复制执行）

这份清单可以直接放到你的 Penpot 部署文档里。