这是一篇晚到的自省。它关乎对工作来路的一些思考也关乎与业务团队无数次讨论的回顾与总结其中有无奈而克制的抱怨也有一些粗浅的分享。凌晨两点工作群里还在刷已上线。这不是某个新功能发布而是一次 fastjson 安全漏洞修复。最近 fastjson 的主要风险集中在安全漏洞上最该被盯紧的是CVE-2026-16723一个影响 fastjson1.2.68 至 1.2.83版本的远程代码执行RCE漏洞官方已在2026 年 7 月 29 日释出1.2.84版本修复。公司成千上百个系统用到了 fastjson大家在两天时间里加班加点修复、验证、上线。从结果看这是一次漂亮的组织动员几百个系统两天归零。但从技术管理的视角看这更像一次警报——我们为什么又用两天时间去补一个本可以更早被治理的问题一、漏洞不是意外而是依赖的代价现代软件系统几乎都站在开源组件上搭建。fastjson 之所以被广泛使用是因为它方便、快、生态成熟。我们当年引入它享受的是效率红利当它爆出 RCE我们面对的就是债务账单。远程代码执行不是普通漏洞。它意味着攻击者可能绕过边界直接在服务器上执行代码拿到应用进程的全部权限。对上千个系统来说这不是某一个应用的麻烦而是整个组织的风险面。更值得警惕的是那么多部门和系统都在用同一个组件说明我们共享了依赖却没有共享治理。版本散落、引入随意、升级靠人肉排查——这才是两天加班背后的真问题。漏洞是技术问题影响面却是管理问题。先止血再根治。如果当晚无法全量升级临时开启 fastjson 的 SafeModeJVM 参数能在不改业务代码的前提下先堵住默认配置下的利用路径——这是争取时间不是终点。二、回顾封装一层是重复造轮子吗我刚毕业参加第一个项目时团队讨论过一个至今没过时的问题基于开源工具组件再封装一层使用到底有没有价值当时两种声音。一种认为这是重复造轮子——开源社区已经做得足够好我们再包一层只是增加复杂度。另一种认为后续维护会方便统一版本、统一配置、统一升级、统一排错。现在回头看两种观点都对但前提不同。如果封装只是把开源 API 换个名字调一遍那确实是重复造轮子甚至是有害的轮子——它既没减少风险又多了一层要维护的代码。但如果封装层提供了统一版本管理、统一安全配置、统一序列化策略、统一异常处理、统一监控、统一升级通道和兼容测试那它就不是轮子而是方向盘、安全带。好的封装能让这次 fastjson 修复从上千个系统各自改代码、各自上线变成改一处依赖版本重新构建、灰度、上线。坏的封装则让问题更隐蔽出了漏洞要穿透好几层才能定位升级时没人敢动最后只能靠加班堆人力。判断封装价值的标准其实很简单它是否降低了变更成本是否增加了可观测性是否保留了退出机制三问都答是它就不是重复造轮子而是在为未来修路。三、快与稳不是对立而是风险预算业务管理强调快拥抱变化、快速上线、有问题马上修靠不停迭代完善产品、抢占窗口。技术管理强调稳想清楚、设计明白把生产运维、审计和变更控制都考虑进去。这两种思路常被放在对立面。但其实它们只是风险偏好不同、反馈周期不同。业务怕错过窗口所以愿意用速度换试错而系统怕生产事故所以愿意用流程换稳定。可安全漏洞不属于任何一方它是共同底线。快不等于不治理稳也不等于不升级。真正成熟的技术管理不是二选一而是双模业务迭代可以快平台治理必须稳安全基线必须统一。快团队需要安全左移、自动化测试、灰度发布和回滚能力稳团队也需要持续演进、依赖更新和应急演练。没有治理的快是裸奔没有演进的稳是僵化。四、两天加班值得尊敬但不该成为常态两天修复几百个系统当然值得尊敬。同事责任心强、组织执行力强这是真本事。但管理者不能只被这种战时状态感动还要追问为什么影响面这么大为什么版本这么分散为什么修复靠人肉排查为什么没有统一依赖清单为什么不能批量升级、灰度验证、快速回滚为什么每次都要靠加班解决英雄主义可以救一次火但不能替代消防系统。如果组织长期依赖有问题马上修、加班加点上线那它其实是在用人的消耗弥补系统能力的不足。五、技术管理应该留下什么这次事件之后比升级到 1.2.84 更重要的是留下几样东西第一依赖治理。建立 SBOM软件物料清单掌握每个系统用了什么组件、什么版本收敛版本建立统一 BOM 和白名单禁止随意引入未经审核的依赖。让我们有哪些依赖从靠人脑记忆变成一张随时能拉出来的表。第二有价值的封装层。抽象接口、隔离实现统一安全策略和升级通道。让业务代码不直接绑死在某个开源实现上——这样未来换版本、甚至从 fastjson 迁到的 Jackson才有余地而不是动一发牵全身。第三应急机制。订阅漏洞情报自动分析影响面支持批量修复、灰度发布、回滚和验证。让修复不再依赖某个英雄而是依赖一套流程。第四组织分工。平台团队提供统一依赖和工具业务团队负责升级验证安全团队制定基线管理层给治理留出时间和预算。各司其职才不会每次都临时拉人。第五允许讨论重复造轮子但要有决策记录、成本收益和退出机制。不要为了 KPI 造轮子也不要为了省事把风险留给未来。fastjson 的漏洞会过去但组织对依赖的态度、对封装的理解、对快与稳的平衡会长期存在。写在最后最好的修复不是又一次通宵上线而是下一次漏洞来临时系统能告诉你有多少影响、该改哪里、能否灰度、能否回滚——然后让工程师正常下班。 从一次 fastjson 漏洞修复看技术管理
这是一篇晚到的自省。它关乎对工作来路的一些思考也关乎与业务团队无数次讨论的回顾与总结其中有无奈而克制的抱怨也有一些粗浅的分享。凌晨两点工作群里还在刷已上线。这不是某个新功能发布而是一次 fastjson 安全漏洞修复。最近 fastjson 的主要风险集中在安全漏洞上最该被盯紧的是CVE-2026-16723一个影响 fastjson1.2.68 至 1.2.83版本的远程代码执行RCE漏洞官方已在2026 年 7 月 29 日释出1.2.84版本修复。公司成千上百个系统用到了 fastjson大家在两天时间里加班加点修复、验证、上线。从结果看这是一次漂亮的组织动员几百个系统两天归零。但从技术管理的视角看这更像一次警报——我们为什么又用两天时间去补一个本可以更早被治理的问题一、漏洞不是意外而是依赖的代价现代软件系统几乎都站在开源组件上搭建。fastjson 之所以被广泛使用是因为它方便、快、生态成熟。我们当年引入它享受的是效率红利当它爆出 RCE我们面对的就是债务账单。远程代码执行不是普通漏洞。它意味着攻击者可能绕过边界直接在服务器上执行代码拿到应用进程的全部权限。对上千个系统来说这不是某一个应用的麻烦而是整个组织的风险面。更值得警惕的是那么多部门和系统都在用同一个组件说明我们共享了依赖却没有共享治理。版本散落、引入随意、升级靠人肉排查——这才是两天加班背后的真问题。漏洞是技术问题影响面却是管理问题。先止血再根治。如果当晚无法全量升级临时开启 fastjson 的 SafeModeJVM 参数能在不改业务代码的前提下先堵住默认配置下的利用路径——这是争取时间不是终点。二、回顾封装一层是重复造轮子吗我刚毕业参加第一个项目时团队讨论过一个至今没过时的问题基于开源工具组件再封装一层使用到底有没有价值当时两种声音。一种认为这是重复造轮子——开源社区已经做得足够好我们再包一层只是增加复杂度。另一种认为后续维护会方便统一版本、统一配置、统一升级、统一排错。现在回头看两种观点都对但前提不同。如果封装只是把开源 API 换个名字调一遍那确实是重复造轮子甚至是有害的轮子——它既没减少风险又多了一层要维护的代码。但如果封装层提供了统一版本管理、统一安全配置、统一序列化策略、统一异常处理、统一监控、统一升级通道和兼容测试那它就不是轮子而是方向盘、安全带。好的封装能让这次 fastjson 修复从上千个系统各自改代码、各自上线变成改一处依赖版本重新构建、灰度、上线。坏的封装则让问题更隐蔽出了漏洞要穿透好几层才能定位升级时没人敢动最后只能靠加班堆人力。判断封装价值的标准其实很简单它是否降低了变更成本是否增加了可观测性是否保留了退出机制三问都答是它就不是重复造轮子而是在为未来修路。三、快与稳不是对立而是风险预算业务管理强调快拥抱变化、快速上线、有问题马上修靠不停迭代完善产品、抢占窗口。技术管理强调稳想清楚、设计明白把生产运维、审计和变更控制都考虑进去。这两种思路常被放在对立面。但其实它们只是风险偏好不同、反馈周期不同。业务怕错过窗口所以愿意用速度换试错而系统怕生产事故所以愿意用流程换稳定。可安全漏洞不属于任何一方它是共同底线。快不等于不治理稳也不等于不升级。真正成熟的技术管理不是二选一而是双模业务迭代可以快平台治理必须稳安全基线必须统一。快团队需要安全左移、自动化测试、灰度发布和回滚能力稳团队也需要持续演进、依赖更新和应急演练。没有治理的快是裸奔没有演进的稳是僵化。四、两天加班值得尊敬但不该成为常态两天修复几百个系统当然值得尊敬。同事责任心强、组织执行力强这是真本事。但管理者不能只被这种战时状态感动还要追问为什么影响面这么大为什么版本这么分散为什么修复靠人肉排查为什么没有统一依赖清单为什么不能批量升级、灰度验证、快速回滚为什么每次都要靠加班解决英雄主义可以救一次火但不能替代消防系统。如果组织长期依赖有问题马上修、加班加点上线那它其实是在用人的消耗弥补系统能力的不足。五、技术管理应该留下什么这次事件之后比升级到 1.2.84 更重要的是留下几样东西第一依赖治理。建立 SBOM软件物料清单掌握每个系统用了什么组件、什么版本收敛版本建立统一 BOM 和白名单禁止随意引入未经审核的依赖。让我们有哪些依赖从靠人脑记忆变成一张随时能拉出来的表。第二有价值的封装层。抽象接口、隔离实现统一安全策略和升级通道。让业务代码不直接绑死在某个开源实现上——这样未来换版本、甚至从 fastjson 迁到的 Jackson才有余地而不是动一发牵全身。第三应急机制。订阅漏洞情报自动分析影响面支持批量修复、灰度发布、回滚和验证。让修复不再依赖某个英雄而是依赖一套流程。第四组织分工。平台团队提供统一依赖和工具业务团队负责升级验证安全团队制定基线管理层给治理留出时间和预算。各司其职才不会每次都临时拉人。第五允许讨论重复造轮子但要有决策记录、成本收益和退出机制。不要为了 KPI 造轮子也不要为了省事把风险留给未来。fastjson 的漏洞会过去但组织对依赖的态度、对封装的理解、对快与稳的平衡会长期存在。写在最后最好的修复不是又一次通宵上线而是下一次漏洞来临时系统能告诉你有多少影响、该改哪里、能否灰度、能否回滚——然后让工程师正常下班。