漏洞公告分析工作坊
这是第一周第二次课，把第一讲的概念转化为可执行流程。学生需要从公告走到 issue、测试、修复计划和披露沟通。
学习目标
- 独立拆解一篇漏洞公告，识别事实、推断和未知项。
- 把根因转化为一个可复现的最小测试用例。
- 把安全风险转化为工程 issue、优先级和修复验收标准。
- 写出一段面向用户和维护者都能理解的安全说明。
先备知识
- 第一讲的四个概念：bug、vulnerability、exploit、risk。
- 能阅读 GitHub issue 或安全公告。
- 能写出简单测试用例描述。
课前准备
- 完成第一次课作业草稿：任选一篇 CVE 公告并做一页分析。
- 带来一个你不确定如何判断严重性的点。
- 阅读课程仓库中的两个示例公告：一个输入验证漏洞，一个依赖漏洞。
课堂流程
0-10复习：四词和五问用冷启动小测复习 bug、vulnerability、exploit、risk，以及谁能触发、入口点、信任边界、资产、回归测试五问。
review
用冷启动小测复习 bug、vulnerability、exploit、risk，以及谁能触发、入口点、信任边界、资产、回归测试五问。
事实、推断和未知项为什么要分开写？
预期回答：因为安全响应需要可审计证据。事实支撑行动，推断需要置信度，未知项决定下一步调查。
追问：如果你把推断写成事实，会对修复优先级和披露造成什么影响？
开场复习
上节课我们建立了四个词：bug、vulnerability、exploit、risk。今天我们不再停留在定义，而是做一件安全工程师每天都会做的事：读公告，然后把公告转成行动。注意，行动不是‘知道了’，行动是 issue、测试、补丁、发布和监控。
公告分析模板
把公告复制到模板。
事实、推断和未知项
10-22教师示范：公告到证据表教师把一篇短公告拆成事实、推断和未知项三列，示范不要把猜测写成事实。
modeling
教师把一篇短公告拆成事实、推断和未知项三列，示范不要把猜测写成事实。
事实、推断和未知项为什么要分开写？
预期回答：因为安全响应需要可审计证据。事实支撑行动，推断需要置信度，未知项决定下一步调查。
追问：如果你把推断写成事实，会对修复优先级和披露造成什么影响？
示范
我先示范如何读。第一遍只标事实：公告明确说了哪些版本受影响，明确说了什么入口点，明确说了修复版本。第二遍才写推断：如果它影响上传接口，我们推断头像上传也可能受影响，但这不是事实。第三栏写未知项：是否暴露在公网？是否启用了相关功能？是否有 WAF 或其他控制？
公告分析模板
以小组为单位提交一个安全 issue：标题、影响、攻击前提、复现步骤、验收标准、回归测试。
事实、推断和未知项
22-38小组分析 1：输入验证漏洞学生小组填写模板：受影响版本、攻击前提、根因、影响、测试、修复验收标准。
group-work
学生小组填写模板：受影响版本、攻击前提、根因、影响、测试、修复验收标准。
升级依赖总是最好的修复吗？
预期回答：不总是。升级可能带来兼容性风险，但长期通常需要升级；短期可能需要配置缓解、禁用入口点或隔离暴露面。
追问：如果升级会破坏生产系统，你如何设计临时缓解和验收时间线？
小组任务说明
现在每组拿到一个输入验证漏洞。你们的目标不是复述公告，而是把它变成工程任务。请写出一个 issue，里面必须有攻击前提、影响、复现步骤、验收标准和回归测试。十六分钟后我们比较两个组的结果。
公告分析模板
把公告复制到模板。
事实、推断和未知项
38-50全班评审：严重性和优先级比较两个小组的优先级判断，强调环境暴露、资产价值和可利用性会改变排序。
review
比较两个小组的优先级判断，强调环境暴露、资产价值和可利用性会改变排序。
升级依赖总是最好的修复吗？
预期回答：不总是。升级可能带来兼容性风险，但长期通常需要升级；短期可能需要配置缓解、禁用入口点或隔离暴露面。
追问：如果升级会破坏生产系统，你如何设计临时缓解和验收时间线？
评审
我们看两个组的优先级判断。一个组给 P0，一个组给 P2。谁对？这取决于环境。安全优先级不是公告分数的机械复制。公网暴露、认证要求、资产价值、是否有现有控制，都会改变排序。你们以后做安全响应，必须把环境写进判断里。
公告分析模板
以小组为单位提交一个安全 issue：标题、影响、攻击前提、复现步骤、验收标准、回归测试。
把公告转成安全 issue
50-65小组分析 2：依赖漏洞切换到依赖漏洞，要求学生判断升级、缓解、锁版本和 SBOM 更新如何进入修复计划。
group-work
切换到依赖漏洞，要求学生判断升级、缓解、锁版本和 SBOM 更新如何进入修复计划。
回归测试应该证明漏洞已经不存在，还是证明 exploit 失效？
预期回答：最好覆盖根因，而不是只覆盖一个 exploit 样本。只证明一个 exploit 失效可能漏掉同类变体。
追问：如果根因还不清楚，第一版测试该怎么写？
总结
今天的闭环是 triage、reproduce、patch、test、release、monitor。只完成其中一步，都不算完整安全工程。下节课我们进入内存安全，会看到一个看似普通的边界错误，如何沿着机器模型变成控制流风险。
公告分析模板
把公告复制到模板。
把公告转成安全 issue
65-76安全说明写作每组写三段话：给用户的影响说明、给维护者的技术说明、给管理者的风险说明。
writing
每组写三段话：给用户的影响说明、给维护者的技术说明、给管理者的风险说明。
回归测试应该证明漏洞已经不存在，还是证明 exploit 失效？
预期回答：最好覆盖根因，而不是只覆盖一个 exploit 样本。只证明一个 exploit 失效可能漏掉同类变体。
追问：如果根因还不清楚，第一版测试该怎么写？
总结
今天的闭环是 triage、reproduce、patch、test、release、monitor。只完成其中一步，都不算完整安全工程。下节课我们进入内存安全，会看到一个看似普通的边界错误，如何沿着机器模型变成控制流风险。
公告分析模板
以小组为单位提交一个安全 issue：标题、影响、攻击前提、复现步骤、验收标准、回归测试。
把公告转成安全 issue
76-85把公告转成工程流程教师总结一个完整闭环：triage -> reproduce -> patch -> test -> release -> monitor。
synthesis
教师总结一个完整闭环：triage -> reproduce -> patch -> test -> release -> monitor。
回归测试应该证明漏洞已经不存在，还是证明 exploit 失效？
预期回答：最好覆盖根因，而不是只覆盖一个 exploit 样本。只证明一个 exploit 失效可能漏掉同类变体。
追问：如果根因还不清楚，第一版测试该怎么写？
总结
今天的闭环是 triage、reproduce、patch、test、release、monitor。只完成其中一步，都不算完整安全工程。下节课我们进入内存安全，会看到一个看似普通的边界错误，如何沿着机器模型变成控制流风险。
公告分析模板
把公告复制到模板。
安全响应闭环
85-90总结和下节课钩子总结公告分析模板。下节课进入内存安全，观察一个具体 bug 如何变成控制流风险。
summary
总结公告分析模板。下节课进入内存安全，观察一个具体 bug 如何变成控制流风险。
回归测试应该证明漏洞已经不存在，还是证明 exploit 失效？
预期回答：最好覆盖根因，而不是只覆盖一个 exploit 样本。只证明一个 exploit 失效可能漏掉同类变体。
追问：如果根因还不清楚，第一版测试该怎么写？
总结
今天的闭环是 triage、reproduce、patch、test、release、monitor。只完成其中一步，都不算完整安全工程。下节课我们进入内存安全，会看到一个看似普通的边界错误，如何沿着机器模型变成控制流风险。
公告分析模板
以小组为单位提交一个安全 issue：标题、影响、攻击前提、复现步骤、验收标准、回归测试。
安全响应闭环
课后作业
把自己的 CVE 分析扩展成一个工程 issue 和一个回归测试设计，下次课前提交。