文章总结： 文章分析了软件供应商面临的四大安全风险：产品漏洞、公司员工、开发流程和云端服务，并提出了相应的治理框架。作者介绍了SDL、SLSA、ATT&CK等安全模型，以及三大安全设计原则。针对不同风险，文章提出了具体的安全举措，包括开源治理源头管控、CI/CD环境渗透测试、安全意识培训、云端服务安全评审等，旨在帮助软件供应商提升产品安全性和供应链安全。
综合评分： 88
文章分类： 供应链安全,安全建设,安全运营,漏洞分析,解决方案

软件供应商实战对抗十大安全举措

原创

aerfa21

我的安全视界观

2024年1月8日 06:06
北京

软件供应链的安全问题越演越烈，在近几年的国家级实战攻防演习中频频发生。即使是在常态化，我们也在不断地帮客户（被供应链攻击的上游客户）应急或在自家环境中发现过此类事件。因此企业在防守难度上，又新增了一块高地。

作为安全产品的供应商，在瞬息万变的攻防态势下，正努力、主动地试图摸索出一条解决之道，提升产品的自身安全性以及到客户侧的整条链路安全性，以更好的服务客户。本系列文章将以供应商视角，介绍实战场景中遇到的软件供应链攻击，分享对应的常态化实践举措，以及在攻防演习前的大型集中战。

本篇章将继续围绕实战风险进一步剖析，结合日常的安全建设和运营工作，总结并提炼出四大类风险、十大应对的安全举措，以及在整个构思的过程中参照的安全框架、设计原则等，最终输出一份软件供应商面临的安全风险治理框架。

—

实战风险回顾

在上一篇的中，主要围绕产品漏洞、公司员工、开发流程和云端服务四方面的安全风险及实例进行介绍，其风险大致如下：

详情可至《软件供应商面临的攻防实战风险》进行回顾。

—

风险深入剖析

本节将进一步介绍这些风险的治理关键点以及策略，不再去对风险进行介绍，但会去拆解、分析关键点，从而琢磨出应对之道。

2.1.产品漏洞

产品的漏洞分类方法非常多，比如按照漏洞风险等级可分为严重、高、中、低危；按照漏洞类型可分为注入类、文件处理类、不安全的配置类、不安全的设计类等；按照漏洞出现的位置可分为主机漏洞、web漏洞、客户端漏洞；…但继续这样分下去可能会使问题变得特别复杂，并不能帮助解决产品存在漏洞的现实。不过每个分类方法，似乎都有一定道理及参考意义。仔细分析这些漏洞分类方法，似乎都是在漏洞已经发生的情况下，要定级或描述时才具有参考价值。不如也“左移”一下，试着从漏洞来源角度解题，则可清晰的分为两类：

外部引入漏洞：外部引入包括开源和商业，前者指开源软件或组件的漏洞，若产品引用了存在漏洞的开源产品（开源产品还存在后门投毒和合规等风险，此处不提及是因为非安全漏洞），则自身可能就会被牵连导致有漏洞。后者则是外采第三方的产品存在漏洞，这部分有供应商为安全兜底（实则一些供应商的安全，很可能做的还不如客户好，产品自身安全性堪忧，故需要甲方对其加强安全审查），相对来说安全资源的投入不用那么大。
内部自研漏洞：指产品开发的过程中，由于缺乏或安全意识不足引入的漏洞（不含外部引入漏洞的场景），包括设计、编码、配置等方面的漏洞。据一份软件质量领域领军人物Jones的报告，说明软件85%的缺陷是在编码阶段引入的，其实放到安全性方面，从占比来看同样适用，其余15%就应该是在设计阶段和部署阶段，产出的不安全设计和不安全配置的问题。故以此泛说明是产品开发过程中的漏洞，而不仅局限指编码阶段的漏洞。

2.2.公司员工

用底线思维的来看人员的安全性问题，员工终端/账号必定会失陷。对失陷的原因进行分类分析，可以分为主动和被动两种：

主动失陷：指有意识的中招，直白点讲就是有内鬼。话说人的“漏洞”是最大的难题，除了说人员缺少安全意识之外，还要特别注意内鬼场景。与之对抗的ROI尤其低，但又不得不做。常见方法至少有三类，其一是全局对身份与权限的管控，如员工访问敏感信息相关系统的权限以及可访问的资源做最小化限制，则获得敏感信息或攻击的概率就会变小，推广到所有员工和系统，就会效果显著，但是全局做起来太难了；其二是技术手段上的检测和监测，反入侵的检测规则、用户实体行为分析等需要建设并投产到常态化运营；第三是处罚和宣贯，针对违规的员工进行严格处罚（开除甚至报案），再广而告之、起到杀一儆百的效果；
被动失陷：顾名思义就是无意识的，自己终端被控都不清楚，主要依赖于反入侵检测和数据安全检测。但针对具体的场景，可以适当的做一些“左移”，在安全公司样本传递过程中，已经要求压缩加密之后传输或使用样本上报相关系统进行传递，公司还专门搭建了样本调试的机器和网络给业务方使用；在社工钓鱼的场景中，安全教育、钓鱼执法是相对来说用的比较多、且有一定效果的方法。

2.3.开发流程

面向软件开发过程的风险，其实质已经远超流程了，还包括流程中的相关人员（开发、测试、配管、交付等）、系统（开发相关基础设施，如gitlab、Jenkins、k8s、AF等）。很多都依赖于企业安全基础设施的建设，但针对此类特定的场景，还可以结合攻防实战来发现安全隐患，并推动修复，比如针对CI/CD环境的渗透测试，可以从攻击者视角进行整体的安全性评估。

2.4.云端服务

产品的云端服务是交付的重要环节，服务本身就已经暴露在互联网，此外就是提供的软件升级包、规则包具有投毒的动力，故吸引着攻击者的注意力。但通常由于其服务比较简单，相对来说较易守难攻，但针对内部攻破的例子却已有发生（SolarWinds）。所以可以借用内部资源的优势，从内部和外部进行安全评审及渗透测试，主动发现安全隐患并及时修补。

—

治理模型探索

此处的探寻是指根据已知的安全问题，去找寻相应的框架或模型来解决的过程。并不是所有的问题都有现成、成体系的模型，但是现有的一些安全模型的确已经涵盖了软件供应商遇到的安全问题。虽然有的不是那么好落地，但确实是可以起到一定的指引作用。本节将介绍三个经典模型，并尝试用自己的实践与理解的去阐述。

3.1.SDL

主要解决供应商产品的安全漏洞，通过建立安全开发组织、规范、流程、制度，配备漏洞扫描工具、人工安全设计、安全评审及渗透能力，可以实现开发安全左移和收敛软件安全漏洞的目的。

（https://www.microsoft.com/en-us/securityengineering/sdl）

至于达到的效果，需要看具体实施的颗粒度、力度而定。在笔者的实践中，开发安全体系其实是一个底座或大的安全基线，建立起来后需要持续精细化运营，才会有好的效果。但是在面对实战时，在资源有限的情况下还远不够，结果依旧会被攻击队揍。但又不能少了它，所以还需要找到真正能够应对实战攻击的补偿方法。

3.2.SLSA

聚焦解决软件开发过程中，由于代码篡改、构建系统或软件仓库而带来的安全威胁。主要通过软件签名和验签的方式防篡改，从而保障整个开发、生产和交付过程中的软件安全性。通过该框架的落地可以解决上述问题中开发流程的风险，但进一步思考为什么会有篡改发生呢？大致又可以归结为相关人员和研发基础设施存在问题，而导致的结果。

（https://slsa.dev/spec/v1.0）

令人沮丧的是要全面落地SLSA的难度也很大，在资源收紧的情况下，可以从人员和研发基础设施着手设计，比如在交付环节的重要节点进行软件病毒扫描，引入蓝军渗透CI/CD相关基础设施，发现最要命的安全漏洞并推动修复。

3.3.ATT&CK

美国研究机构MITRE推出的攻击框架，完整的包括了攻击技战法，国内不少公司的安全运营都在参照进行检测规则编写，最近几年也涌现了一些书籍专门介绍这个框架。其内容是大而全，但实际不必面面做到、况且有的也是遇不到的或利用难度很大的；其内容比较通用，没有细化到具体的场景中，比如开发环境渗透、员工终端攻防对抗，但仍旧值得借鉴其框架，来构建自己关注的场景的攻击框架。

（https://attack.mitre.org）

3.4.Top 10 CI/CD Security Risks

OWASP出品，针对CI/CD生态环境（开发环境、流程、系统）的十大安全问题总结。安全人员若在不熟悉研发环境的情况下，可参照这些风险，快速上手对公司的环境进行攻击模拟。在笔者的实践中，最开始针对开发流程的安全治理主要就是依托于这个总结，结合公司实际使用到的系统和流程等情况，枚举可能存在的安全漏洞或隐患，在由蓝军依据制定的行动计划发起攻击，从而发现安全问题之后推动业务方整改。

（https://owasp.org/www-project-top-10-ci-cd-security-risks）

—

安全设计原则

在风险深度剖析的基础上，参照安全模型或框架，便可规划或设计出安全对策及措施。不过也有几点原则可以参考，以便提高成功率：

4.1符合安全建设阶段

其实就是可落地性，符合当前的建设阶段就是最好的。安全模型和框架往往都是大而全，要做到高度覆盖率，其实是需要配套的基础设施才能支撑。当没有好基础的时候，就应该适当的做舍弃，做出切合实际的剪裁。

4.2突出问题重点治理

站在攻防视角来看待这些风险，从影响和危害角度对其进行逐一评级和分类，重要的问题就重点投入、跟进、优化，以至解决。在找重要问题时，比较有用的一个做法就是：提前思考和底线思维，如果这个风险不管而带来的结果能否承受、外部现在最关注、最想利用的是哪个风险？

4.3设定多级治理目标

无论是重点还是一般治理，其都应该有一个度，也就是在安全人员心里要有一把称。结合实际的资源、安全态势来给出不同风险的治理程度定位，如：

100%治理，不接受安全事件的发生，如产品安全漏洞；
80%治理，允许发生安全事件但要快速响应和处置，如终端攻防。

—

风险治理举措

综上所述，应针对这四方面进行case by case的制定安全举措。其涵盖的内容主要为：

产品漏洞：主要解决产品开源代码和自研代码的安全漏洞，主要是通过落地SDL来实现。另由于近几年供应链攻击特别火热，故在公司内部牵头做了一个集团级的开源治理源头管控专项，主要解决开源软件安全、合规及可用性等问题。即使SDL做的再好，也可能会发生产品安全事件，故设置了集团级的产品安全事件应急响应团队，通过场景演练、建立响应SOP等方式实现快速、有效的响应。在深入剖析处提到SDL不能对抗实战攻击，故在2023年建立了内部的产品安全蓝军，其工作职责是想方设法的攻击产品拿权限，主动走攻击者的路、让其难以继续走这条路。
开发流程：主要是解决开发制品篡改带来的威胁，但采取了效果最直接、快速体现的方式–基于Top 10 CI/CD Security Risks的实战渗透和在员工终端上的攻防对抗检测，以此在短期内发现并消除隐患、快速响应失陷或行为异常的员工终端，阻断对研发基础设施的进一步攻击。
公司员工：包括安全服务人员、研发人员和普通员工，均需要进行安全意识教育，并不定期进行钓鱼执法演练。此外安全人员需做好事件发生后的快速止损和影响范围评估的准备，备好常见场景的SOP及SOAR自动化。为了解决这一问题，内部提炼了三个专项，分别为安全意识培训、终端攻防对抗和安全运营SOP。
云端服务：防止被内、外部攻击以及升级包不被篡改发布，专门针对产品的制品交付流程进行了安全评审，并投入安全防护和运营的力量对相关资产进行加固及重点运营，投入内部蓝军（非产品安全蓝军）对云端服务从内外部视角分别进行了渗透，以此及早发现并收敛安全隐患。

长按识别二维码，和我交流

More…

——— 供应商实战演习对抗探索 ———

1 软件供应商面临的攻防实战风险

——— 实战演习 ———

——— 安全运营 ———

——— 软件安全 ———****

——— 企业安全 ———****

——— 渗透测试 ———****

——— 安全开发 ———****

——— 个人体验 ———****

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：我的安全视界观 aerfa21《软件供应商实战对抗十大安全举措》

Tags: 供应链安全安全培训安全建设安全开发安全运营渗透测试漏洞分析解决方案

你可能错过

网安别乱考证！5 本真正能帮你找工作的证书，分清刚需和智商税

数据安全风险评估系统已更新，可试用

【已复现】WordPress 未认证路径遍历漏洞，特定条件下可导致RCE

从 ZCode 到 Trae：AI 编程工具的偷传数据争议何时休