20年来,我们建造了更好的烟雾探测器。
现在我们终于要建消防员了 我们非常擅长找问题 您的 IDE 在完成输入前强调一个弱点 。
你的CI输油管失效了 因为从2019年起 3个深层的过渡性依赖性 你的收件箱每个星期二都会收到一个Depabot PR,你会礼貌地忽略到星期四.
GitHub Advanced Security, Snyk, Semgrep, Wiz, Orca, Lacework, 扫描仪的字母汤把安全变成了一个燃烧的建筑物的非常高分辨率的照片.
我们确切知道火在哪里。
我们有热图 我们有重度分数 我们有无人读取的CVSS矢量 我们只是没有把它熄灭。
这是我们即将离开的奇怪时代。 " 寻找经济 " 是可喜的 AppSec的最后十年是建立在一项无口可言的协议上:工具找来,人类固定.
寻找困难时,这是合理的分工。
您需要抽象的语法树, 调味分析,符号执行, 和一个博士来解释 您的 Python 字符串连接为什么实际上是远程代码执行。
于是我们围绕探测建立了整个经济。
数出弱点的板子 领导板让团队感到羞耻 因为他们不够快 合规框架 询问你是否知道你的bugs, 而不是如果你修复它们。
衡量成功与否的尺度变成了检测的刻薄时间,而不是补救的时间。
结果是可预测的。
平均企业有类似50-100天的开放关键弱点,不是因为工程师懒惰,而是因为漏斗从根本上被打破了.
单次扫描可以产生一万个发现.
你不能用一个工程师来制造一万个修正 用计算法寻找天平 。
与人修鳞.
人类没有规模。
任何保持开放源代码项目的人都非常了解这种痛苦。
你得到一份优美,详细的报告 并有概念证明, CVSS的分数, 以及你威胁互联网的礼貌说明。
你没有得到的是一个补丁 通过你的测试, 尊重你的建筑, 并且不打破三个奇怪的边缘 案例 只有你知道。
我们庆祝了发现者。
我们把修理工烧了 为何修复是不同的问题物种 将固定为发现加一步是令人着迷的。
事实并非如此。
这是一项完全不同的认知任务。
查找是一个模式匹配问题 。
这个代码看起来像我以前见过的坏代码吗?
用户输入是否流入敏感水槽而不消毒?
一种LLM在这点上令人震惊的好,因为它已经看到了数百万的好和坏代码的例子.
修复是一个规划和背景问题。
要正确修复一个错误,你需要理解意图,而不仅仅是语法.
你需要知道原作者想要做什么, 代码库的其余部分所依赖的是哪些变化, 测试套房实际上覆盖了什么, 而它假装覆盖什么, 以及如何做出最小可能的改变, 关闭洞而不打开两个新的。
坏的修补比没有修补更糟糕 错误的修补给你虚假的信心 和一个新的CVE 和一个不同的名字。
这就是为什么早期的自动补救尝试 感觉像一个Clippy的安全。 "看起来你注射了SQL, 要我加个ORM吗?" 不,谢谢。
改变的并不是模型在写代码上得到了更好的表现,尽管他们做到了.
改变的是,他们更擅长操作工具。
新一代不是写 diff 的聊天员。
它是一种能复制出bug,写出因它而失败的测试,编辑出源,运行相关测试,观察失败,再试一次,并直行到绿色检查标记回来.
换句话说,它可以做一个无聊的,有条理的,不光彩的循环,人类工程师在修补某事时实际做的.
凌晨2点不累 我们进入了补丁特工时代 看看边上发生了什么 在开源中,你现在有代理商