数字时代传统安全理念应对复杂威胁显得滞后，企业需要围绕发展目标建设安全新范式。为此，腾讯安全联合IDC发布了数字安全免疫力模型框架，以免疫的视角助力企业兼顾安全建设与企业发展企业建设免疫力。
框架中，底层围绕数据安全治理和业务风险控制，设置了防御纵深，以保护企业两大关键生产要素。第二层也是整个体系的中枢，它以人为核心，贯穿企业战略、组织流程等全部运营模块，各个系统之间高效合作，是保障企业长期、健康、稳定的运行，实现风险可控的基础。
通过构建边界安全、端点安全、应用开发安全，牢固基础屏障，能在对外部攻击进行控制和阻断的同时，对内部实现动态化防御，以确保端点及应用开发安全性。数字安全免疫力模型强调前置投入，其将安全要素融入各个环节，从战略组织与人才层面、技术层面、流程和运营层面破局，帮助企业提高韧性，抵御未知风险。
而在9月22日下午，为了更好地将此框架展现给众人，腾讯联合安在新媒体推出线上直播，以此作为腾讯安全先行者系列活动之一。此次直播由易宝支付信息安全总监郭东升，腾讯开发安全产品规划负责人刘天勇共同分享，他们分别从甲乙两方的角度，通过在软件供应链安全上的具体实践，为我们解读了数字安全免疫力模型框架的重要性。本次直播的主持人为安在新媒体创始人张耀疆。
特别鸣谢：直播期间，感谢观众对于直播内容做了完整的梳理笔记，对照笔记中的几处重点逻辑，我们也重新进行了更详细的内容梳理和扩充，下文会将更为完整的解读呈现出来。
软件供应链安全到底是老问题还是新问题？
张耀疆：软件供应链安全的概念非常多，五花八门，因此总会给人产生一种疑惑，我们关注的到底是一个老问题还是新问题？像业内专家提出的那样，安全这条道路上，可以用老技术解决老问题、用新技术解决老问题用、老技术解决新问题、用新技术解决新问题，所有的创新都会在这四个象限之中，那软件供应链安全又属于哪一象限？
刘天勇：SDL、DevSecOps再到软件供应链安全，这三个名词的演进，代表着软件供应链安全从老问题发展为了新问题。SDL的中文意思是软件生命周期的安全，其更多解决的问题是，在传统的软件开发环节，把安全检测融入进去，做一个相对来讲更偏第三方的检测。
而从SDL到DevSecOps，其实象征着软件供应链安全从老问题变成了新问题，因为研发模式变了。相当于研发模式从原来的瀑布式开发变成了流水线开发，变成了DevOps开发，所以以前SDL理念对应的问题就变成了DevOps对应的新问题，而为了解决新问题，于是有了DevSecOps。研发模式带来的新问题，有流水线的集成效果，集成之后的落地方案，以及对于整个流水线效率的影响和安全效果之间的平衡。
软件供应链安全和DevSecOps，更像是一个大问题的两个维度。DevSecOps是从甲方的研发视角入手，和研发模式挂钩。而软件供应链安全，是站在一个更宏观的视角来看待所有供应链上的问题，包括第三方开源组件会带来的风险。所以说软件安全这个概念相当于是一个新的问题。
以上是四象限的横轴，在坐标的纵轴上，还有SST、DAST、AST、RASP这些技术，除了RASP外，其他很多技术早已被gartner提出。而腾讯安全在技术领域，尤其是SAST和SC这两个技术方向上，都做了相应的创新，是面向DevSecOps理念而做成的新一代SAST和SC技术，所以从四象限来看，确实是新技术解决新问题，同时这个技术本身也能解决老问题。
对甲方来说，如何看待软件供应链安全？
张耀疆：从用户的角度来看，在实践的时候，需要这么明显的区分断代吗？还是可以无所谓各种概念？
郭东升：甲方做体系化建设时，主要还是根据需求出发。业内的这些名词和解释，做的是一个具象化的定义，其落到甲方带来的是能力的增长。而甲方更关注的是痛点，即“能不能解决问题”，这是最重要的。
比如早期安全人员会采用一些黑盒扫描器，在上线前对产品做一些测试和扫描，最终在上线之前推动漏洞的修复。而这个过程成本很高，因为代码已经开发完毕，如果测出漏洞就会耽误产品上线的时间，因此安全部门常会和业务部门在上线前后起冲突，这也就导致了甲方的安全工作很难推动。这是第一阶段。
随着产品的开发方式变化之后，这种模式已经不适用于甲方的安全工作了，这时甲方的扫描工具会基于规则，像灰盒检测等。但这也产生了新的问题，比如误报率比较高。像第一代的白盒扫描工具，误报率可达70、80以上，这就导致安全部门需要安排大量人员去排除这种误报，人员不够，反过来就是增加开发的工作量，而开发部门则会认为安全部门的能力是不够的，便不会愿意配合修复漏洞，这是恶性循环。
因此对甲方而言，其所要求的安全工具不能只基于一种规则，而是要基于比如动态的静态扫描，比如解析器能够覆盖大量的语言脚本，然后能帮助甲方更准确的发现漏洞，同时要能提高发现效率。就像如果有工具能在整个代码仓库里，对一些增量代码做一个快速、全量的识别，这样就可以大大减轻甲方安全人员的工作时间，甲方安全人员因此可以聚焦在某些告警出来的问题上。
不同的发展阶段，安全人员的管理职能有何变化？
张耀疆：不同的发展阶段，安全角色的职责也发生了改变，从最初的独揽安全大权，到现在，往往会需要其他部门的配合，那在此过程中，安全人员在管理职能、治理方式上有着怎样的变化？
郭东升：首先，工作模式的变化带来了工作量的增多。早期，安全人员通过挖漏洞、渗透测试和黑盒扫描，在产生相应的报告后，可直接给到开发人员做修复。这种方式的漏洞检出率比较高，但因为基于的个人经验，其局限性也比较强。所以之后通过白盒审计的方式，安全人员可把整个代码参数，全量的、增量的都通过相应的形式过一遍，这样就能够覆盖完整，安全上也不会有遗漏。而带来的工作量增加，就需要和组件部门或开发人员做一些前期的安全培训，以及安全漏洞修复工作，这个过程会变成安全运营人员一项重要的工作。
刘天勇：DevSecOps有一个非常重要的指导原则和理念，叫做人人对安全负责。在践行这个理念时，会把安全任务和安全责任，从单纯的只让SDL团队负责，变成让整个业务一起来为这部分内容负责。而在这个角色的变化过程中，有几个特别明显的点，第一是身份的变化。在以前的逻辑下，安全SDL团队的定位更像第三方审计，而在现在的DevSecOps框架之下，其更多变成了安全能力的提供方，而安全能力的使用方变成了业务本身。
第二是角色的变化。以前角色比较简单，可能就是开发和安全两个角色，而在DevSecOps里，可能还有第三、第四个角色，就是除了安全和开发外，还有运维和研效（研发效能）。研效团队负责整个公司企业内部DevOps平台建设，因此人员角色分配上，就变成了由安全团队提供能力和工具，由研效团队实现集成和耦合，以及整个链条的打通，再由真正的业务团队、开发团队来进行实际的使用，使用之后的结果，再回到安全团队来进行修复的指导。整个安全团队会把更多的重心放在运营角度、度量角度，而不是纯检测的维度。
数字安全免疫力具体是什么概念和状态？
张耀疆：数字安全的免疫力不是简单的工具和产品，不是在某个环节就能够实现的，因此它的概念是围绕体系化建设要有一个平台级的整合，需要不同部门共同来协作，还是单纯的只是各个产品的组合？
刘天勇：在公认的DevSecOps理念方法论上，会拆成三个维度。第一个维度叫技术工具，第二个维度叫组织架构，第三个维度叫流程制度，三个维度要三管齐下，才能真正去落地实践。技术工具方面，安全团队是所有方，安全人员需要把工具放到大的开发平台里，并基于工具设置相关的基线、相关的流程制度，以及一些管理上的要求。
流程制度方面，包括了制定公司的安全代码规范，包括内部和研发团队共同形成的公司的某个语言框架使用规范，包括基于外部开源框架来形成的公司内部的二开框架，还有编码规范，以及人员的培训和考试，当然也会包括一些在流水线中的阻断判断。
组织架构方面，需要不同的团队围绕DevSecOps平台共同协作。腾讯内部，各部门会共同依托于整个大的平台，把安全作为一个柔和的、嵌入自动化的集成。因此对于开发来讲，并不会有很强的任务感受，觉得安全部门又在捣腾新标准了，而是相当于在原有的使用场景之下，加入了一些柔和嵌入的环节，这样大家的分工就会清晰很多。研效团队负责平台运营，安全团队负责安全工具的运营，等等。
对甲方来说，软件开发安全是怎样运作的？
张耀疆：软件开发是安全人员的日常工作，在具体实践中，甲方用户平时会怎么去做？有没有可扩展的地方？
郭东升：在具体落地过程中，每一家公司的体量、企业文化、发展阶段、研发团队的成熟度，决定了最终会如何落地。安全属于后端部门，和中台和前场的联动时，需要提供安全能力的展示，通过对其他部门的服务，来改变众人对安全的认识。
如何让其他部门感受到安全服务的价值？这就需要安全部门在前期提供很多的能力，比如真正把工具落地到企业内部，能让研发团队使用起来，这需要安全部门结合很多攻击事件、漏洞发生的概率，包括能够提高产品代码质量的能力，以此来影响研发人员对安全的重视。
安全人员要以技术高地的立场要求自己，要能提供真正有价值的东西，而不是基于合规压力或者基于需要体系化的建设，才去买什么工具，不然最终在落地之后，往往会把安全在整个技术团队里的形象拉低。只有通过重要的安全事件推动，来影响高层对安全团队的支持，同时提供真正的能力，让产品研发团队能够切实感受到在安全人员的帮助之下，把他们的代码，比方从100个漏洞变为了10个漏洞，这才是甲方能把工具和制度流程真正落下来的一个关键因素。
软件供应链安全中一些痛点和经验
张耀疆：DevSecOps运作过程中，或说软件安全工作中，会有不少曾经踩过的坑和疑难杂症，印象最深刻的有哪些？
郭东升：产品上线之前，安全部门会对一些小功能做一些抽查，在这个过程就会遇到一些问题。比如一些创新产品项目在立项过程中，在其第二次大版本的更新时，只走了老的流程，就是只做了小版本的流程申请，而这对安全部门来说，是一个比较大的代码更新，因此安全部门就需要对其做一些覆盖，而这个过程中，只使用过去的安全工具，效率会比较低，从扫描到复测，到最终上线，这一整个流程时间非常长，其周期已远远大于了它上线的节奏，而这却是个不可调和的矛盾。
在使用了新的工具后，安全人员可以给开发人员的开发工具设置插件，或者给开发人员做培训，但其中也会牵扯到一些问题。开发人员是流动的，他们不会在公司一直持续不停的工作，因此在流动过程中，安全能力就无法覆盖到新的人员，即使安全部门可以对新员工进行一些培训，但培训的效果，新员工的接受程度在他工作中能体现多少，这是一个不可控的变量。
所以，甲方需要一个强有力的抓手，这个抓手要高效，要准确，要能够在安全部门做完所有的流程和培训之后，也能够让安全自主的去发现这些漏洞。而这就对工具能力提了更高的要求，不是让工具基于规则引擎，而是基于一些新的解析器，或者其他新的开发方式，其最终目的是能够为开发安全提质、提效，降低安全部门的运营成本，降低安全部门整个的修复周期，这是目前而言甲方最关心的一个痛点。
腾讯相关产品如何？
郭东升：腾讯产品和传统的代码审计工具不一样，其能通过扫描引擎快速的覆盖整个代码仓库，包括增量代码，这就大大提高了检出效率。其次，产品对一些常见主流框架的支持度较高，可以覆盖不同商业化的产品和第三方的引入制品，对安全短板的覆盖比较好。第三，产品对常见的漏洞支持比较好，比如top ten的这些漏洞，其基于污点分析技术，对漏洞检出率会比较准确。具体例子，比如原来做20万行代码扫描需要大概几个小时，现在能提高到20秒左右。
刘天勇：腾讯开发的Xcheck产品，在做整个白盒代码安全审计的时候，采用了全新的技术路线。过去腾讯作为甲方的时候，也采购过市面上一些知名的SAST产品，结果发现这些传统品牌在流水线场景，在DevOps平台上的集成效果不太好，因为它的速度过慢，严重影响了迭代的效率，同时误报很高，让安全团队没有办法真正的践行DevSecOps。
所以，腾讯自研的这套全新一代技术原理产品，就是在这样的背景下诞生的。首先，其具备自研的模糊解析器技术，可以在完全无需编译的情况下，直接进行整个代码的解析，因此在这个逻辑之下，其对于扫描速度的提升是非常明显的，以及在解析之后，产品的漏洞检测也不再基于传统的规则匹配（规则越多，扫描的时间会呈线性增长），而是用了一套模拟执行的算法，模糊解析器加模拟执行算法，两套方式互相叠加，因此就使得扫描速度有了极大的提高。
此外，接近五年的时间，整个模拟执行的算法被每天几十万个任务不停的千锤百炼，如此打磨，可说每一个漏洞都是实锤，将漏洞交到开发手中，他们看到结果之后也就省去了再次沟通的时间成本，下个环节如何修复一目了然，同时在流水线的过程中，其能够将误报控制在一个极致的水平，对开发的接受度会更高，也更友好，因此也就更有助于落地。
产品在误报方面有着怎样的优势？
郭东升：首先技术路线是在持续增长的，因此没有办法断定其能够百分之百的排除误报，但是基于之前的产品已经有了非常大的提升，而且是可运营的。可运营的意思是，在安全部门投入了少量的人力后，可以快速的对这些漏洞做研判，最终形成真实的漏洞报告，然后给到产品研发侧去“推修”（推动开发人员修复漏洞的简称）。目前腾讯的产品对甲方用户而言，只需要两到三个人就能运行，从投入上看，其效率非常可观，整个产出也很让人满意。
产品对人员有着怎样的要求？
张耀疆：软件开发安全是技术活，其对人员的要求具体有哪些？
郭东升：要求会比传统的测试人员高一些。首先其要求相关人员不仅能做渗透测试，还要懂整个软件代码的安全编码规范，要能够对一些常见的漏洞成因有所了解，以及需要具备开发能力、安全能力，同时还要具备一些漏洞的演示讲解能力。
张耀疆：如此看来，对用户端使用人员的要求还是挺高的，这样会不会造成一种现象？就是产品虽好，但不一定有适合的用户具备足够专业的人员，因此导致产品的普及率不高？
刘天勇：对大部分公司而言，其分为两种情况，一种是具备专业的人员，但人员精力有限，因此产品的作用是把专业人员的人效发挥出来，比如公司业务、代码量、应用的版本数量都是持续增长的，难道安全检测人员也要配套增长吗？这不现实，所以对于很多公司来讲，目的是要把整个检测的效率提高，把整个误报控制在更低的水平，然后才能提高人效。
第二种情况，有些企业的开发安全并未到达一定的阶段，比如处在从零到一的建设阶段，他们往往没有自己的开发安全，所以针对这些从零到一的用户，腾讯产品拥有和自身配套的技术服务，相当于工具+服务，也就是说这些企业每次做检测和扫描时，不会像单独买一次渗透测试或者买一次代码审计一样，需要过高的成本，因为腾讯产品本身可以无限次扫描，而配套的服务能力可以帮助用户做整体的落地、运营和维护。
就目前而言，产品还有哪些问题亟待解决？
郭东升：首先，一个基础的认知，没有百分之百的安全。腾讯工具比起过去的代码审计产品已经有了非常大的进步，如果非要提一些建议的话，可能需要从识别框架自身的安全机制入手。很多现有的框架，其自身具备一些安全能力，比如某场景里，框架做了一些参数的拼接，这个参数拼接是一个高危动作，但它过了框架本身的安全审核机制，最终拼接完之后，不一定具备注入或命令执行，但是在白盒审计工具的识别过程中，安全人员可能会对这个动作打标签，但是最终在安全人员研判的时候，会发现其可能也不一定有风险，或者说有一定的风险，但可能并不会造成漏洞。类似于这样的情况，需要产品做进一步提升。
刘天勇：郭总提到的这个场景我们称为防护识别，这是一个问题，比如框架自身的一些特性会带来一种防护逻辑，而默认的规则引擎很难去识别这种逻辑，如果勉强识别，很有可能会带来漏网，相当于识别的不准，所以防护识别确实是整个技术的一个难点，也是腾讯目前在处理的一件事。
当前针对防护识别，更推荐的方式是通过自定义来解决，因为整个防护的概念和逻辑一定不是无限发散的，比如公司用的框架就那几个，这几个框架的特性做了适配之后，一定是逐渐收敛掉的。或者说公司整个的防护逻辑就那么几种，因此只要自定义能力足够强大，就能够收敛这个问题。
所以腾讯把整个研发的重心放在了自定义能力的开放性，以及自定义能力的覆盖度上，这也是今年腾讯产品一个很大的迭代能力。此次新的自定义能力，可以用低代码的方式去编写，意味着成本降低了，另外，在这个自定义的能力之上，对于原生底层引擎的能力开放会变高，所以更复杂的框架适配，更复杂的防护逻辑都能够通过自定义方式来解决。
未来软件开发安全会有怎样的趋势？
郭东升：我们知道，人员的成长需要时间和精力，就国内趋势而言，高端信息安全人才一直处于紧缺状态，而人才不会无限增多，从整个招聘市场可以看到，招聘中高端安全人员的周期会变长，同时企业配备的人员投入也不会无限增多，因此还是希望乙方能够把工具的门槛做得更低，准确度做得更高，误报率更小，给甲方带来更多的便捷。
甲方安全不仅有开发安全，还有应用层、逻辑层、网络流量层，以及数据安全，所以甲方要做的工作非常多，会依赖于市场上一些标准化的安全能力和产品，因此希望乙方能够更好、更快地去迭代一些能力，让甲方能够更好地运作起来。
刘天勇：可以从几个点来展望。第一，从技术本身而言，性能、效果等，一定会持续优化，同时我们在技术上还有一个比较新的变量，就是腾讯的大模型技术。我们会把大模型的这套代码理解能力放到整个修复的指导当中，以形成“智能审计助理”的能力，这在后续会推出。
短期内，靠大模型技术扫漏洞还不现实，但是漏洞扫完之后，它能够帮助开发人员提效。比如开发人员的安全修复素质不那么强，一个智能的AI审计助理能够通过对话的方式，帮助开发人员一步一步地提高修复速度，或用这种方法提供更针对性的修复建议，这是技术上的一些畅想。
理念方面，大家会面临一个共性的问题，就是不同的工具太多了，因此集约化是发展趋势。比如像SCA，它是开源组件的一个检测，它和第三方开源组件的检测，和自研代码的检测就是一个应用的两部分，因此这两块儿能合到一起，不同的检测技术都是在解决同一个问题，只是技术路线不一样，因此完全可以趋向于一体化的集成。
当下，腾讯Xcheck产品已经包含了SAST的能力、SCA的能力，以及二进制制品扫描的能力，在整体的使用上，相当于已经做到了三合一，未来还会具备更多的合一。接下去的趋势里，all in one是大家共同的目标，安全工具的提供方，会把更多的工具和平台进行更紧密的结合。
面向安全研究者、白帽子等个人用户，腾讯 XCheck提供免费的saas体验版本，SAST和二进制SCA的能力可以直接登录下面的地址体验：
https://xcheck.tencent.com
https://www.binaryai.net
面向企业用户，欢迎直接联系我们，会有专门的商务和技术支持同事来提供免费的poc 测试。