浅蓝工作台上的小提琴琴桥、琴弦与备用零件;AI生成概念插画,表现局部修补与保留整体用途。

DAILY AI INTELLIGENCE

最新日报 历史日历 ↗

2026-10-22 · AI 日报

AI 找到漏洞之后,修复怎样落地

6 条精选1 份学习材料资料截至 2026-10-22 08:02(北京时间)

EDITOR’S NOTE

本期导读

让 AI 找漏洞、写补丁,已经能产生具体成果;但网站恢复正常、旧功能仍然可用,还要经过许多人的判断。本期从 PHP 的修复复盘切入:一类风险早在两年前出现迹象,修复却因兼容性取舍、人员和决策机制数次停滞。新利用路径提高了紧迫性,组织怎样接住这些发现同样决定了结果。

编辑观察沿着“发现、举证、选定修复、恢复服务”展开。先读 PHP 基金会怎样解释困难,再看 Trail of Bits 如何让补丁在旧版、新版和撤销后反复验证。“回归”指改动破坏了原本正确且受支持的行为;误报更少值得重视,也要看真实回归是否仍被确认。

工具与人的接口是另一组阅读线索。HarnessAdapt-RL 让模型训练与工具调整交替进行;同一台 4B 小模型的使用记录则展示了空白字符、计数和保存位置怎样造成失败。Dan McAteer 的监督插件曾帮他注意到未提交工作,也让他遇到提醒过多而开始略读的问题。它们各自提供了改善具体步骤的办法。

最后转向生物研究:分布式 Agent 把基因扰动数据和文献组织成可追问的图谱。值得期待的是探索更多线索的能力,而线索进入实验后的价值仍需继续观察。可先按问题选读正文,再用学习卡练习把一次代码修复写成可复查的证据。

组合筛选

METHODS & SYSTEMS

技术进展

04
值得读AI 编程 / 评测与基准
追踪记录 ↗

PHP 修复复盘:发现漏洞之后,还要解决兼容性与决策

技术Vulnerability ResearchRegression TestingMemory Safety
可信度
65
重要性
90
新颖度
80

PHP 是大量网站运行服务器端程序所依赖的语言环境。10 月 21 日,项目发布四个受支持分支的安全更新,修复两类可能导致远程代码执行的内存问题:一种与内存耗尽时留下未完成初始化的数据有关,另一种与错误退出后残留的跨请求状态有关。实际可利用路径取决于运行方式与应用;“PHP 覆盖大量网站”不等于这些网站都已遭到攻击。

基金会的复盘把时间线往前推到了 2024 年:外部审计后的修复工作已经暴露第一类问题的迹象,但当时没有具体利用路径。候选修复各有代价,有的破坏兼容性,有的引入新的拒绝服务风险,有的需要大量扩展同步修改。熟悉引擎的人少,团队又依赖共识决策,修复数次停滞。2026 年 8 月起,Calif、OpenAI、Wiz 等报告把影响变得具体,修复才获得最高优先级。

这份材料的价值是解释 AI 发现能力怎样进入真实维护流程。团队用 AI 辅助验证和聚合同根因报告,但每次判断与补丁仍有人负责;基金会同时增加专职人员并改变决策方式。它承认此前延误是资源与流程共同造成的结构性失败。这里的新进展包括更快找出问题,也包括让难以取舍的修复有人及时决定。

PHP Foundation · 原帖 / 原文

语境:维护方对修复过程及资源配置的公开复盘。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

基金会没有把延误归结为缺少扫描工具。几种方案会分别影响兼容性、拒绝服务风险或扩展生态,依赖共识的小团队迟迟难以选择。它承认这是结构性失败,并说明正在改变决策流程,让困难取舍更早进入领导层协调。

cookmeplox · 原帖 / 原文

语境:Weird Gloop 运营者在此次预防性停机后发表的个人立场;并非全网统计。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他先解释停机 13 小时以及缓存维持大部分访问的结果,再感谢打包维护者和协助沟通的安全团队。他担心人员很少的公共网站难以持续承受抓取、低质量工具与核心软件漏洞带来的负担,有些此次下线的网站可能不再恢复。对未来的担忧是他的判断,文章没有提供全网停站调查。

编辑评读

这次应当更新的判断,是“更多高质量漏洞报告自然会换来更安全的软件”。报告只解决了是否存在问题的一部分;维护者还要判断哪些旧行为必须保留、哪些兼容性损失可以接受,以及谁有权作决定。PHP 已经知道风险迹象却长期无法选定修复路径,说明补充证据与改变决策条件可以同样关键。

这也给 AI 工程提出了更具体的产品机会:把同根因报告归并,给每种修复呈现影响范围与可复现证据,帮助维护者比较方案。它比单纯提高报告吞吐更接近交付。但不能从这一事件推断 AI 只会增加负担;独立团队提供了更明确的攻击路径,确实推动了优先级变化。

外部运营者 Weird Gloop 报告主动关闭动态服务 13 小时,靠缓存仍服务约 94% 的页面访问。这是一个站点的缓解经验,也说明补丁到达前的运营成本有时比研究公告更早显现。缓存保住访问量,并不代表动态功能都正常;下一步衡量改进,应把修复等待、升级和恢复服务的工作一起算进去。

依据 1 · 依据 2 · 依据 3

值得读Agent 系统 / AI 编程 / 评测与基准
追踪记录 ↗

Trail of Bits 把“修好了”拆成可重放的证据

技术Regression TestingProof of ConceptAgent Tools
可信度
65
重要性
88
新颖度
84

Trail of Bits 发布 patching-bugs 与 regression-hunt,分别帮助开发补丁和寻找补丁造成的新缺陷。“回归”在这里有严格含义:原来正确且受支持的行为,被这次改动破坏,而且真实用户或攻击者能够触达那条路径。旧缺陷、修复不完整和不受支持的用法,不能都算成新回归。

修补流程先复现报告,再围绕被破坏的安全约束修改代码,并采用三组验证:旧代码失败、补丁后通过、完全撤销补丁后再次失败。这样能更有力地区分“补丁确实修好”与环境或测试恰好变化。回归检查则从改动追到调用方和实际入口,在实际运行环境中复现前后差别,换一个新上下文的 Agent 重放,再由裁定步骤检查证据是否符合定义。每一步传递代码版本、原始证据和未解问题。

作者复查自己参与且已合入的 130 多个 PR,确认 21 个回归,涉及功能、性能、构建或测试。在这些已知案例上的初步比较中,regression-hunt 比仅提示基础 Agent 审查回归少产生 25% 的误报,报告的 95% 置信区间为 14%–38%。严格举证也使部分真实回归停留在证据不足状态;这个结果不能读成整体检出能力提高 25%。

回归候选经过前后版本复现、新上下文重放与裁定后才成为报告。图中的独立重放是流程分离,不保证模型错误统计独立。Trail of Bits · 原文方法图,有限引用用于解释本文讨论的方法 · 原文图表 · 图片出处 ↗

Dan Guido(dguido) · 原帖 / 原文

语境:在本文 HN 讨论中解释工具定位;Trail of Bits 负责人,与项目有关联。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他认为漏洞到利用之间的成本正在降低,产品负责人需要提高收到报告后的修补速度。他甚至判断协调披露的作用正在缩小,建议采用团队的修补与回归检查工具。回应质疑时,他同意快速打补丁不能替代减少攻击面;即使设计更安全的软件,也需要响应新发现。

marcosdumay · 原帖 / 原文

语境:回应 Dan Guido 对修补速度的强调;属于原则性反驳,不是插件实测。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他反对把发现一个漏洞就修一个的做法,当作把脆弱软件变安全的充分方法。漏洞发现得更快,并没有改变这个问题。

编辑评读

最值得借用的是把“再检查一次”改成可以交换和重放的证据。新的 Agent 仍可能和前一个犯相同错误,但它面对的是具体版本、入口和运行记录,能够重新判断主张,而不是只读上一位的总结。三组验证还增加了撤销操作:若撤销以后错误没有回来,就需要重新检查所谓修复的因果解释。

这套方法与单纯增加审查意见数量有不同目标。原复查从 58 个候选中确认 21 个回归,说明工程师必须花时间处理大量未成立的发现;减少误报有真实价值。但这批案例来自团队已合入的安全补丁,且工具把部分真问题留为边界案例,不能据此保证任何仓库都获得同样净收益。

对维护团队而言,可迁移的做法是先写清受支持行为与安全边界,再要求重要结论附能复查的变化证据。验收对象仍是完整补丁:修好原问题、没有损害需要保留的行为、剩余疑点可以被人接手。这些检查是对速度的支持条件,不能靠一个“已完成”状态替代。

依据 1

值得读Agent 系统 / AI 编程 / 评测与基准 / 训练与对齐
追踪记录 ↗

HarnessAdapt-RL:训练会改模型,也要重调工具

技术GRPOHarness OptimizationAgent ToolsTraining-time Skills
可信度
65
重要性
82
新颖度
86

编程 Agent 由模型与运行框架共同完成任务:模型决定动作,框架负责执行工具、返回结果和提示运行状态。HarnessAdapt-RL 研究的是两部分一起变化时怎样训练,而不是给固定模型再写一套提示词。它从修复轨迹中区分两类问题:诊断或修复思路不对,以及编辑失败、输出太多、验证不足等跨任务反复出现的交互问题。

前一类交给冻结的教师模型,生成解释何时、为何采用某种修复策略的临时技能;后一类由另一教师提出工具与运行钩子的改动。候选框架与当前框架使用相同模型、任务、技能和采样预算比较,只有通过率或可用于训练的轨迹比例至少一项增加、另一项不下降才保留。随后用新采样轨迹进行 GRPO 强化学习,再根据更新后的模型重新改框架。

论文以 Qwen3.5-9B 和 mini-swe-agent 为基础。在三个 SWE-bench 修复基准上,完整系统的平均单次成功率为 44.9%,GRPO 基线为 35.3%;基线拥有两倍策略训练采样,但完整方法另有教师调用与框架搜索开销。评测时移除临时技能和教师,保留最终工具与钩子。固定训练权重再拿掉这些工具,最多损失 7.7 个百分点。每套配置只训练一次,三次重复指评测,不能说成三次独立训练复现。

训练循环先提出技能与工具改动,比较候选框架后再用新轨迹训练;部署时保留模型和工具框架,移除临时技能与教师调用。Lingxiao Tang、Wei Tao、Yiwen Guo、Lingfeng Bao · 原文方法图,有限引用用于解释本文讨论的方法 · 原文图表 · 图片出处 ↗

编辑评读

这项工作的贡献,是把部署资产的边界说得更清楚。技能内容在训练后可以撤掉,相关收益仍留下;部分工具支持却需要随模型一起交付。因此,比较两个模型权重并不能复现表中的完整 Agent 排名,换一个常用运行器也可能改变结果。对开源模型使用者来说,工具与钩子的版本应和模型版本一起记录。

一个具体例子比“框架会进化”更有解释力:后期轨迹显示模型减少了验证,即使已有测试工具和提醒。作者于是让准备补丁的工具自动挑选相关测试,并把失败情况反馈给模型。这把部分操作落实进程序,而没有假定更长的提醒总会有效;自动选择仍只提供部分验证,准备补丁成功也不等于测试通过。

同条件候选比较有助控制模型变化,但“观察到一项提高、另一项不降”的接受规则并不是显著性检验。作者明确承认有限采样和重复搜索会影响入选。可以借用这种交替调整的方法,但若要判断总训练成本是否划算,还需把教师、比较采样与独立训练波动纳入共同预算;本期没有运行该实验。

依据 1 · 依据 2

值得读Agent 系统 / 评测与基准 / 检索与知识
追踪记录 ↗

分布式生物推理:把扰动数据变成可追问的线索

技术Multi-AgentLiterature RetrievalPerturb-seq
可信度
65
重要性
80
新颖度
80

基因扰动实验通过干预基因活动,观察细胞发生哪些变化;大规模实验会产生很多结果,解释每个变化又需要联系细胞类型和散落的文献。OpenAI、PerturbAI 与 Scripps Research 把小鼠脑 CRISPR 图谱中的扰动分给多个 Agent:分别分析细胞反应、查文献、提出解释,再把报告组织成连接基因、现象和潜在机制的推理图谱。这里的产物是研究线索,不是完成临床验证的治疗方案。

官方报告称,系统在 32 分钟内完成这批分析;在模型与资源固定的对照中,最大规模设置的引用从单 Agent 的 11 篇增加到 700 多篇,专家盲评有 75% 的比较更偏好分布式报告。引用增加和报告偏好分别衡量覆盖与评读结果,还没有测出后续实验成功率。一个例子是 Dctn1 扰动后与胆固醇合成相关的表达变化:系统把它连到运输异常的研究,提出应进一步检验细胞内分布,而没有把这种联系直接当作病因证明。

公开仓库让研究者沿 Findings、Claims 和证据查找报告,也区分托管查询与本地重算:在线入口没有原始数据,不能替代需要原始数据的统计操作。对想使用这类图谱的人,这个区别决定了它适合做阅读入口还是分析工具。论文全文本次未取得,详细比较口径仍以已读公告与仓库范围为限。

jostmey · 原帖 / 原文

语境:在这项生物研究公告的 HN 讨论中质疑线索生成的价值;未报告该系统实验。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他认为一直困难的是得到验证结果,尤其是证明有效性的临床试验;他反而期待 AI 帮助科学家处理研究复杂性和监管负担。

Tadpole9181 · 原帖 / 原文

语境:回应把生物进展与数学结果直接比较的评论;是研究过程层面的辩护。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他反问,是否有人真的期待 AI 第一次做生物研究就不再需要物理验证。即使提出可能的治疗方案,也需要患者、实验设施与相应批准。生物学的反馈更慢、更贵,AI 必须参与通常的协作研究过程。

编辑评读

这里值得关注的能力,是为原本难以逐项读完的数据提供一组带出处的解释入口。把任务拆到单个扰动,可以减少一个 Agent 在巨大工作清单中忽略文献的机会;报告又能聚合查询,让领域专家选择值得深挖的关系。这是扩大分析覆盖的工具价值。

争议集中在“线索多了是否有用”。HN 评论者 jostmey 强调验证和临床研究才是瓶颈;Tadpole9181 则提醒,生物研究本来需要物理实验与协作,不能要求第一次分析就跳过它们。这两点可以同时成立,但都没有直接测出本系统的后续实验收益。

因此,当前应改变的选择是可以尝试用图谱组织补读和挑选实验,而不宜据报告偏好率推断疗效。一个有辨别力的后续检查,是让专家在相同实验预算下分别使用原数据入口与推理图谱,比较最终选中的问题是否更可检验、更能排除解释;这是编辑提出的验证方向,并非团队已经完成的实验。

依据 1 · 依据 2 · 依据 3 · 依据 4

VOICES & EXPERIENCE

观点与经验

02
值得读Agent 系统 / AI 编程 / 评测与基准
追踪记录 ↗

同一台 4B 模型的 50 次运行:失败常在编辑接口

技术Tool CallingCode EditingLocal Inference
可信度
65
重要性
76
新颖度
76

Reddit 用户 GapNew4766 用同一个本地 Qwen3.5-4B 量化模型,测试十种 Agent 运行框架。每种框架执行五个小任务,每题一次;使用 M5 MacBook Pro(32GB 内存)、Q4_K_M 量化和 llama-server,64K 上下文设置固定,任务文件每次重置,由脚本判通过与否。因此“50 次”是十乘五的组合,既不是五十个独立任务,也不足以给框架排稳定榜单。

作者最意外的是,日志里没有找到畸形工具调用,失败却出现在工具语义与工作细节:跨三文件改函数名时,旧文本漏了一个空行,精确替换失败,模型原样重试五遍;另一次修补只照顾可见测试,隐藏字符串仍处理错误;日志计数把 43 行数成 40 行。还有答案写对但放错目录的情况。

评论者 porkminer 说自己改用按函数名与新定义替换的工具,减少逐字复述旧文本的要求;作者随即追问重名和重载,评论者承认尚未遇到,必要时应加文件或作用域信息。enternoescape 则提醒,读文件工具附加的行号有时也会干扰替换。这些意见给出了可检查的接口原因,并没有证明所有精确替换失败都来自模型能力不足。

u/GapNew4766 · 原帖 / 原文

语境:原帖作者在固定本地模型与机器上的探索性比较。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他原先预期小模型主要会生成坏掉的工具调用,查日志后却没有找到这种失败。最让他困扰的是模型知道该改什么,却没能逐字重现旧文本;失败后还重复同一个编辑。速度差距很大,他猜测与提示词大小及多余步骤有关,但明确说尚未测量原因。没有破坏性命令也不能说明安全:这些任务本来就没有诱导危险操作。

u/porkminer · 原帖 / 原文

语境:原帖评论区回应精确匹配失败;后续回复承认尚未遇到重名边界。 · 读取时间:2026-10-22T00:12:52.284404+00:00

回应原帖:u/GapNew4766

逐句忠实转述(非原文)

他在自己的测试里主要遇到精确匹配问题,于是让模型只发送函数名和新定义,由工具定位并替换。他还不开放任意命令行,把需要的操作包成工具。面对重载和不同文件中同名函数的追问,他说自己还没遇到,但应加入作用域或文件信息,必要时考虑语法树索引。

u/enternoescape · 原帖 / 原文

语境:同一评论区补充另一种可能的接口原因;未提供统一对照。 · 读取时间:2026-10-22T00:12:52.284404+00:00

回应原帖:u/GapNew4766

逐句忠实转述(非原文)

他指出读工具加上的行号有时会导致匹配问题;在他的经历中,能使用 shell 工具时有时第一次就成功。他也见过前沿模型编辑成功却漏掉细节、仍需再改,所以不把这类问题只归给小模型。

编辑评读

这份小样本的价值在于诊断,而非名次。工具调用能被解析,只表示指令格式正确;编辑器还要求目标文本存在,任务还要求修改满足隐藏条件。把这几个层次分开,能避免一遇到失败就换更大模型,也能避免工具返回成功后就提前宣布任务完成。

按函数替换降低了模型必须准确复制空白字符的负担,但把工作移到了定位器:它必须找对文件、作用域与目标定义。作者对重名的追问很重要,因为一个更“宽容”的编辑接口也可能更安静地改错位置。较好的比较应记录匹配失败、错误替换和最终任务通过,而不仅是编辑操作成功次数。

这与 HarnessAdapt-RL 的工具演化构成机制上的对照:前者是个人观察,后者有训练与消融,不能互称独立复现。共同可借用的是沿失败轨迹定位哪一步需要可靠程序。计数可以交给确定性工具,保存位置可以显式指定,是否实现完整需求仍要用适当测试判断。

依据 1 · 依据 2 · 依据 3

值得读Agent 系统 / AI 编程
追踪记录 ↗

Dan McAteer:监督界面要帮人注意,也可能让人略过

技术Agent HooksHuman-in-the-LoopContext Management
可信度
65
重要性
75
新颖度
77

Dan McAteer 的实践文章讨论 Claude Mods:在 Claude Code 内运行的 JavaScript 或 TypeScript 插件,可以响应提示、工具调用或界面渲染,改变工作过程里展示给人的信息。他把这类面向操作者的层称为“注意力界面”,关注什么时候打断人、展示什么,以及让人作哪个决定。

一项内置提示曾指出,他正在改动的文件已经含有未提交工作;如果后来丢弃演示改动,可能连原先的工作一起丢掉。作者自建的 Next Steps Supervisor 则在修改文件、执行命令或至少八次工具调用的回合后运行,列出缺口并给出可点击的下一步。这些例子说明,监督可以做成可操作的入口,而不只是最后的一段总结。

但他记录的 111 个回合中有 99 个达到触发条件,部分提醒开始被他略读;一次状态显示已解决,同时又列出两处缺口和三项捷径。他还指出监督检查会重新读取上下文并产生费用。文章最有价值的取舍,是可定制性使人能够修正提醒策略,也把判断什么值得提醒的责任留给使用者。

Dan McAteer · 原帖 / 原文

语境:作者介绍自己的 ModSmith 插件与实际使用记录,与所推荐工具有开发关系。 · 读取时间:2026-10-22T00:12:52.284404+00:00

逐句忠实转述(非原文)

他最初看重的是可以亲手决定 Agent 怎样与自己协作:提醒什么,什么时候询问,让下一步直接可执行。真正使用后,他发现频繁提醒容易变成噪声,每次监督又增加上下文读取费用。他的判断标准是有没有发现原本会漏掉的事、让决定更容易、让行动更少分心;否则再漂亮的界面也只是装饰。他设想以后从会话摩擦中主动建议插件,但那是未来方向。

编辑评读

作者的成功例子有明确目标:让人看见原本可能漏掉的未提交工作。高频触发却把同一界面推向相反结果:若几乎每轮都需要读一段裁定,人很容易把它变成背景噪声。衡量监督价值,因而应看它改变了哪些决定,以及遗漏的重要事项有没有减少。

这比再加一个“完成度”标签更接近实际需求。一个状态同时说已解决又列缺口,使用者仍需自行解释哪些是阻断项、哪些只是建议。如果把提示连到可查看的差异、具体证据和下一步操作,就可能缩短这段解释工作;如果只是生成更多评语,则会增加审阅负担。

可以从单一摩擦开始试用:只对会覆盖既有工作、缺少关键验证等已明确的情形提示,并保留用户实际处理记录。作者的统计不是受控用户研究,不能据此选出普适触发阈值;但它给了一个可复查的产品问题——提醒频率、有效行动与忽略行为,应当放在同一份使用记录中。

依据 1

LEARN BY DOING

技能学习

每天 1–2 份实践材料

博客 · 项目实践 · Trail of Bits

给一次修复补齐前后版本证据

技术Regression TestingProof of Concept

学习怎样定义受支持行为、复现原问题,并在撤销补丁后确认错误是否回来。

适合能构建并运行测试的开发者;选自己有权修改的练习项目。 · 编辑建议:阅读约20分钟,再用30—45分钟检查一个小修复。

动手试试:选择一个已有本地单元测试的小错误,记录旧版失败、新版通过、撤销后失败;再加入一条旧成功测试。此练习是编辑建议,本期未执行。

CONNECT THE DOTS

把几件事放在一起看

编辑观察
追踪记录 ↗01

漏洞更快出现,修复能力要沿着交付过程增长

当 AI 更快地报告漏洞、提出补丁,团队最直观的选择是加速审查。但审查队列只呈现了困难的一部分:有人需要把相似报告归为同一根因,有人需要比较兼容性与安全取舍,有人需要把修复送到下游并恢复服务。PHP 的公开复盘让这条链条变得具体——风险迹象很早已经出现,真正卡住的是几种修复方案各有代价,而熟悉引擎且能够作决定的人手有限。[1]

此前本刊沿着代码审查讨论过:少一轮审查,可能减少返工,也可能把工作留给以后;因此不能只看评论量或轮数。这次新增的认识是,即使问题已经被认定为真实,团队仍可能因为无法选定可接受的修复而停滞。PHP 后来的进展既来自研究者给出明确利用路径,也来自专职人员投入、优先级提升和决策机制调整。把延误简单归为“模型还不够强”或“人类总是瓶颈”,都会漏掉可以改变的条件。[1]

Trail of Bits 提供了对其中一段工作的具体改进。它让修复证据经过旧版失败、新版成功和撤销后再次失败,再用真实入口检查旧行为是否被破坏。重要的不只是多了一位检查者,而是后一个步骤可以重新运行前一个步骤的主张。版本与证据的交接有机会减少重新理解问题的成本;同时,严格举证留下的边界案例也必须交给人,不能当成问题已经消失。[2]

Dan McAteer 的监督界面从人的一端补充了这个判断。提醒曾帮助他发现未提交工作,也因为几乎每轮触发而开始被略读。增加检查次数不自动增加注意力;如果输出无法区分必须处理的缺口与普通建议,人就又要承担一轮解释。这里可以借用补丁流程的做法:重要提醒直接指向证据和可执行的下一步,而不是只生成一个完成标签。[3]

外部站点的经历则提醒我们把交付终点放远一点。Weird Gloop 预防性停机期间用缓存保住大部分访问,但动态服务仍有中断;维护者担心人员很少的公共网站承受不了持续的紧急应对。这一经历不能代表所有网站,却表明发现方节省的时间与运营方付出的工作可能发生在不同组织,不能只在单个团队的账上评价整条流程。[4]

我的判断是,值得扩大的能力包括发现新问题,也包括把证据、决定与修复交给下一位参与者。下一次比较不妨追踪同一批报告从成立、选定方案、发布到恢复服务的等待和返工,再看哪些自动化真正缩短了交付。这个建议尚未验证;本期材料已经足以说明,报告数、补丁数与误报下降都只是其中一段,不能各自替代最终结果。

相关条目:PHP 修复复盘:发现漏洞之后,还要解决兼容性与决策 / Trail of Bits 把“修好了”拆成可重放的证据 / Dan McAteer:监督界面要帮人注意,也可能让人略过

来源 1 · 来源 2 · 来源 3 · 来源 4