企业官网建设流程全解析

• 人工智能
• AI Agent
• 多模态
• 语音
• AI 应用

本文基于 TEN-framework 仓库内随附的 curl 源码树（third_party/curl/SECURITY.md）及其配套的 SECURITY-PROCESS.md、SECURITY-ADVISORY.md，系统梳理 curl 项目从"漏洞上报→确认→修复→发布"的完整安全流程、四级严重性分级标准、哪些问题"不算漏洞"的判定清单，以及安全公告（Security Advisory）的规范撰写格式；同时结合该 curl 源码树在 TEN 框架中的实际集成方式（构建配置、版本与 TLS 依赖），说明在依赖 libcurl 的工程中如何落实这一套安全实践。

为什么关注 curl 的安全流程

curl 是互联网上部署最广泛的网络传输工具与 libcurl 库，其安全漏洞一旦被利用，波及面极广。本仓库将 curl 源码整体 vendored 在 third_party/curl 目录下，作为 TEN 框架运行时的网络传输组件之一，因此 curl 官方定义的"什么算漏洞、按什么流程处理、如何对外披露"直接决定了一个基于 TEN 框架构建的语音 AI 应用在网络层面临的风险治理方式。

从构建配置看，本仓库通过 third_party/curl/BUILD.gn 以 CMake 工程方式构建 libcurl：默认curl_use_shared_lib = false（见 third_party/curl/output_libs.gni），即默认产出静态库libcurl.a；TLS 后端选择CURL_USE_MBEDTLS=ON，并公开依赖//third_party/mbedtls。源码树中的版本标识为 8.1.2-DEV（见 third_party/curl/include/curl/curlver.h）。这意味着读者在使用 TEN 框架时，实际随包使用的是静态链接的 libcurl，安全更新节奏与上游 curl 8.x 系列保持一致。

漏洞上报：走 HackerOne，不进公开 Bug 追踪器

curl 项目对漏洞上报渠道有严格约定：

• 发现或怀疑 curl / libcurl 存在安全问题，一律通过 HackerOne 平台的 curl 项目提交，该渠道的报告只会到达少数被选定的受信任人员手中。
• 与"未公开漏洞的上报或管理"无关的消息会被忽略，无需进一步处理。
• 所有已知且已公开的 curl / libcurl 漏洞，统一收录在 curl 官网的 security 页面（本仓库内不保存该列表）。

最关键的保密原则是：在漏洞被正式公告之前，不得将其登记进项目的公开 Bug 追踪器——因为追踪器条目本身就是公开的；也不得在任何公开邮件列表上讨论，提交相关 commit 的消息也不得暗示其安全性质。也就是说，整个修复过程必须在私有空间内完成，直到正式披露。

漏洞处理全流程：从报告到发布的时间线

SECURITY-PROCESS.md 给出了标准处理流程，核心环节如下：

1. 上报：报告人在 HackerOne 提交漏洞详情。
2. 确认收到：安全团队中有人工回复报告人，确认报告已被看到。
3. 调查与裁决：安全团队调查报告，决定拒绝或接受（拒绝标准见后文"不算漏洞"清单）；被拒时向报告人书面解释原因；被接受时通知报告人并开始修复。
4. 修复与排期：团队讨论问题、制定修复方案、评估影响范围并建议发布排期，讨论应尽可能让报告人参与。信息发布应"尽快"，多数情况与包含修复的下一个版本同步；若报告人或相关方认为下一版本太远，应考虑单独提前发版。
5. 撰写安全公告草稿：说明问题是什么、影响面、影响哪些版本、解决方案或规避方法、修复发布后应如何操作，并正确署名所有贡献者；同时为漏洞确定 CWE（Common Weakness Enumeration）编号（参见 SECURITY-ADVISORY.md）。
6. 申请 CVE 编号：通过 HackerOne 的 CVE 申请流程获取 CVE 号，并回填到安全公告中。
7. 私有分支修复：修复提交在私有分支上，commit message 应尽量包含 CVE 号。若严重级别为 Low 或 Medium，允许通过普通 PR 合入主干——但不得提及这是安全漏洞。
8. 提前通知发行方：发布前最多 10 天，将公告草稿（含 CVE 与当前补丁）发给 distros@openwall 邮件列表以便发行方提前准备；该列表不接受超过 14 天的 embargo，也不关心仅 Windows 平台的缺陷。
9. 发布前合入：发布前最多 48 小时，将私有分支合入主干并推送。一旦推送即公开，正式版本必须立即跟进发布；推送与发布之间的时间仅用于最终测试与评审。
10. 正式发布与公告：项目组创建包含修复的版本，按常规发布渠道（curl-announce、curl-library、curl-users 邮件列表）同步公告漏洞与版本；官网 security 页面更新该漏洞条目。

奖金机制与披露策略

• 漏洞赏金由 Internet Bug Bounty 团队管理，报告人应在漏洞被 curl 完全处理并公开发布后，自行向该团队申请奖金。
• 发布后，通过 HackerOne 请求将问题披露（disclose）；报告与讨论中的敏感细节应先做脱敏处理，默认策略是"漏洞一经发布，尽可能多地公开信息"。

私有安全邮件列表

项目还维护一个私有邮件列表（security at curl dot se），仅用于讨论 curl 安全问题。加入没有严格正式流程，基本要求是：在 curl 项目中有长期存在记录、表现出对项目及其工作方式的理解、短期内没有离开计划；参与者名单不公开，因为名单随时间变动，公开只会导致信息过时。

四级严重性分级标准

curl 安全团队使用Low / Medium / High / Critical四级来评估问题严重程度，明确不做数值化评分（如 CVSS 分数）。定级时综合考量：攻击向量、攻击复杂度、所需权限、必要的构建配置、涉及的协议、平台特性，以及漏洞被利用或触发后可能造成的后果（机密性、完整性、可用性问题）。

这套分级对集成方（如 TEN 框架的使用者）有直接指导意义：评估一个上报问题时，不应只看现象本身，而应从攻击向量、配置前提、平台分布、触发难度和后果五个维度综合判断，并对照下文"不算漏洞"清单排除误报。

哪些问题"不算安全漏洞"

SECURITY-PROCESS.md 用一节专门列举了不视为漏洞的典型情形，用于指导报告人与安全团队快速分流。逐条归纳如下：

1. 小规模内存泄漏：偶发、小幅增长的内存泄漏不视为安全问题，因为长生命周期应用和服务本就需处理内存增长（无论是泄漏还是正常增长）；但若泄漏规模很大（存在 DoS 风险）或泄漏的内存含敏感数据，则可能升级为安全问题。
2. 永不结束的传输（never-ending transfers）：传输停滞不结束不视为安全问题，因为已有多种良性原因可导致停滞，应用本应具备应对机制；若该问题能绕过常规应对机制，则另当别论。
3. 现有硬件上无法实际执行的缺陷不算安全问题。
4. API 误用：只有应用以文档未支持甚至明确不支持的方式使用 API 时才触发的问题，通常不视为安全问题——项目只保证 API 按预期且按文档方式使用时安全；当然，对文档含义的解释若有争议，仍可能最终被认定为安全问题。
5. 本地攻击者已存在：只能被已存在于本地系统或网络的攻击者利用的问题，门槛更高——如果本地用户已拥有足以攻击 curl 的越权，他们很可能本就能造成更严重的破坏，问题本质不在 curl。
6. 实验性功能：默认关闭（构建层面）且被文档标记为实验性的功能中的漏洞，不参与赏金，也不视为安全问题。
7. URL 解析不一致：浏览器与 curl 在 URL 解析上的差异是预期行为，不视为漏洞（WHATWG URL 规范与 RFC 3986+ 本身并非完全互通）；明显的解析器 bug 当然仍可能是漏洞。
8. 可见的命令行参数：curl 命令会清空部分命令行参数以防出现在进程列表中，但这是"尽力而为"：并非所有系统都允许清空参数；参数在清空前的一瞬间仍可被读取；几乎所有参数按用途都可能含敏感数据；若清空全部参数，用户将无法在进程列表中区分不同的 curl 命令行。因此遗漏不属于安全漏洞。
9. 忙循环（busy-loops）：消耗 100% CPU 但最终结束（如有超时设置）的忙循环不视为安全问题——应用本应处理传输循环合法占用 100% CPU 的情形；虽然长时间忙循环是恼人的 bug，但不构成安全问题。

这些判定标准对 TEN 框架中调用 libcurl 的扩展（例如 HTTP 请求、文件下载等场景）同样适用：排查问题时先对照清单，可避免把预期行为或文档未支持的用法误报为安全事件。

安全公告（Security Advisory）撰写规范

当漏洞被确认后，团队需要撰写公告文档，详见 third_party/curl/docs/SECURITY-ADVISORY.md。公告文档与报告人合作撰写，确保问题各角度和细节都被正确、简洁地描述。

文件与元数据发布流程

• 公告文件创建在 curl-www 仓库的docs/目录下，按 CVE ID 命名（如CVE-2016-0755.md），使用 Markdown 编写。
• 常规做法是先撰写VULNERABILITY小节，再将这段描述粘贴进 CVE 申请请求。
• 新条目要登记到同目录vuln.pm文件中数组的顶部，该数组保存所有已发布漏洞，字段以竖线|分隔，共11 个字段，按顺序为：HTML 页面名、首个受影响版本、末个受影响版本、问题名称、CVE ID、公告日期（YYYYMMDD）、上报日期（YYYYMMDD）、CWE、奖励金额（USD）、区域（单个单词）、C 语言问题类型（-表示非 C 问题；OVERFLOW、OVERREAD、DOUBLE_FREE、USE_AFTER_FREE、NULL_MISTAKE、UNINIT）。
• 新 CVE 页面文件名需加入 Makefile 的CVELIST宏；Markdown 就位且 Makefile、vuln.pm 更新后，其余文件与所有公告的元数据会自动生成。

公告文档的标准章节格式

新公告最稳妥的做法是拿最近一篇已发布公告，清空旧文本后另存为新文件名，保留小节标题与整体版式——因为部分细节和元数据会从文档中提取，必须严格遵守既有格式。文档按以下固定小节组织：

• VULNERABILITY：首个小节，详细描述缺陷，包括如何触发、触发或利用后可能发生什么。
• INFO：元数据小节，必须给出官方 CVE ID，并在独立一行列出 CWE ID；CWE 标识须带官方全称，例如CWE-305: Authentication Bypass by Primary Weakness。
• AFFECTED VERSIONS：先列出受影响版本，再明确列出不受影响的版本，第三行给出引入该漏洞的具体 git commit。示例格式：

  - Affected versions: curl 7.16.1 to and including 7.88.1 - Not affected versions: curl < 7.16.1 and curl >= 8.0.0 - Introduced-in: (指向引入 commit 的完整 URL)

  Introduced-in应使用展示该 commit 的完整 URL，同时也能作为独立 commit hash 使用（去掉最后一个斜杠之前的部分）。

• THE SOLUTION：描述并讨论修复方案，唯一强制内容是指向修复 commit 的链接，同样使用完整 URL 形式：- Fixed-in: (指向修复 commit 的完整 URL)。
• RECOMMENDATIONS：按优先级从上到下列出给用户的建议动作，理想情况下三条、至少两条；前两条几乎总是"将 curl 升级到 XXX 版本"和"为本地版本应用补丁"。
• TIMELINE：记录项目收到报告的时间、发行方被通知的时间（通过 distros 邮件列表等）、公告与修复版本发布的时间。
• CREDITS：至少提及报告人与补丁作者，再提及你认为值得提到的其他参与者；多人用逗号分隔。格式示例：

  - Reported-by: Full Name - Patched-by: Full Name

对 TEN 框架集成方的影响与建议

回到本仓库的实际场景，curl 以源码形式内嵌于 third_party/curl，与 mbedtls、zlib 等一起参与构建。结合 BUILD.gn 的构建选项与上游安全流程，几点落地建议：

1. 追踪上游修复节奏：仓库内版本为 8.1.2-DEV（curlver.h），应以上游 curl 官方 security 页面发布的高危 CVE 为触发器，及时同步升级源码树；curl 公告的AFFECTED VERSIONS章节就是判断"本仓库内嵌版本是否受影响"的直接依据。
2. 按需裁剪攻击面：本仓库构建时已关闭 LDAP/LDAPS、libssh2、libpsl、libidn2 等（见 third_party/curl/BUILD.gn），并仅启用 mbedTLS 作为 TLS 后端——这本身就是减少"依赖罕见协议/选项"类漏洞面的做法。集成方在自定义构建时应延续"最小化启用特性"原则。
3. 调试构建的保密提醒：构建配置在 debug 模式下会开启ENABLE_DEBUG=ON与ENABLE_CURLDEBUG=ON（BUILD.gn，对应 CMakeLists.txt 中TrackMemory特性）。这些选项服务于开发调试，不应出现在生产发布构建中，以免引入非预期行为与信息暴露。
4. 上报问题先对照"不算漏洞"清单：无论是上游报告还是内部排查，先比对 SECURITY-PROCESS.md 中的九类豁免情形（内存泄漏、API 误用、忙循环、URL 解析差异等），再决定是否按安全流程处理，可显著减少误报与无效沟通。
5. 若自建安全响应流程，可直接参照本文第二节的完整时间线（HackerOne 上报→人工确认→调查裁决→私有分支修复→提前通知发行方→发布前合入→正式公告），以及第四、五节的分级与公告模板，两者均为可直接复用的开源安全治理范本。

小结

curl 的安全流程是一套闭环、可复制的开源项目安全治理方案：以 HackerOne 为唯一上报入口、以私有分支和延迟披露保证修复期保密、以四级严重性分级统一口径、以明确的"豁免清单"控制误报率、以固定格式的公告文档保证信息可机器提取与长期归档。对于把 libcurl 作为网络组件的 TEN 框架及其使用者而言，理解这套流程并跟踪仓库内嵌 curl 版本的漏洞公告，是保障语音 AI 应用网络层安全的基础功课。

• 人工智能
• AI Agent
• 多模态
• 语音
• AI 应用