在应用程序接口（API）启动和上线之前，捕捉预生产中的编码错误对于防止漏洞利用至关重要。这就是为什么我们看到 "左移 "成为 API 开发的一个重要焦点，DevOps 负责将安全测试纳入软件开发生命周期（SDLC），从而降低修复编码错误和漏洞的成本和费用。

但是，对于不是安全专家的开发人员来说，修复代码或了解业务逻辑滥用的可能性可能会耗费大量时间，而安全测试人员则会因为代码审查不够严格而感到沮丧。正是由于这些原因，自动化测试才显得十分必要，而将生成式人工智能（AI）加入其中也能让测试变得更容易。

自动化 API 安全测试主要使用两种应用安全方法中的工具：静态应用安全测试 (SAST) 和动态应用安全测试 (DAST)。

SAST 通过分析源代码来检测漏洞，因此往往在开发过程的早期使用。它可直接集成到集成开发环境、错误跟踪系统和持续集成（CI）/持续开发（CD）工具等 API 开发环境中。当标准规范使其能够检测 API 中的常见实施问题（如错误暴露的 API、参数、错误代码和消息）时，SAST 的效果最佳。

相比之下，DAST 是一种安全测试方法，利用漏洞扫描工具探测生产或非生产环境中正在运行的应用程序，但无法访问源代码。针对应用程序接口的 DAST 的基本要求之一是，工具需要理解应用程序接口，包括语法和业务逻辑。像 OpenAPI Specification 这样的典型规范标准可以帮助理解 API 的语法，但业务逻辑却很难理解。DAST 从用户/攻击者的角度来发现问题，通常用于开发流程的后期阶段。

为什么 API 测试需要 API 工具

SAST 和 DAST 是成熟的网络应用程序工具，可用于 API 测试。

然而，与应用程序接口相关的复杂工作流程可能导致 SAST 分析不完整。与此同时，如果没有更多关于 API 预期如何正常运行的上下文，DAST 就无法准确评估 API 的漏洞，也无法解释什么是成功的业务逻辑攻击。此外，虽然安全和 AppSec 团队对 SAST 和 DAST 运用自如，但开发人员可能会发现使用它们很有难度。

因此，我们看到针对 API 的测试工具越来越普及，可以对 API 规范进行持续验证。API 安全测试正越来越多地集成到 API 安全产品中，并转化为更高效的流程，例如自动将适当的 API 与适当的测试用例关联起来。

任何应用程序安全测试计划面临的一个主要挑战是在发布前生成专门针对被测应用程序的测试用例。在应用程序接口方面，这可能涉及到检查应用程序接口在被调用时是否返回正确的数据，这个问题一旦出错，就很容易导致应用程序数据泄露。

API 安全测试是一个更为复杂的问题，因为 API 基于各种技术（GraphQL、REST 等）、业务功能（敏感或非敏数据暴露）以及其他因素。

许多组织都是手动创建测试计划，这可能会导致错误，并要求开发人员掌握安全测试用例知识，以便将其与 API 关联起来。通过自动化 API 端点的手动关联测试用例，可以加快 API 安全测试的采用。这将使应用程序开发人员能够在将代码从开发环境部署到更高环境之前，确定他们需要执行的必要安全测试。

生成式人工智能（GenAI）在其中扮演什么角色？

首先，使用AI创建这些测试用例可以将几个月的时间缩短到几分钟。它可用于自动生成 API 安全测试计划，并大大减少获得结果的障碍。

例如，安全分析师可以通过人工智能 API 安全工具说："为我的支付 API 生成一个测试计划，以确保 PCI 数据合规"，这样就无需输入查询或详细的测试计划。这样的测试计划将自动检查支付 API 端点和有效载荷特征，并关联适当的测试用例，以测试这些端点是否符合 PCI DSS。

在测试失败的情况下，补救工作流可以导出到第三方系统进行补救，并由 GenAI 提供详细原因，测试结果也可以集成到 CI/CD 管道中。

新的测试用例可在 CI/CD 管道外针对生产服务器运行，以测试已投入生产的 API。还可以根据规范查询这些 API，以确保整个企业符合首选 API 规范，或根据 OWASP API Top 10 2023 运行新的测试用例，以确保它们不会受到战术、技术和程序漏洞的攻击。

要确定 GenAI 对 API 开发和安全测试的全面影响还为时尚早。不过，早期证据表明，它有能力大幅缩短生成测试用例的时间，并协调整个开发和安全团队的测试工作。通俗易懂的英语提示应能更容易地查询和收集必要信息，以证明其符合行业法规。最重要的是，它建立在将 API 安全测试集成到 API 安全工具中的最新进展之上，这意味着该行业不再需要单纯依赖 SAST/DAST 工具。