2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
在我之前担任开发人员的一份工作中，有人第一次在我们的代码库上运行 Semgrep。结果返回了 180 个发现项。我们没有安全工程师。运行该工具的开发人员查看了输出结果，关闭了终端，此后我们再也没有运行过它。
这并非一个关于团队粗心的故事。这是一个关于工具的故事，该工具生成的输出结果让缺乏专业知识的小公司团队不知如何处理。
在与小型开发团队合作的过程中，我目睹这一场景发生的次数多得数不清。这也是我在过去一年里构建 SecOpsium 的原因。但在介绍该产品之前，让我先解释一下真正的问题所在，因为我认为这个问题被误解了。
问题不在于扫描
Semgrep 和 Gitleaks 是优秀的工具。它们免费、积极维护且功能强大。如果你尚未使用它们，应该开始使用。
问题在于运行这些工具十分钟后发生的情况。
你会得到 200 个发现项。其中一些是危急的。一些是测试文件。一些是 2021 年注释掉的代码。一些是真正的密钥。一些是变量名，虽然符合规则的模式匹配，但不包含任何敏感信息。在输出结果中，它们看起来都一样。
现在，你是一名同时负责开发运维、审查拉取请求和处理事故的开发人员，正盯着 200 个项目，却没有任何明确的指示表明哪三个项目在本周真正重要。
于是你关闭了终端。或者你创建了一个标记为“安全发现项”的 Jira 工单，让它永远停留在待办事项列表中。或者你花费两天时间手动分类，在修复任何问题之前就已精疲力竭。
这才是真正的问题。扫描从来都不是困难的部分。
为什么基于规则的扫描器会产生如此多的噪音
从技术角度理解这种现象发生的原因会有所帮助。
Semgrep 和 Gitleaks 是基于规则的。它们匹配模式。测试文件中名为 api_key_example 的变量与活跃生产配置中真实的 Stripe 密钥以相同的方式被标记。Gitleaks 扫描熵值和已知的凭证模式，但无法区分六个月前已轮换并撤销的密钥与当前正在使用的密钥。这两种工具都不理解你的代码库，它们将注释掉的凭证与位于每次请求都会加载的文件中的活跃凭证同等对待。
结果就是信噪比极低，使得输出结果对于非安全工程师来说几乎无法使用。而残酷的讽刺在于，开发人员学会了忽略它。这比完全不扫描更糟糕，因为现在你在真实暴露风险之上又产生了虚假的安全感。
为什么这个问题在过去 12 个月显著恶化
在人工智能编码工具出现之前，噪音问题就已经存在。发生变化的是秘密信息进入代码的体积和性质。
当开发人员手动编写代码并提交秘密信息时，通常有一个故事背景：他们正在测试某些内容，忘记将其移动到 .env 文件中，或者从教程中复制了代码。这种错误带有人的痕迹和人的节奏。
人工智能代理的工作方式不同。
使用 Cursor、Copilot 或任何代理式工具的开发人员描述他们想要的内容，然后由代理编写代码。一次生成数千行。代理的任务是完成“集成 Stripe 支付”、“添加 AWS S3 上传”、“连接到数据库”等任务。它会执行这些操作。有时，完成任务意味着从任何能找到的地方获取凭证，因为这样才能使代码运行。
我更频繁地观察到两种模式：
未填充的占位符被发布。
代理生成凭证占位符，如 YOUR_API_KEY_HERE、sk_test_REPLACE_ME、INSERT_DB_PASSWORD。这些本应被替换。 Som
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
