云安全圈最近有个怪现象：AI辅助工具的能力边界越来越模糊。一部分原因是厂商对AI漏洞发现能力的过度包装，另一部分是真的没人说清楚这些工具该用在哪。但最核心的问题在于——大家把安全当成一个整体问题，实际上它分明是两个。
这两个问题需要完全不同的解法。评估任何工具之前，先分清问题类型。
第一类：模式可识别问题
SQL注入就是典型。不管谁写的代码，未过滤的用户输入拼进SQL查询，在任何应用、任何部署环境里都是漏洞。开发者的意图不改变判定结果——没人故意让自己应用存在注入风险。
XSS、缓冲区溢出、命令注入、不安全的反序列化，以及OWASP Top 10里的大部分Web漏洞都属于这一类。它们是通用模式，漏洞存在是因为代码怎么写，而不是开发者想干什么。一个把用户输入传给eval()的函数，不管用在医疗系统还是菜谱博客，都不安全。
核心特征：判定结果与操作者意图无关，模式可以跨部署环境通用。见过一个SQL注入，就能识别下一个。
第二类：意图依赖问题
公开访问的S3桶，用来托管静态网站的CSS文件完全正确；但同一个配置，如果桶里存的是患者记录，就是HIPAA违规。桶的设置一模一样，判定结果完全取决于操作者对数据内容的声明。
再看个例子：Bedrock代理拥有lambda:InvokeFunction权限且Resource为*，对内部开发工具来说合理——它需要编排任意工作流。但同样的权限，如果代理面向客户查询，而某个Lambda函数能读取标了PHI（受保护健康信息）的桶，就是灾难。IAM策略完全相同，判定结果取决于策略、代理用途、工具链能触及的资源数据分类这三者的交互关系。
核心特征：判定结果依赖操作者声明的意图，模式无法跨部署环境通用。每个组织的标签、策略、信任关系都是独特的。看过一千个"此配置不安全"的例子，依然无法判断下一个配置是否安全——因为下一个操作者的意图不同。
为什么这个区分很重要
把两类问题混为一谈，会导致选错工具、设错预期。
用AI训练的扫描器处理第二类问题，就会产生经典的IDOR误报：扫描器把公开端点标记为严重IDOR漏洞，因为它不知道这个端点本来就该公开。它在用模式识别解决一个模式无法通用的问题。由于判定结果依赖只有该操作者知道的意图，扫描器只能猜测——而猜测必然带来噪音。
热门跟贴