认识达内从这里开始

随着互联网的不断发展，越来越多的企业都在关注软件测试等互联网技术，而本文我们就通过案例分析来简单了解一下，做好软件测试需要用到哪些测试方法。

交互式应用程序安全测试IAST

交互式应用程序安全测试(InteractiveApplicationSecurityTesting)，由Gartner公司在2012年提出，是一种运行时检测工具，依赖于应用程序在被监控时的活动，可监控流经应用程序的流量，以确定底层源代码是否容易被利用。IAST监控正在运行的应用程序的数据流以确定是否存在保护数据的安全控制。例如，它会检测一个字符串是否通过了验证方法，或者密码是否在源头加密并保持加密，直到它退出正在运行的应用程序。因为它是在运行时观察数据的行为，而不是对单个组件如何在本地管理数据进行假设，所以IAST很少误报。同时IAST工具能够读取和理解底层源代码，因此它们可以定位和报告程序员应该关注的代码行，以修复扫描识别出的漏洞。

尽管IAST使用起来简单，但它也有与DAST相同的限制--它需要一个正在运行的应用程序来执行测试，这意味着好将它集成到CI/CD流。并且如果在测试期间执行的功能测试未覆盖的底层源代码，则安全测试代码覆盖率也将低于。

自动化应用程序安全测试的三种方法：静态、动态和交互，这些都在成功的DevSecOps框架中发挥作用，决定将哪些集成到价值流中取决于许多因素。SAST容易在源代码中找到的缺陷--但由于缺乏上下文，它会产生大量的误报，用DAST或IAST(或两者)补充SAST是不错的方法。

软件组成分析SCA

应用程序成为外部攻击的主要对象，其中的一个原因就是开源软件的使用不断增多，为了加快开发速度，开发者会大量复用成熟的组件、库等代码，组织机构对开源和三方组件的使用，从而使更多的API暴露在外。组织的代码库包含不是由开发人员编写的代码。不知道它是否经过安全测试，或者它是否包含恶意代码或恶意软件。更糟糕的是，许多这些开源库依赖于其他开源库来提供更多功能。这意味着在组织的应用程序中存在OSS的依赖链。根据Synopsys的说法，开源占应用程序代码库的70%，这意味着组织的大多数应用程序不是由组织的工程师编写的，面临的挑战在于了解这些依赖项是否安全，如果不安全，如何确保它们安全。

尽管应用程序安全测试可以识别依赖代码中的一些漏洞，但不太可能识别出与它们相关的所有问题。已知漏洞可能会记录在通用漏洞数据库中，一些开源提供商也维护自己的漏洞数据库。必须根据这些数据库检查应用程序依赖性并解决与易受攻击的组件相关的任何风险。有许多软件组合分析工具可用于执行此任务，每个工具都有自己的优点和缺点。在基本级别，它们都提供了漏洞的详细信息和降低风险的建议，例如升级到组件的安全版本或完全使用不同的组件。

通常安全测试阶段进行二次SCA，次则在软件开发的早期阶段。因为在开发过程中更新三方库比在生产环境中更新成本更低，在生产环境中，修复成本更高。

渗透测试

上面讲到的AST应用程序测试和SCA软件组件分析，在研发安全时间过程中都是以自动化形式存在，尽管价值流中有很多层自动化测试，但它不可能安全，作为自动化测试的有效补充，手工安全测试不必可少，在一些受监管的行业部门中，必须由经认可的三方对组织的在线产品或服务进行渗透测试。通常，这些渗透测试是在预生产环境中进行的，它们也可以在实时系统上进行。

国家网络安全中心(NCSC)将渗透测试定义为“对计算机网络或系统的授权测试，旨在寻找安全漏洞”。渗透测试是一种有效的测试方法，是安全人员模拟黑客进入系统的测试方法，他对执行测试的人要求很高，能力强的测试者能够发现有价值的安全性漏洞，而不具备很强攻击能力的测试者就无法有效发现系统中的安全性漏洞，因此很难被大规模使用。渗透测试的过程不具有可重复的特点(主要依赖于测试者的经验，类似调试)，所以脚本化、自动化的渗透测试想法不可行，完全自动化的工具通常只能发现那些可以被用标准方式发现的特定安全漏洞，如简单的SQL注入。在渗透测试期间，授权测试人员尝试使用攻击者使用的相同技术和工具，利用公开已知的漏洞和常见的错误配置，针对系统架构、应用程序、网络层面漏洞进行渗透测试，根据行业特点与业务场景实施渗透测试，范围应覆盖重要安全风险点与重要业务系统，有明确的渗透测试计划与管理机制。

在DevOps中，一天可能会有多次发布。因此，在系统部署之前运行手动测试是不可行的。相反，手动渗透测试是作为年度审查的一部分进行的，以满足监管要求，并作为一个验证过程来突出自动化安全测试过程中的弱点。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。