🍿
文章想以《浪浪山小妖怪》里的几句台词作为开篇
熊教头:“小的们,你们看好了,这弓,要这么拉。你们还得多练呐,不然,怎么在浪浪山干活啊!”;
狼总管:“大王说,要突出一个‘陷’字。”
工作当中的烦恼真的让人无力和恼怒,在做的一个CVE相关的AI项目,在误报阶段已经有60-70%的CVE可以被AI处理,准确率也达到了90%,接下来阶段就是对非误报的CVE进行安全风险评估,包括安全技术分析、攻击向量模拟、可利用性评估、修复难易评估、Patch修复、发布Errata,这里涉及到的数据、工作量极其繁杂,一个40+人的团队在投入但是人力上还是捉襟见肘。Leader决定拉起一个「数字员工」的项目,将AI引入全部的CVE处理流程,用来提升CVE处理的效率解决人力的问题。
我们作为安全团队,除了负责AI Infra的建设之外,要做的一个事情就是为CVE漏洞给出安全风险评估,包括安全技术性分析、攻击向量模拟甚至CVE利用的PoC等等,这里面涉及到很多安全数据和模型,发挥AI的能力是比较自然的思路,于是大家一致同意把这个纳入到上面提到的「数字员工」项目中。
公司将AI作为公司级别的战略,所以AI应用在公司内部属于百花齐放的阶段,跟创业类似的,周边团队在开发AI应用的时候碰到Agent幻觉等问题,导致在收益上比较微薄也就是常说的ROI不高,但也确实的减少了几乎一半的工作量。面对这种经验,Leader们泛起嘀咕——现阶段大力投入AI是不是会收益微薄甚至项目失败,不妨等技术成熟一点再加大投入。于是Leader在项目讨论会上,一直push我们要求给数据、给指标,一个没有跑起来的项目当然没有符合老板预期的数据和指标,甚至连数据打标点都还在设计中,可想而知项目的推进阻力会如何之大。
这期间还发生一个让我无言以对的事情,我的直系Leader问我「CVE这么多繁琐的流程,如果我跳过所有的前序步骤,来一个CVE我就用AI merge修复patch这样是不是也可以?」。面对一个企业级的操作系统产品,这个问题有很多角度来分析和论述:
- 修复patch来源考虑,大约只有30%左右的CVE才有上游patch
- AI修复CVE代码的能力问题,复杂patch人肉cherry-pick的时候都会失败何况AI
- AI合入patch的效率和成本问题,面对每个月1000+的CVE修复(一个CVE修复时间按照8个小时算,那是15人月工作量,换算成AI Token应该有千万量级资金开销了)
- 直接合入patch代码引入的安全性问题,patch是否修复CVE,是否引入新的风险,这些不分析无法判断
- 直接合入patch代码引入的稳定性问题,变更意味着稳定性问题,看看Debian操作系统的版本管理就知道了
面对革命性的技术浪潮,到底是想清楚再做还是先做然后调整呢?我的理念是「想都是问题,做才是答案」,同样都是付出成本与代价,与其在想这件事情上浪费人力物力,不如把成本放在做这件事情。想出一个 90 分的方案再去执行,相比一个 60 分的方案加后续再打磨完善,后者更能在过程过获得做事的成就感,形成一个输入和输出的正循环。
抛开理性分析,安全团队不是应该专注于自己领域的问题的研究和解决吗?把自己的Ego和Scope扩展到这么大,是不是太把自己当回事了,大厂这样的巨无霸面前不会真由基层员工来掌控方向的,都是螺丝钉就别给自己加戏了。大厂这样环境给人太多枷锁了,一直在被要求回答:我是谁,我在做什么,我为什么要做,为什么是我做,Blablabla……作为小团队的Leader没有这样清醒的意识,真的会「累死三军」
这篇文章没什么总结更没什么思考,只是感慨跟我类似的这些困在大厂里的「牛马」,慢慢的你会越来越清醒的意识到一个道理:“在大厂永远不会得到精神自由”!






















