近几年，伴随云计算、容器技术以及 DevOps 的普及，DevSecOps 作为糅合了开发、安全及运营理念的全新方法，其关注热度持续上升，并在全球范围内得到广泛应用。目前 IAST 被部分业内人士看作一种“更适合 DevSecOps 流程 构建”的应用程序安全检测技术，受到行业的更多关注。

　　那么 IAST 是否真的更适合 DevSecOps 流程构建？它能够提供哪些核心能力和关键技术，以及有哪些局限性？

　　要了解 IAST 是否真的更适合 DevSecOps 流程构建，首先要弄明白 DevSecOps 到底是什么。根据 Gartner 定义，DevSecOps（即 Development、Security 和 Operations）是指在不减少敏捷度和开发者效率，或在不要求开发者离开现有工具链的情况下，将安全尽可能无缝、无感知地集成进 IT 和 DevOps 开发中。

　　DevSecOps 有三个核心点：一是便于集成，安全工具可以很方便的与现有的 IT 或 DevOps 流程对接和打通，这也是实现 DevSecOps 的前提条件；二是无感知，要求安全工具对已有的 DevOps 流程不能产生任何的影响和干扰；三是在研发阶段解决安全问题，而不是像传统开发流程一样，在软件上线后由安全人员检测问题，再反馈给研发人员来解决问题。问题越早的检测和修复，企业的整体修复成本就越低，这也是 DevSecOps 的核心目的之一。目前来看，DevSecOps 在落地时遇到的主要痛点和难点也体现在这三个点上。那么，更适合 DevSecOps 流程构建的 IAST 到底是什么？有哪些特点？

　　IAST 是交互式应用程序安全测试（Interactive Application Security Testing），是一种新的应用程序安全测试方案，通过在服务端部署 Agent ，收集、监控应用程序运行时的函数执行、数据传输等信息，然后根据污点跟踪算法、值传递算法等一系列算法进行漏洞的识别。

　　IAST 是一种应用程序运行时的漏洞检测技术，所以它具备了 DAST 中检测结果准确的特征；此外，IAST 采集到数据在方法内部的流动后，通过污点跟踪算法来进行漏洞检测，用算法来进行漏洞检测，所以检测结果也具备了 SAST中全面性的特征。

　　同时因为 IAST 安装在应用程序内部，安全人员可以拿到类似于源码级漏洞报告，这种漏洞结果对于开发人员很友好，可以方便开发人员进行漏洞修复。综合来看，IAST 具有高检出率、低误报率、检测报告详细便于排查等一系列优势，可以很好地在 DevSecOps 流程中解决痛点和难点。

　　如何用 IAST 来构建 DevSecOps ，或者说是构建 DevSecOps 流程时，IAST 必须具备哪些功能才能支撑这个流程的构建。大概有三点。第一点，IAST 必须柔和地嵌入 DevOps 流程，即十分便利地与 CI/CD 流程对接，包括与 Jenkins 、Gitlab 等工具打通等；第二点，当IAST 和 DevOps 流程对接时，需要做版本的控制，支持在 Agent 端直接指定项目名称和版本，进行后续的版本跟踪，以及版本的漏洞对比等；第三点，IAST可通过漏洞复测与回归测试，验证此前发现的漏洞是否依旧存在。

　　那么，IAST 的核心能力有哪些？其在具体的场景应用中又会存在哪些局限性？IAST 本质是做漏洞检测，其核心能力主要包括四点：一是实时的漏洞检测，保证不影响 DevOps 的原有效率；二是第三方组件的梳理和漏洞检测，保证应用避免供应链的攻击；三是灵活的漏洞检测逻辑，让用户在使用内置检测逻辑的同时，很方便地配置出具有业务属性的特定检测逻辑，来做业务层面的漏洞检测；四是极低的运营成本，IAST 在企业内部使用时，一定是需要持续运营的，当出现了 IAST 没有覆盖到的漏洞情况时，可以用最低的成本来完善检测策略和检测逻辑，保证漏洞的检出。

　　IAST 的局限性主要体现在 IAST 的内置漏洞策略有限、且无业务属性，无法保证检测所有的安全风险；推荐在上线前通过白盒、灰盒、黑盒、人工渗透测试一起来检测漏洞，然后将 IAST 没有覆盖到的漏洞策略补充进来；上线后可通过外部的众测、SRC 运营等手段，更全面地发现安全风险，同时将漏洞策略补充到 IAST 中，做后续的自动化测试。

更多信息可以来这里获取==>>电子技术应用-AET<<