想了解AppSec工程师如何从“木匠”转型为“园丁”，在AI驱动的安全评估时代重新定义自己的角色吗？从定义工作流到提供关键上下文，这些新兴职责将塑造应用安全的未来。

本文译自 Edition 33 – The role of AppSec engineers is moving from being carpenters to gardeners^[1]

第 33 期 – AppSec 工程师的角色正在从木匠转变为园丁

又到了充满生存焦虑的季节。科技行业的每个人都在思考，自己的工作是否还能在未来几年存在。如果 AI 能写所有的代码，我们还需要开发者吗？如果 AI 能编写 Terraform 并完成部署，我们还需要 DevOps 吗？如果 AI 能写出这篇博客文章，我们真的还需要作者吗？诸如此类。

如果你带领一个团队，这种焦虑还会延伸到你的直接职责之外。我应该雇佣有经验的人来告诉 AI 做什么吗？还是应该雇佣没有经验但聪明的人，因为他们“没有需要忘记的东西”？等等。

在最近的对话中，我发现这种焦虑也蔓延到了 AppSec 团队。每隔三天，你就会看到某个工具发布，声称可以自动化你之前手动完成的工作。SAST 变成了 SAST+AI（带有 AI 功能用于分类的 SAST 工具），然后演变为 AI 驱动的 SAST（利用 AI 发现业务逻辑问题的 SAST），最终变成了 Claude 中的一个按钮（完全消除了 SAST 在 SDLC 中的步骤）。尽管这些工具的现状仍有争议（我在此处写过相关内容 这里^[2]），但趋势是明确的。构成“安全评估”的大部分工作将由 AI 代理完成。我们还不知道谁会做到这一点（现有的安全公司、基础模型公司还是新的初创公司），但它一定会发生！

我也在 Seezo^[3] 内部见证了这一过程。最初只是一个尝试自动化部分安全设计审查的实验，现在已经发展到产品的绝大部分繁重工作都由其自行完成。人类仍然参与结果的审核，但随着每个新模型的发布和平台的改进，他们的角色正在逐渐减弱。

如果 AI Agent 不可避免地将承担大部分的安全评估工作（扫描、分类和沟通），那么 AppSec 工程师的角色是什么？我们甚至还需要一个 AppSec 团队吗？

通过我作为终端用户使用 AI 以及构建 AI 驱动产品的经验，我很清楚 AppSec 团队将继续存在，但他们的角色会发生变化。

从木匠到园丁

当我和我的伴侣 Pooja 等待女儿出生时，我们变成了那种对未来充满紧张感的准父母，想读遍所有关于育儿的内容。我们被各种书籍包围，订阅了育儿通讯等。我们曾一度是“研究型”父母（这是另一个故事，不过那个阶段很快结束了，我们迅速转向了“本能驱动的方法”）。在这一阶段，有一个框架深刻影响了我们的思维方式，并且我们至今仍在尝试应用它。Alison Gopnik 提出的框架^[4] 认为，育儿更像是园丁而不是木匠。

木匠用一块木头“制作”一把椅子，每一个小细节都由木匠掌控。而园丁不同，他们浇水、施肥、除草，但他们“让”植物自己生长。这本书（以及作者的许多文章）强调了这种方法。

暂且不论育儿框架的优劣（你可以争论哪种方法更好），当我思考 AppSec 正在如何变化时，我觉得我们已经从木匠的角色逐渐向园丁转变了一段时间，而 AI 显著加速了这一趋势。

我们已经从“执行安全评估”，到“借助工具进行评估”，再到“配置执行评估的工具并分类结果”。下一个阶段很简单：整个评估过程将由 AI Agent 端到端完成：配置、扫描、分类和沟通。

然而，根据我构建 AI 产品并广泛使用 AI 的经验，我可以肯定的是，AI Agent 的结果质量取决于 Agent 本身的质量、底层基础模型的质量 *以及* 提供给 Agent 的上下文。第三部分并不是可以从 SaaS 工具中购买的。AppSec 团队必须自行构建这部分内容。

AppSec 中的“园艺”是什么样子？

分解来看，即使在 AppSec 智能体（Agents）在安全评估方面表现出色的乐观情况下，AppSec 工程师仍然需要完成 3 件事情：

1. 1. 定义工作流： SAST 应该在什么时候运行？谁应该接收结果？什么时候需要人工审核结果？什么情况下应触发流水线阻塞？这些问题你的 AI 智能体无法回答，因为没有“正确”的答案，正确的做法取决于你组织的安全和技术文化。根据你合作的产品/业务单元/团队的不同，甚至可能需要为不同的团队定义不同的工作流。虽然你可能有工具来编排你的 AppSec 智能体，但定义和调整工作流仍然是 AppSec 团队的工作。在某些情况下，你可以将此外包给开发团队（例如，通过安全冠军计划），但 AppSec 团队仍然需要对此负责。
2. 2. 提供上下文： 这可能是 AppSec 团队工作中最耗时且最难定义的部分。我很清楚，你提供给智能体的上下文越丰富，它提供的结果就越好。那么，你需要向 API 安全智能体提供哪些信息，以便它真正了解内部 API 的速率限制要求？安全设计审查工具应该推荐哪些默认安全模式？这个问题比表面看起来更复杂，因为上下文并不集中在一个地方。它分散在“事实来源”（如代码和部署）和“意图来源”（如安全标准文档、PRD 等）之间。根据公司的运作方式，AppSec 团队需要为合适的智能体提供正确的上下文，以提取最佳价值。提供过多的上下文会用无用信息填满上下文窗口；提供过少的上下文，你的 AppSec 智能体会给出泛泛而谈的结果。
3. 3. 作为人机协作中的人类，并将每次交互视为智能体的失败： 在可预见的未来，运行这些评估的 AI 智能体仍然需要人类的帮助。它们需要验证某些结果，并对某些类型的变更进行人工审核。希望随着时间推移，需要人工审核的项目比例会下降。在此之前，我们需要 AppSec 工程师审查结果、添加更多上下文并决定如何处理输出。我认为看待这一问题的一个有用框架是，将每次人机协作交互视为智能体的失败。除了解决需要解决的问题外，人类还应该“教导”智能体如何在未来处理类似情况。这可能意味着在上下文文件中持久化信息（例如，Claude.md），编写技能/子智能体来处理特定类型的场景等。衡量智能体成功的一个好标准是其结果的准确性以及人类参与的频率。

注意：第 2 和第 3 点有些相关。虽然“上下文”可能是在评估开始之前添加的内容，但“记忆存储”对于智能体的反应也很重要。如果某个误报在不同智能体运行中反复出现，那么记住为什么它是误报以及智能体如何更好地处理它是很重要的。从某种意义上说，这是 3 个不同的活动，但它们也是一个相互促进并不断改进的循环。

这是一个巨大的变化

如果一个 AppSec 工程师在 2015 年陷入昏迷并醒来面对 这个 现实，他们将无法认出自己的角色。这一变化对每个人来说都不会容易。更糟糕的是，还没有足够的工具支持这些行为。安全供应商花了数十年时间才弄清楚结果分类的最佳用户体验（我们尚未完全完善），但没有人知道“提供上下文”的最佳用户体验是什么。过去，定义安全标准和安全工作流是一年一次的事情，而现在事情必须快速发生。这种变化会带来附带损害。根据组织背景的不同，一些公司可能已经完成了这一转变，而另一些公司可能需要很多年才能做到。如果你正在承担 AppSec 领域的新角色，我建议你了解团队在这场变革中的位置，以及这是否适合你。需要明确的是，我不认为这一变化是一个简单的“成熟度曲线”。未适应这些变化的团队不一定不成熟（尽管这是一种可能的解释），这也可能反映了公司软件开发的方式或公司所属的行业（某些行业的 AI 转型会花费更长时间，这是合理的）。

你在光谱的哪个位置？

在 Seezo 内部会议中展示的图片，用于强调我们在“AI 光谱”中的位置。你的具体位置并不重要，但需要与你的组织保持一致。

在 Seezo 的一次内部会议上，我半开玩笑地说，我们需要处于“AI 采用光谱”的同一范围内（见下图）。无论你在光谱中的哪个位置，重要的是与与你位置相近的团队合作。如果你是一个 AI 怀疑论者，但却身处一个 AI 技术狂热团队，你会感到挣扎。如果你对 AI 持谨慎乐观态度，但你的公司要等到“技术成熟”才会使用它，你也会感到沮丧。

引用链接

[1] Edition 33 – The role of AppSec engineers is moving from being carpenters to gardeners: https://www.boringappsec.com/p/edition-33-the-role-of-appsec-engineers[2] 这里: https://www.boringappsec.com/p/edition-32-bigco-is-building-in-appsec[3] Seezo: https://seezo.io/[4] Alison Gopnik 提出的框架: https://www.npr.org/sections/goatsandsoda/2018/05/28/614386847/what-kind-of-parent-are-you-carpenter-or-gardener