《漏洞披露机制搭建方案》
第3章 制定披露政策（上）
3. 制定披露政策（上）：政策目标、适用范围、漏洞定义与分类标准
漏洞披露政策是安全响应体系的“宪法”。本节将深入剖析政策制定的三大基石：明确政策目标、界定适用范围、统一漏洞定义与分类标准。一个清晰、可执行的政策能够有效降低沟通成本，规避法律风险，并建立与安全研究社区的信任桥梁。
3.1 政策目标：为什么需要一份披露政策？
一份优秀的漏洞披露政策（VDP）不仅仅是技术文档，更是组织安全文化的体现。其核心目标可归纳为以下四点：
- 降低风险暴露面：通过建立官方渠道，确保漏洞在第一时间被内部安全团队知晓，而非在黑市或公开论坛中传播。
- 建立正向激励机制：明确告知研究人员“哪些行为是被鼓励的”，从而引导其进行负责任的披露，而非恶意利用。
- 提升响应效率：通过标准化的提交流程和分类标准，减少安全团队与报告者之间的沟通摩擦，加速漏洞修复周期。
- 满足合规与监管要求：许多行业标准（如PCI DSS、ISO 27001）及国家法规（如《网络产品安全漏洞管理规定》）均要求建立漏洞接收与处置机制。
3.2 适用范围：政策覆盖的边界在哪里？
明确适用范围是避免争议的关键。政策必须清晰界定“谁”可以参与、“什么”可以测试以及“哪里”可以测试。
| 维度 | 详细说明 | 示例 / 注意事项 |
|---|---|---|
| 适用对象 | 所有外部安全研究人员、白帽黑客、客户及公众。 | 通常排除内部员工（另有内部流程）。需明确是否接受匿名提交。 |
| 适用资产 | 明确列出允许测试的域名、IP范围、应用及API。 | 例如：*.example.com，排除 critical.example.com（生产核心库）。 |
| 适用行为 | 授权测试方法：仅限使用非破坏性技术，禁止社会工程、DDoS、物理入侵等。 | 明确禁止：暴力破解用户密码、大规模扫描、数据下载（PoC除外）。 |
| 不适用范围 | 明确列出“不接收”的漏洞类型或测试范围。 | 例如：自评分XSS、TLS配置问题、内容欺骗等低危问题。 |
3.3 漏洞定义与分类标准：统一语言，减少歧义
为了确保报告者和审核团队对漏洞严重性有一致的理解，必须采用业界公认的分类标准。推荐使用 CVSS v3.1（通用漏洞评分系统） 作为基础评分框架，并结合 CWE（通用弱点枚举） 进行类型归类。
3.3.1 漏洞严重性分级（基于CVSS v3.1）
| 等级 | CVSS 分数范围 | 颜色标识 | 响应SLA（目标） | 典型示例 |
|---|---|---|---|---|
| 严重 (Critical) | 9.0 - 10.0 | 红 | 24小时内确认，7天内修复 | 远程代码执行（RCE）、SQL注入导致数据泄露 |
| 高危 (High) | 7.0 - 8.9 | 橙 | 48小时内确认，14天内修复 | 越权访问（IDOR）、存储型XSS |
| 中危 (Medium) | 4.0 - 6.9 | 黄 | 5个工作日内确认，30天内修复 | 反射型XSS、CSRF、信息泄露（非敏感） |
| 低危 (Low) | 0.1 - 3.9 | 绿 | 10个工作日内确认，90天内修复 | 点击劫持（UI Redress）、TLS配置问题 |
3.3.2 常见漏洞分类（CWE映射）
以下是在Web应用和API中最为常见的漏洞类型，建议在政策中明确列出，并附上CWE编号以便统一检索：
- 注入类 (Injection): CWE-77 (命令注入), CWE-89 (SQL注入), CWE-79 (XSS)
- 认证与会话管理: CWE-287 (认证绕过), CWE-384 (会话固定)
- 访问控制: CWE-285 (权限过大), CWE-862 (缺少授权), CWE-918 (SSRF)
- 敏感数据泄露: CWE-200 (信息泄露), CWE-312 (明文存储敏感数据)
- 安全配置错误: CWE-16 (配置), CWE-209 (错误信息泄露)
3.4 政策制定最佳实践清单
在起草政策时，请务必检查以下要点：
✅ 使用清晰、无法律术语的平实语言，确保非安全背景的研究人员也能理解。
✅ 明确承诺“善意研究”不会面临法律诉讼（Safe Harbor条款）。
✅ 提供具体的测试环境（如Staging/Dev环境），避免影响生产业务。
✅ 定义漏洞报告的“有效载荷”要求：例如，PoC需包含复现步骤、影响描述及建议修复方案。
✅ 定期（至少每年一次）审查并更新政策，以适应业务变化和新出现的威胁类型。