这篇博客打算重点介绍一下IAST相关的内容，以及IAST如何在DevSecOps中的CI/CD中的结合。做一期大杂烩，同时也是对我这半年多来的实习一次技术总结。
大致需要了解的内容为：
CI/CD的介绍
DevOps的介绍
IAST的介绍
在Jenkins流水线引入IAST
CI/CD是一种在应用开发阶段来引入自动化集成和部署交付的方法。其具体的核心是持续集成、持续交付和持续部署。在过去的开发阶段中，往往都是各个开发人员写完代码再集成在一起，这时候如果出现bug，则所需耗费的人力、时间成本会大大增加。有CI/CD的频繁自动化集成和交付之后，开发人员就只需将代码上传svn\git平台上触发CI/CD流程即可，大大减小了研发期间的人力和时间成本。
其中CI指的是持续集成（Continuous Integration），而CD指的是持续交付（Continuous Delivery）或持续部署（Continuous Deployment）。
举个例子：工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。
而持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。
DevOps是指开发运维一体化的概念，以实现用户价值作为唯一评判标准，保证产品的功能以及功能的实现、成功部署和稳定使用。其DevOps的核心就是之前介绍到的CI/CD，在此基础上针对开发（Dev）和运维（Ops）团队的一种解决方案。这种解决方案大大的体现出敏捷开发的优势以及长处。
DevOps的好处与价值
对于业务与产品而言，DevOps的好处更多基于持续部署与交付。 从组织结构而言，DevOps是部门间沟通协作的一组流程和方法，有助于改善公司组织文化、提高员工的参与感。
代码的提交直接触发：消除等待时间，快速反馈
每个变化对应一个交付管道：使问题定位和调试变得简单
全开发流程高效自动化：稳定，快速，交付结果可预测
持续进行自动化回归测试：提升交付质量
设施共享并按需提供：资源利用最大化
总的来说DevOps就是一套解决方案，一套开发-运维落地的流程，其中涉及的工具链各式各样，下图是从网上找到的一张图，囊括了部分DevOps各个阶段的工具集合。
IAST，全称为交互式应用安全测试（Interactive Application Security Testing，IAST），是一种自动化诊断发现应用程序漏洞的一种技术，其核心技术可以分为主动式探测与被动式插桩两种方式，本文主要讲的是被动插桩（Instrumented）的方式。
其被动插桩方式的原理是利用Agent部署在应用服务器上，并通过织入相关代码来获取程序执行过程中的上下文数据流信息，并结合污点传播的方式判断是否存在漏洞的一套流程。相比较之下，与其他两款DAST（黑盒）、SAST（白盒）自动化产品比较，IAST的优势不仅存在误报低，而且对系统的性能和环境的污染程度较低。
IAST在应用测试中取到至关重要的地位，对自有研发的代码可以进行测试发现漏洞，同时IAST本身也会集成SCA的方式，获取应用程序在运行时候所有加载的第三方依赖库，并与网上的在野利用漏洞和CVE版本号进行匹配，同时保证第三方应用的安全使用。
因为IAST是部署在应用服务器上的（例如Tomcat、Springboot Jar包、Weblogic），再通过测试人员触发程序的功能进行测试，IAST的Agent就会捕获到相应的数据流信息，从而判断出漏洞。而整个这个过程基本上无需等待时间，即点即出的结果。
在这里就可以打成一个Docker镜像，并将k8s部署的yaml文件模板一起放到git仓库中，到时候从仓库中拉去-->修改-->编译-->推送到Harbor-->k8s部署
Dockerfile中的文件如下：
#基础镜像
FROM docker.io/tomcat:9.0.31\-jdk8-openjdk
#将虚拟机内的war包复制到tomcat容器的webapps目录下
ADD xxx.war webapps/xxx.war
#复制IAST Agent进容器
ADD iast\_agent.jar /tmp/iast\_agent.jar
#可以设置tomcat调优，并发数等，或修改tomcat端口号，然后替换掉容器内部的server.xml文件即可
#ADD server.xml conf/server.xml
#使用上海时区
RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
#启动javaagent
ENV JAVA\_OPTS="$JAVA\_OPTS -javaagent:/tmp/iast\_agent.jar"
#启动命令，默认也是这个，可以不写
CMD \["catalina.sh","run"\]
最后流水线通过自动化发包工具将被测系统中的数据内容都触发一遍，完成整体流程。并通过钉钉将漏洞数量来上报给测试人员。