8月10日，由悬镜安全主办、以"开源的力量"为主题的DSS 2023数字供应链安全大会在北京·国家会议中心隆重召开。蚂蚁集团网络安全副总经理程岩出席并发表了《蚂蚁集团软件供应链安全实践》主题演讲。
图1 蚂蚁集团网络安全副总经理程岩发表主题演讲
以下为演讲实录：
尊敬的各位领导，各位嘉宾，谢谢子芽给我们这样的宝贵机会来分享蚂蚁集团在软件供应链安全方面的实践。我叫程岩，花名"小哥"。这次我的主题分享会从四个方面展开。
一、软件供应链面临的风险与挑战
供应链面临哪些威胁？第一是代码漏洞，第二是供应链恶意投毒，第三是合规断供问题，这次重点讲前两者。代码漏洞和恶意投毒的问题犹如冰山，已经被曝露的漏洞或事件只是海面上的冰山一角，冰山之下还有多少？没有人能准确回答。同样为什么供应链安全话题如此火热和被大家所重视，也是因为这类威胁的攻击门槛低、攻击方式隐蔽、影响范围大而且危害大。
为了确保供应链安全风险可控，我们会面临怎样的挑战？
第一个挑战，生产源头不可控。无论我们自己的安全意识如何，任何一家企业、院校、监管单位、安全机构都无法百分之百保证开源软件的安全性。
第二个挑战，稳定性不可靠。由于生产源头不可控，而且开源是非常开放的形式，无法保证开发的软件新版本包括国内外其他开源软件百分之百向下兼容。
第三个挑战，复杂的实际场景。不同的应用对同一个组件的调用方法、传入参数是否外部可控等复杂多样，当爆发漏洞时，难以确定风险的真实影响面，无法确定真正需升级的应用系统，只能选择伤筋动骨地按版本号一刀切式的全部升级。
第四个挑战，爆炸式的依赖。直接依赖、间接依赖和次间接依赖的存在，导致某一组件爆发漏洞，往往随之引发放大效应，波及范围广，且非常隐秘。
上述风险和挑战的存在，使得不管是企业还是整个国家层面，对于供应链安全建设的要求和期待，不仅要面向合规，更要面向实战。
二、集团软件供应链安全目标思考
在如此严峻的安全形势下，面对众多不可控的情况和混沌状态，思考金融类企业安全建设前首先需要先明确安全目标，以终为始，确定安全建设终态的效果是什么。蚂蚁集团对供应链安全建设的终态分为两个方向：
2.1 让安全满意
先找准服务对象，即让安全满意，没有安全就没有用户放心把钱交给金融类企业。如何"让安全满意"，我们认为有四个方向或者称四种状态：
第一，第一时间获悉投毒、漏洞、断供、合规等方面的情报，并且在真正的攻击来临之前快速有效止血。
第二，止血只能解决当下问题，不能解决长期问题，对于高安全型企业而言，要求止血更要求彻底修复。与此同时，看不见、灯下黑、没人养的系统所存在的安全问题也能得到解决。
第三，已知问题不再重复发生。从实践来看，大多数企业往往在开发过程中仍会引入过去使用过且存在风险的镜像或者组件，大部分安全人员也并不清楚哪些组件是较为安全的。问题解决是可喜的，但相同问题再次出现，可能意味着"老树开新花"，存在巨大风险。
第四，无惧未知攻击。当0Day漏洞爆发时可以快速响应和修复，甚至做到提前免疫。
2.2 让业务爽
安全不能只是在管理和指挥业务。在一家企业里，如果业务出现问题无法发展，安全就没有生存余地，安全目的其实是帮助业务成功，让业务安全稳定地发展壮大。所以当安全的核心诉求得到一定满足以后，接下来要思考的问题是如何让业务满意或者让业务爽。怎么理解"爽"？有以下几点：
- 安全要给业务足够长的修复时间。业务不希望熬夜加班来修复漏洞，此外，因为金融系统较为复杂，一旦出现问题会影响支付行为，需要较长的修复发布时间。
- 安全要让业务低成本完成修复升级发布。发布工作要经历非常重要和稳定的周期，尤其是非常关键核心系统，往往需要2-3天才能保证全链路无损发布。如果每次漏洞修复要投入2-3天的时间精力，这对于业务而言，修复成本是不可理解的。
- 安全要帮助修复。研发往往会有诉求，希望安全帮助修复他代码中存在的漏洞。
- 安全要保姆式推荐。业务往往希望安全能如保姆一般在旁指导，在开发过程中就推荐或者直接帮助选择安全版本的组件。
图2 程岩分享蚂蚁集团的供应链安全实践经验和成果
三、蚂蚁集团软件供应链安全体系发展
为了达到上述终态效果，蚂蚁经历了三个阶段来推进相关建设。
1.0阶段：十万火急
基于我多年来在甲方工作的经历，我发现每个甲方在遇到安全问题时都认为是十万火急的。在这个阶段，我们将安全活动分为应急态、研发态、运营态。
应急态包含止血策略WAF、排查策略SAST和DAST以及修复策略手工修复和紧急发布。
研发态&运行态是为了防止0Day复现，包含利用SAST和DAST工具进行巡检查漏补缺以及通过SAST和IAST工具进行安全卡点避免再犯。
图3 蚂蚁集团软件供应链安全体系建设1.0阶段
2.0阶段：游刃有余
1.0阶段必然无法实现"让安全满意""让业务爽"的效果，所以我们进入2.0阶段：让安全和研发可以放心、不着急地将安全漏洞解决，所以称为"游刃有余"。在这个阶段，我们同样将安全活动分为应急态、研发态、运营态。
相较于1.0阶段，2.0阶段的应急态补充了大量工作，比如在止血策略中补充了RASP和miniRASP，其中miniRASP是针对短期运行的计算任务所采取的轻量级注入方式；同时在排查策略中补充了SCA，用于梳理间接依赖和链路画像。我们认为只有支持间接依赖检测的SCA才是真正的SCA。所以1.0阶段，我们SCA这个方块里标注的只是SAST。
值得一提的是，2.0阶段，我们在应急修复层面实现了无痛升级。无痛修复首先需要知道不受到漏洞威胁的组件版本，以及为了防止兼容性问题，需要确认安全修复版本与存在漏洞版本相比，在组件代码层面有哪些修改，是否夹带"私货"或大幅修改原有组件代码逻辑，且这个"不兼容"修改是否影响业务系统的代码链路。一旦发现安全修复版本的代码会影响业务系统链路，便可判断系统不能自动升级，需要研发人工介入来观察修复稳定性。当通过上述方式确保漏洞修复不会影响业务系统链路时，便可以帮助业务部门进行自动升级，会帮助研发人员修改代码，会进行自动化发布和回归测试以及线上监控系统观察，研发人员只需要接收报警信息后快速响应和处置即可，所以称为无痛升级。
图4 蚂蚁集团软件供应链安全体系建设2.0阶段
3.0阶段：持续可信
相较于2.0阶段，3.0阶段是为了实现对未知威胁的免疫。何谓可信？是明确应用系统可执行的进程和行为，即便应用本身存在漏洞或被投毒。目前我们仍在对3.0阶段进行持续打磨，争取实现真正意义上的完全可信。
图5 蚂蚁集团软件供应链安全体系建设3.0阶段
四、蚂蚁集团软件供应链安全实践分享
接下来分享我们在软件供应链安全实践方面的三个有意思的经验和成果，希望能给大家启发。
1.蚂蚁集团软件供应链组件全生命周期管控流程
我们公司基本都是通过自研的方式来开发系统，所以面临的安全问题主要集中在组件的供应链安全威胁上。在整个管控流程中，有个重要的环节我们称之为"版本保鲜"，即当研发人员尝试引入了一个低版本或者存在安全问题的组件时，因在制品库层面进行组件版本的保鲜控制，这个低版本根本无法被构建时候引入成功，如此从源头管控组件的安全。
图6 蚂蚁集团软件供应链组件全生命周期管控流程
2.软件供应链组件辅助修复技术
业务系统在安全卡点之后，自动辅助研发人员进行修复，其核心在于对蚂蚁集团常用的组件进行扫描检测和修改引入的版本，并通过PR的方式告知相关研发人员，由他们来审查该安全修复是否对业务产生影响，从而实现业务稳定性和安全性的平衡。
图7 蚂蚁集团软件供应链组件辅助修复技术应用流程
3.应用可信解决方案
我们认为当下真正可信的解决方案应该是可以在企业内部实现大规模、可持续落地的安全解决方案，而非华丽的银弹。如图所示，首先在我们推出的安全平行切面底座上配置的各类行为规则，然后应用可信解决方案的核心是可信策略运营，即通过持续轻量级的运营，让应用、容器、网络行为能够被持续地监测和风险收敛，并且不影响其正常的功能。
图8 蚂蚁集团应用可信解决方案
时间关系，最后用一句话来结束本次分享，同样也是我非常喜欢的我们蚂蚁集团愿景中的一句话，"为世界带来微小而美好的改变"。希望今天我的分享能够给大家带来一些启发。谢谢！