2025 年现代动态应用程序安全测试 (DAST) 2.0 的崛起

静态应用程序安全测试 (SAST) 受到安全团队的青睐，因为它是一种无需真正参与开发人员即可轻松部署安全测试的方法。

凭借在软件交付生命周期早期分析源代码的能力，SAST 解决方案提供了一种更主动的方法来在生产之前发现安全问题。但这是有代价的。

SAST 工具的许多发现都是潜在的漏洞，这意味着需要大量的人工和时间来评估和确定风险的优先级。开发人员只能在缺乏上下文的情况下解析数千条警报，以确定哪些问题最为关键，更不用说如何将它们映射到 CWE 类别以查明真正的问题和必要的修复。

静态应用程序安全测试 (SAST) 的痛点

SAST 最初承诺为安全团队提供主动安全测试，但由于噪音太大，很快就成为开发人员面临的根本问题。

它向开发人员提供成千上万的发现结果，其中大部分是“误报”，并将代码模式标记为“潜在不安全”，而不评估实际的可利用性，这使得开发人员几乎不可能确定需要修复哪些问题的优先顺序。

SAST 也无法提供有意义的上下文；它可能会检测到有问题的代码模式，但无法确定该代码是否正在使用、是否暴露在互联网上或是否正在积极促成可利用的漏洞。

它无法回答重要的问题，例如，该代码是否在生产中运行？它是否暴露在互联网上？它真的可以被利用吗？

结果如何？数千条警报，却一无所获。开发人员只能淹没在 Jira 工单中，分散在 PR 和积压工作中，只有模糊的“尽快”截止日期，没有明确的优先级。

与此同时，软件仍需交付。

SAST 需要运行时上下文来确定优先级

没有上下文的安全性只是猜测。如果不知道什么是可利用的、代码库中存在风险的位置以及如何修复它，安全测试就只是一堆毫无意义的警报。

现代动态应用程序安全测试 (DAST) 通过在运行时测试应用程序来改变脚本，找出真正的风险而不是理论上的风险。它不会转储一份充满“潜在”问题的报告，而是清楚地告诉开发人员：此漏洞可利用，在此服务中，在此代码行中。这就是在 StackHawk 构建的上下文的力量。

旧版 DAST 存在自身的问题。这些解决方案传统上速度缓慢、与开发人员工作流程不一致，并且对 API 视而不见。对生产环境进行扫描需要数小时或数天的时间，即使发现漏洞，也无法将其追溯到源代码以便轻松修复。如果没有 API 测试，旧版 DAST 就会错过大量现代攻击面，使组织暴露在外。

但是现代 DAST 解决方案通过以代码形式运行、实时测试 API 和微服务以及在开发人员工作的地方提供即时反馈来解决这些问题。

现代 DAST + SAST = 可操作的见解

现代 DAST 将继续发展并支持现代软件交付的速度，而随着人工智能的兴起，软件交付的速度只会越来越快。

在 DAST 2.0 的世界中，开发人员编写和合并代码时，API 和应用程序正在实时测试。工程师和安全团队现在都可以通过他们的工作流程获得即时、可操作的安全洞察，而不必筛选大量潜在漏洞。

简而言之：通过将 SAST 发现与现代 DAST 环境相结合，工程师可以优先考虑重要事项并打开更快、更安全的软件交付之门。

SAST 帮助定义了 AppSec 的早期时代，但它从未针对现代开发的规模、复杂性和速度进行设计。开发人员淹没在噪音中，安全团队被缺乏明确优先级的漏洞所淹没。有了 AI 辅助编码，SAST 的未来可能会变得过时，AI 副驾驶员会生成修复和建议。

现代 DAST 可在风险点实时提供验证，并直接集成到工程工作流程中。它不仅能发现漏洞，还能证明哪些漏洞可被利用并实现快速有效的修复。