总结：

话题1、中国出口信用保险公司在软件供应链安全方面的探索

　　崔志铭：我是2021年那会知道软件供应链安全这个概念，当时是因为上级主管部门下文让我们清查自己的供应链。我当时甚至不了解供应链是什么东西，包括他规定的范围或者说都包含什么东西。后来他又给我们下了个清单，让我们去清查这些东西。清单上有关于组织架构、流程、漏洞管理、研发人员安全管理等等。我一看这个清单，这不就是我们之前搞那个SDL那些东西么？然后我拿着清单去对照原来最初1.0版的SDL，发现有一些对应软件供应链安全要求的点。

　　我们那个软件研发安全体系大概是17年开始建设，21年软件供应链安全这个概念开始被聚焦。然后基于我们原来的体系，把在软件研发各个阶段设计的规范、软件供应链安全的自动化工具、安全能力进行了一些补充，现在也形成了自己的软件供应链安全体系。

　　徐锋：实际上软件供应链这个概念也是因为近两年相应的安全事件爆出来以后，大家才开始关注和重视，之前基本上没有特别明确的概念。那其实国外当时有相应的法案，特别是美国，当时那个法续要求供应商、政府机构的采用方等去响应法案的要求。再加上一些太阳风、乌克兰的这些事件发生以后，出现软件供应链中断、开源许可风险等威胁，发现原来软件供应链是如此之重要。

　　李少鹏：原来的话应该是更关注安全开发、漏洞威胁之类的吧

　　徐锋：是的。现在更多地是在关注整个软件供应链的一个平稳、持续，还有软件自身的安全问题。刚刚崔老师提到的他们通过安全开发体系建设来解决软件自身的一些安全问题，其实这个就是软件供应链要做的其中一个重要的工作。

话题2、IAST在用户侧应用的现状和技术趋势

　　李少鹏：今天的主题讲的就是解构CAS之IAST,我们希望仔仔细细的把IAST这个软件安全测试的技术剖析清楚。我想了解徐锋作为国内比较早接触这类技术的资深技术人，如何分析IAST的应用的现状以及优劣势？

　　徐锋：这里我想先说一下的技术背景。IAST出现一开始是为了填补白/黑盒使用的劣势场景，包括检测效率低、误报率太多，安全威胁报告出来却没有足够的人员去及时处理等问题。

　　李少鹏：那为什么现在白盒还是采用选购最广的？

　　徐锋：这个主要是由于国家相关的标准要求，要求代码审计、合规的这些东西。这方面呢，白盒有很多优势，例如它可以更加透明的去分析。另外，我认为每一种工具的推出，都是满足不同场景的需求，并不是说一定优于什么别的工具。

　　话题回到IAST。IAST的特色技术就是动态污点分析技术，这个技术赋予了IAST区别于传统漏洞扫描技术的优势。这里需要对污点分析的原理进行简单科普，第一种情况，例如我们日常使用的登录功能，需要输入一些数据信息后点击登录，我们把这些外部输入认为是不可信的，即只要跟外部输入的这些信息我们都认为是危险。然后我们要去跟踪这些数据，监控它是怎么去传播的，这个时候就要在每一个中转的路径上去埋桩。第二种情况，程序员在编写函数的时候没有对输入进行相应的格式或者安全控制、没有校验，这个时候外部危险数据可能会在程序内部传播，从而导致产生漏洞，我们一般称之为风险函数。

　　那动态污点分析的优点就凸显出来了。就是不对原始程序有任何干扰的情况下，监控外部输入的数据。通过正常的功能测试完成安全测试。还有一个优势是不产生脏数据，因为插桩相当于监听，不会对源代码的逻辑产生影响。另外，IAST还能兼顾加密环境、一次性资源、微服务架构这些场景的漏洞测试。总结下来就是在覆盖率和误报率、时间效率等方面拥有领先的优势。

　　劣势方面，IAST的部署跟开发框架有关，不算是编程语言通用型技术，因此存在一定开发成本。另外对应用的性能存在一定的性能损耗。

　　李少鹏：崔工，你作为IAST的用户，如何看待关于徐总介绍的IAST的优缺、使用的场景和原理这个方面。

　　崔志铭：关于系统运行速度的影响，其实在测试环境中我们感觉还是微乎其微的。

　　后台运维人员把那个插桩给部署上以后，其实对研发测试他们的没什么影响，几乎就无感。部署上以后，可以直接在后控制台获取漏洞信息。另外我也认为，整个软件供应链安全工具链中的每一个工具他都是扮演自己的角色，我们取之长处应对安全需求场景即可。

话题3、CAS思想与方案在真实生产环境中能否提升安全效能？

　　李少鹏：我们整个的开发环境越来越复杂，大家用的各种工具、各种品牌也挺多，那自然就会面临一个统一管理的问题，所以统一管理是我们CAS理念的一个原始的起因。那除了统一管理，工具之间还应该联动，例如这个工具什么东西已经检测出漏洞，然后别的工具重新做一遍检测。为什么不把它的结果打通给了别的工具呢？当时是出于这两种原因，生成了CAS这样的持续应用安全方案。

　　崔志铭：我之前大概了解了CAS的概念内核，我把它理解为研发安全这块，整合安全工具的一种解决方案，里面包括白盒、黑盒、IAST等等。

　　徐锋：其实就像刚刚提到的，例如白盒扫出来一堆漏洞，然后IAST又扫出来一堆漏洞，这个时候运维成本翻倍，对于用户来讲工具购买成本也被迫提升。类似于这些出现冗余数据的场景，就需要CAS来满足信息贯通、高效利用的需求。比如说一个漏洞的统一分析，包括根据严重程度为漏洞修复定优先级。再比如白盒或者黑盒报出来的漏洞能不能通过IAST的再去验证一下，确定漏洞是不是在同一个位置等，这样验证出来的漏洞精确度是非常高的。

　　第二点，我觉得CAS可以实现不同工具之间调度跟联动。特别是像DevOps环境里面对接的工具有非常多，那么如果通过将CAS包含的测试工具做统一的接口，然后与DevOps平台做一对一的对接就可以实现工具调度和联动。

　　第三点，关于IAST与RASP(应用运行时安全防护)的联动也会非常具有落地意义。例如在IAST测试里面的收集到的一些数据,其实到线上的时候这些数据是非常宝贵的一些资源。我们程序员可以提前把某个漏洞修复，同时可以通过这些数据加强在RASP的防护算法，也就是避免遭受这个漏洞的危害。还有一种情况是IAST检测出来了一些漏洞，而RASP目前拥有防御这些漏洞的能力，这个时候研发团队就可以暂缓漏洞修复工作，优先考虑上线效率。

　　第四点，像SCA(开源组件安全分析)扫描出来的风险组件，可能现在被利用的可能性很小，但是保不准什么时候出现问题。这个时候我们加载有相应防御能力的RASP，就可以做一些提前的预知。

　　总体来说，是CAS思想与方案在真实生产环境中是能够提供信息共享、工具联动、统一管理等优势，这恰好是用方在软件供应链安全力开发安全这块最紧迫的需求痛点，也是帮助他们提升安全效能的有效途径。

参考阅读
网安三人行：XDR离我们还有多远？
网安三人行，把酒话XDR
“网安三人行-创业企业投融资那些事儿”谈话实录
“网安三人行”干货盘点：软件供应链安全的那些事儿