2021可信云大会软件安全论坛现场
软件开发的安全痛点
一、开发人员对安全工作的误解
开发人员对安全人员常常有一些偏见，曾经有个大厂开发吐槽他们的安全部门的人不切实际，他们经常强调安全的重要性和漏洞的严重性，但又不能帮开发们解决任何问题，只是一味的“说教”。
同时，又喜欢把小问题极度放大，让开发不停的改漏洞，而这些漏洞在开发眼里危害很低甚至没有危害，不值得修复。从漏洞和风险来看，问题不是来自安全人员，而是来自开发、运维、测试甚至是业务等角色的人。
二、安全人员做开发安全的误区
从安全人员自身角度来看，他们很多人都是做渗透测试、漏洞挖掘等出身，在他们看来，开发人员能写出来漏洞是很愚蠢的行为，但将心比心的讲，实际上在安全公司做开发写出来的程序也有很多漏洞，在开发阶段出现漏洞是难以避免的，正如去年某安全大厂爆出的漏洞影响范围非常大。
如果安全人员太过专注漏洞本身，有解决漏洞的一技之长，往往让自己感觉自我良好，但事实上并非如此，尤其是在甲方，如果只靠一技之长，并不能解决企业所有的安全问题。
所以开发人员和安全人员有思维逻辑上的矛盾，这也是软件开发安全难以打破的屏障。
三、SDL 落地难
从微软提出 SDL 到 DevOps 再到 DevSecOps ，目的是把包括安全在内的很多事情前置化。我们曾经把软件工程挂在嘴边，但后面发现软件开发根本不是个工程问题，因为它不能把所有的事情都标准化。就像产品经理提出需求，开发人员实现需求，实现的方法有很多，产品经理并无法确认实现是否与需求完全一致。
简单总结一下 SDL 落地难的原因：
1. 人微言轻：因为无法将安全运营工作深入到开发过程，对业务相关性不大，安全部门的人往往被边缘化，说话没有什么话语权。
2. 艺高胆大：安全人员觉得自己技术好，可以解决企业的安全问题。
3. 不谙世事：安全人员在安全运营方向做得不够深入，其他部门无法配合安全人员的工作。
4. 按部就班：安全工作并不能按部就班，因为安全是人和人对抗的工作，所以无法完全照搬其他公司的方法。
5. 举步维艰：正因为上述原因，SDL 很难跨出第一步，哪怕是 SDL 第一步做培训，也有很大阻力。有人会问，“为什么要参加安全培训，这和我有什么关系”。
IAST 技术浅析IAST 是一个在应用和 API 中自动化识别和诊断软件漏洞的技术。通过插桩技术(Instrumented)，实现对目标应用程序在运行时的安全信息收集，从运行的代码中发现代码安全及逻辑问题，提供实时的报警展示。在整个软件开发生命周期中，可以开发与测试阶段中使用 IAST 工具。
IAST 的应用场景
第一种场景，在安全开发生命周期的全过程中，有安全培训、需求、设计、开发、测试、部署/运维、流程与管理各个阶段，以业务安全和信息安全为出发点，对上述各阶段提出安全要求，在开发、测试阶段，会使用到 IAST。
第二种场景，在整个 DevSecOps 流程中，落地的关键是：缩短调度成本，提高自动化效率。归根到底是提高工具链的自动化支撑能力，IAST工具因其低侵入性，实时检测出结果，漏洞准确率高、误报率低等特性，被认为是最佳测试工具。
第三种场景，敏捷开发、快速迭代开发模式中，设计、开发、测试、部署等各环节都在快速推进中，而软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。IAST 工具适用开发、测试阶段，且不需要安全专家投入，普通开发、测试人员就能使用，特别适合用于软件安全测试，提高软件安全质量。
IAST 的技术原理
IAST 的实现模式较多，常见的有代理模式、VPN、流量镜像、插桩模式，最具代表性的是代理模式和插桩模式：
1. 代理模式：拦截请求和响应信息，通过代理拿到功能测试的流量，利用功能测试流量模拟多种漏洞检测方式对被测服务器进行安全测试。
代理模式基本原理是对请求或响应进行拦截/过滤处理，来达到应用保护的目的，我们可以称之为应用层 WAF 的类似产品，此种类型的产品严格意义上来说，不能称之为 IAST 产品。这里以 Java 语言为例，介绍 IAST 代理模式实现原理：
Java Web 的 MVC 框架主要为 Spring、Struts1。x、Struts2，而 Java Web程序的运行都依赖于 Servlet 容器，故 Spring、Struts1。x、Struts2 三大框架中，都遵循 Servlet 规范实现了自己的 Filter；同时，利用 Java 的反射机制，也可以实现拦截器。它们都可以通过流量监控的形式，完成应用层的安全防护。
代理模式无法做到对应用程序中某个代码段或某个函数的行为做精准的安全防护从而导致误报，这是它的缺点。但因为此类技术比较成熟，故市场上仍有不少此类技术的产品。
2. 插桩模式：插桩模式是在保证目标程序原有逻辑完整的情况下，在特定的位置插入探针，在应用程序运行时，通过探针获取请求、代码数据流、代码控制流等，基于请求、代码、数据流、控制流综合分析判断漏洞。
插桩模式也是本次 IAST 最佳实践使用的部署模式，IAST 插桩其实就是基于 Hook 的思路，从这层意思上说，拦截器也算是 Hook 的一种形态，只是我们在这里讨论的是如何基于运行环境做更底层的 Hook。插桩 Hook 的方式是目前市场上的主流 IAST 技术实现手段。
下图所示展示了 Java 基本原理，Java 程序从编码到运行主要分编译、字节码加载前、字节码加载后三个阶段，其中后两个阶段都在运行期。
Java 基本原理
IAST 技术的局限性
IAST 技术的局限性
语言的局限：不同的语言、不同的框架会影响到漏洞的测试情况。
性能的局限：性能要求10%，但相比 RASP，我们可以不把分析和处理都放进探针端完成，因为这点会对性能产生极大的影响。
环境的局限：不同的部署环境有不同情况发生，测试环境和实际生产环境会有差异。
部署成本的局限：在复杂的部署环境下，如果加上探针会对产品产生负面影响，负面影响会让其他职能部门认为 IAST 产品有问题，甚至对安全工作产生不信任。
对于 IAST 产品来说，最重要的其实并不是漏洞检测能力，而是它和 DevOps 或者 DevSecOps 的集成能力。因为如果不具备这种能力的话，对于安全部门而言与黑盒、白盒工具无异，IAST 产品的优势会大打折扣。
如果能很好的集成的话，首先能够解决掉安全工作中很多沟通的成本、同步信息的成本、安全推广的成本，基于这点探针对性能的影响才能被大家所接受。
