2.4 应用程序安全保证

传统上，应用程序安全实践集中在应用程序测试的概念上，我们在这里称之为应用程序安全保证。在这里，应用程序安全超越了治理和流程等较软的主题，旨在回答有关应用程序技术风险的问题。我们在这里讨论五种主要方法和几种使用的技术：

• 静态应用程序安全测试（SAST）
• 动态应用安全测试 (DAST)
• 交互式应用程序安全测试 (IAST)
• 移动应用程序安全测试（MAST）
• 软件组成分析（SCA）

静态应用程序安全测试

进行代码审查的概念，对于从事应用程序安全实践的人来说可能并不陌生。这是对某一时刻应用程序或软件组件源代码的静态视图。通常，在一些重要的里程碑，如重大发布或架构变更时，会进行详尽的静态应用程序安全测试（static application security testing, SAST）。而日常的代码审查则仅限于对代码库中新编写或更新的代码进行检查。

SAST可以通过手动或自动方式进行。然而，在大型软件项目中，手动审查可能会面临可扩展性问题。此外，由于某些应用程序框架在不同路径中可能重复使用文件名，这也可能使测试人员感到困惑。即使是手动代码审查，测试人员通常也会遵循优先级流程，重点寻找已知漏洞函数或应用程序的高信任区域，如身份验证和访问、密码管理、数据加密等。挑战在于，像输入验证例程等重要功能可能并不总是在这些审查中被捕捉到，而且结果高度依赖于测试人员的技能和测试范围的时间。

同样，自动化测试可以帮助完成测试的完整性，并以更快的速度处理大规模的代码库，但在所有测试方法中，SAST的误报率最高。即使是最好的SAST工具，误报率通常也在5%或更高。这看起来不多，但当你意识到一个大型应用程序可能识别出成千上万的错误时，情况就不同了。尽管如此，通过利用机器学习（ML）等技术进行创新，可以基于先前的审计活动构建，从而提高准确性。（误报是指基于规则集识别出的发现，尽管这些发现实际上并未对系统构成风险。这些误报可能会导致团队浪费时间分析那些并不实际构成风险但根据使用的工具和规则触发的发现。）这也是对软件材料清单（software bill of materials, SBOM）作为漏洞检测手段的常见批评。误报会制造噪音，损害应用程序安全计划的可信度，并可能导致软件发布延迟或在无明显价值的错误领域重新优先考虑安全工作。这种认知消耗可能会使团队士气低落，并阻碍软件交付的速度。

尽管存在这些问题，SAST仍然是识别软件缺陷、安全性和质量的重要且有价值的手段之一。它也是帮助开发人员了解他们在哪里编写不安全代码的最佳方法之一。许多现代集成开发环境（IDEs），如Eclipse等，配备了SAST工具的插件，当开发人员使用不安全约定或做出可疑的代码质量选择时，这些插件会提供即时反馈。此外，许多安全编码培训平台使用不安全的代码片段示例来培训开发人员编写更安全的代码。

在软件透明度工作中利用SAST的最有用方法之一是帮助验证和改进你的软件物料清单，并识别出哪些大型库被使用，但只需要其中的一小部分功能。通常情况下，一个包含100个或更多函数的库会被导入，但你的软件只调用了不到10个函数，这种情况下，SBOM可能会识别出一些实际上无法被利用的漏洞，导致误报。如果你能剔除不必要的代码，将会减少很多噪音。不过，修改后别忘了重命名你的库，因为SBOM工具会根据库的名称和版本来识别内容，如果名称和版本不匹配，可能会导致识别错误。

动态应用安全测试

虽然SAST通过源代码从内到外检查应用程序，动态应用程序安全测试（dynamic application security testing，DAST）则通过HTTP和其他基于Web的协议从外到内进行测试。需要注意的是，DAST通常局限于Web应用程序，无法用于桌面、移动或其他不监听和响应HTTP的应用程序。此类测试专注于直接与正在运行的应用程序或其组件（如API或监听服务）进行交互。DAST的一个挑战是，测试必须在应用程序达到足够的操作状态后才能进行，因此，其执行时间比SAST要晚得多。一个关键的优势是DAST的误报率较低，但相应的漏报率更高。（漏报是指测试未能检测到实际存在的安全问题，这同样是不理想的。)

通常，这种方法的工作方式是配置扫描器以编程方式与应用程序交互，例如，通过脚本化的浏览器模拟界面。扫描器首先浏览Web应用程序，识别所有路径（除了测试人员排除的那些），跟随页面上的任何链接，并忽略测试范围外的其他Web域。这通常也被称为Web爬虫或蜘蛛。如果需要身份验证，也可以配置扫描器处理应用程序中的特定Web表单。

在蜘蛛程序完成后，DAST工具会构建一个可供测试的路径列表，并使用预配置的测试列表来搜索缺陷，如SQL注入和跨站脚本攻击等。一旦识别出潜在风险并捕获到令工具怀疑问题有效的证据，DAST工具会以扫描报告的形式将这些结果返回给测试人员。自动化的DAST测试通常需要很少的测试技能和交互，但它确实提供了对应用程序工作原理的良好可见性。在某些情况下，这种可见性在构建Web应用程序防火墙规则和了解应用程序的攻击面时非常有用。

更复杂的DAST场景通常涉及拦截代理的概念，即测试人员在其浏览器中配置一个Web代理，拦截他们的HTTP请求和响应，以便进行操作和利用应用程序。尽管这通常是一个手动操作，但从应用程序站点地图开始，可以为测试人员提供测试范围。此外，大多数此类工具确实提供了一定程度的自动化，原生或通过插件实现，如Burp Suite或Zed Attack Proxy（ZAP）工具系列所使用的那样。

混合分析映射（HAM）是一种结合SAST和DAST优势的技术，能够生成混合静态动态测试结果。其理念是，SAST可以对软件进行全面覆盖并识别潜在问题，然后运行DAST，彻底扫描应用程序的攻击面，寻找与SAST发现相关的漏洞。这种方法对于以最大程度的可信度对漏洞进行优先排序非常有效。然而，尽管这种匹配能够提高检测的准确性，SAST的发现仍然需要经过验证，以确保其真实性和相关性。

在软件供应链安全方面，建议回到应用程序的威胁模型，考虑它可能被如何滥用。例如，如果你的应用程序调用外部脚本，外部域名被接管是否会将恶意代码注入到用户的会话中？拦截代理提供了出色的功能，可以操纵和重定向流量，以模拟这些场景。如果应用程序执行组件更新呢？这些场景是无穷无尽的，通过赋予你的测试团队使用灵活工具的能力，发挥创造力并拥抱他们的“邪恶”一面，你可以扩展对潜在风险的理解。

另一个在讨论DAST时值得强调的点是其识别第三方客户端依赖项及其已知漏洞的潜在能力。例如，一个Web应用程序通过脚本标签而不是包管理器（如npm）包含库。大多数SBOM工具可能会忽略这种检查和上下文，而DAST工具可能能够识别并报告这些潜在风险。

交互式应用程序安全测试

另一种测试形式是交互式应用安全测试（IAST），它使用运行时中的应用程序仪表或使用软件开发工具包（SDK）直接进入运行中的应用程序，跟踪代码流动情况，观察数据在应用程序中的流动情况。IAST供应商声称，这种方法可以比其他测试方法更真实地反映应用程序的运行情况，有时使用IAST就像在托管应用程序的服务器上安装一个软件代理一样简单，但通常不支持所有编程语言和框架。

这种技术也是过去十年中出现的一种被称为运行时应用程序自我保护（RASP）的新型保护机制的核心。RASP作为网络应用防火墙（WAF）的替代或至少是补充方法出现。由于RASP了解应用程序内部发生的事情，它不会像WAF那样被绕过WAF风格的攻击或签名变异所欺骗。然而，由于它看不到原生的网络流量，RASP无法在嘈杂的攻击影响网络应用程序之前进行缓解。

事实上，IAST供应商（如Contrast Security）的研究表明，我们认为会给我们带来风险的许多软件实际上从未被我们的代码调用过。大多数开源组件可能只使用了其功能的10-20%。此外，随着SaaSBOM（捕获服务的物料清单）、API、数据流等主题的发展，IAST可能是捕获这些信息最可行的方法之一。这是目前SBOM工具供应商不支持的领域，但随着软件透明度市场在未来几年中的成熟，IAST将扮演的重要角色值得期待。

移动应用程序安全测试

随着移动设备及其相关应用程序的普及，另一种测试形式在行业中变得常见。这被称为移动应用安全测试（MAST）。MAST涉及使用静态和动态测试方法来识别与移动应用程序、平台和设备（如Android和iOS）相关的安全漏洞和缺陷。这种测试可以帮助识别危险功能、过多权限以及可能被恶意行为者利用的漏洞。随着SBOM（软件物料清单）概念的发展，我们现在在移动设备领域看到了SBOM的创新解决方案，例如NowSecure，它可以从运行中的应用程序生成SBOM，包括其应用程序库依赖关系、操作系统级别依赖关系和应用程序正在通信的服务（www.nowsecure.com/press-releases/nowsecure-announces-the-worlds-first-dynamic-software-bill-of-materials-sbom-for-mobile-apps）。

软件成分分析

另一种常见的应用保障方法和工具类别是软件成分分析（SCA）。简而言之，SCA有助于识别代码库中的开源软件（OSS）及其相关依赖关系。组织已经开始广泛使用OSS组件和库。SCA可以帮助评估应用程序的安全性、许可证合规性和代码质量。一些SCA工具提供支持生成SBOM（软件物料清单），以帮助提供组成应用程序的组件和依赖关系的详细清单。正如我们将在第10章“供应商的实用指南”中讨论的那样，了解应用程序或产品中包含哪些OSS组件及其相关的许可和漏洞信息是至关重要的。行业实践者通常还建议在SDLC（软件开发生命周期）早期使用SCA工具，以便在软件开发期间识别和减轻漏洞，防止这些漏洞传递给应用程序用户或在SDLC的后期阶段需要更昂贵和破坏性的修复。在第6章“云和容器化”中，当我们讨论推动DevSecOps时，我们将触及这一点。