京麒沙龙15期回顾①-京东软件供应链安全运营与实践分享

2月27日，京麒沙龙软件供应链安全专场举办，京东集团信息安全部应用安全运营负责人Damien分享了京东在治理软件供应链安全风险方面的实践经验。

京东集团信息安全部应用安全运营负责人

“各位京麒沙龙的朋友们大家好，我今天分享的主题是软件供应链安全运营与实践。我会从三个方面来分享：一、软件供应链安全的风险与挑战；二、在京东的业务场景下，我们是如何开展对外的软件供应链安全持续的威胁对抗的；三、在内部我们是如何开展软件供应链安全的可持续运营工作的。”

首先分享两个案例，一是SolarWinds，它在2024年被外部爆出遭受供应链攻击，导致影响全球至少1800家企业，其中还包括包含美国的政府和一些全球的知名企业。二是2024年全球APP攻击活动超过1300起，中国的国产化软件也成为了主要的攻击目标之一，政府能源通信等行业都受到了不同程度的威胁。去年下半年某省的教育厅的短信发送平台疑似遭到供应链攻击，攻击者以这个教育厅的名义向学生和家长发送了包含非法链接的短信，该事件一度冲上热搜。

软件供应链安全现在已不仅停留在新闻层面，也可能会影响我们的生活。与之前几年相比，软件供应链的风险发生了一些变化： 

首先软件开源化的趋势加剧，导致安全风险增加。这主要表现在三个方面：

第一是开源软件代码的透明性，使得风险暴露更充分。更多的组织和个人将软件开源，让全球的开发者参与开源项目的建设中，这种开放的生态也为攻击者提供了更多可利用的信息，使其能够针对开源软件进行更有针对性的漏洞挖掘，这也让供应链软件的风险更进一步增加。

第二是依赖管理复杂性。开源软件通常依赖很多第三方软件，这种互相依赖的关系增加了软件安全维护难度，同时也为攻击者提供了更多的利用方式。比如你开发了一段代码，是一个没有安全风险的状态，但是假如你引用了Fastjson，一周后Fastjson爆发出一个新的漏洞，那你的软件也会受到影响。

第三是缺乏支持和更新，许多组织和个人都出于技术共享和非盈利的目的开源这些组件，这种机制也导致了许多漏洞不能及时更新，更有甚者直接就断供了。这种情况，给企业的安全运营工作带来了很多困难，其次，软件供应链的风险点较为分散。

其次，软件供应链风险点分散，这表现在三个方面：

第一，这个复杂的供应链结构会涉及到开发者第三方服务提供商和开源组件多个层级的参与者，这种多层调用的复杂关系导致风险在不同层级传播，其中任何一个环节的漏洞都可能影响整条供应链的安全。

第二，第三方依赖的脆弱性。在开发软件的时候，研发往往会依赖很多第三方组件和服务。之前国外统计有80%的软件都使用了开源的代码，所以风险其实就会从这些第三方的软件扩散到使用者的企业内部，给企业带来安全风险。

第三，缺乏透明性与追溯性。商业性闭源软件的不透明性，也使得这个风险其实很难在前期被发现。那在发生安全事件时，这类软件的处置成本可能会更高。

从近几年 CVE 漏洞的变化趋势中可以看到，2024年 CVE 的漏洞总数已经达到了近4.5万个，相较于2023年增长超过了50%，2024年平均每天有123个 CVE，创下了历史新高，相较于10年前上升了近7倍。大量的漏洞给企业的安全运营带来了更大的挑战。

京东是一个多供应链业务形态的公司，涉及电商、金融、云、工业、医疗等等各式各样的业务，并且京东有几千家的供应链主体，数万个开放在公网的域名，每周还会新增几十个业务域名，企业内部每天也有近万次的应用变更。同时，这些应用引入的三方组件超过了十几万，挑战可谓非常大。

针对行业性风险和京东特有的业务形态，京东应对软件供应链安全的策略分为两个方面：对外持续对抗威胁，对内实现可持续的运营。

（一）对外：持续威胁对抗

对抗威胁的第一步是看清资产，这是做好安全风险对抗的第一步，也是十分关键的一步。

京东通过增强攻击面管理能力，结合攻击者与防守者的视角，完成了公司资产的绘制。资产库让我们在资产层面上在威胁对抗上占据一些优势。

第二，持续威胁对抗还要看清风险，绘制漏洞优先级。

在收集完资产之后，对外部的风险要做一个判断，这一过程需要动态进行，通过合理分配资源，在最短时间内降低这些漏洞给京东带来的风险。

具体怎么做？首先是在情报方面，需要具备对各种漏洞情报的一些监控能力，包括一些漏洞库，同时还需要去关注一些大型的开源软件提供商，比如阿帕奇。通过监控这些漏洞情报源形成一份基础的漏洞情报数据库，用于感知安全漏洞情报的变化，为后续的分析预警提供一个基础的能力。

在收集完情报之后，接下来要做的就是对情报的风险分析，首先是影响范围，去除掉一些冷门的软件，例如国外的一些图书馆管理系统、餐饮系统等漏洞，可能不会出现在我们的企业业务中。第二是漏洞的严重性。这可以通过一些漏洞平台对漏洞的评分来评估潜在的影响，然后来设定一个企业内部对漏洞严重程度处理的一个阈值。第三是攻击复杂性，主要是评估利用这个漏洞所需要的技能和资源，比如这个漏洞是否需要一些特定条件才能被触发，比如是否前置登录、特殊权限等。第四是判断漏洞的可利用性。第五是需要再对漏洞情报的敏感性做一些判断来评估这个漏洞的实际影响，最后是结合前面提到的资产测绘的能力来分析企业内部有使用这些组件的相关系统，以及系统的重要性、敏感性、受攻击的难易程度，然后通过这些维度可以更全面的判断这个漏洞处置的优先级，判断出我们真正需要去关注的是哪些漏洞。

第三，持续监测。如果漏洞对企业内部有影响，会进入到应急处置流程，应用安全团队对这些漏洞风险进行推修。在推修结束后，这个漏洞情报会进入到一个持续观测的状态。当有新的变化出现，我们会重启这个流程。

（二）对内-持续安全运营

如何开展可持续的安全运营工作？这里有几个容易被忽略的地方，第一个场景是商采的软件入场无感知，这些软件一旦出现漏洞安全就会比较被动。解决方案是在规范采购流程，比如在采购合同中约定安全的要求 、SLA 补丁的时效等，并在流程上建立安全可观测、能力可感知的能力，减少事后应急的情况。

第二是开发阶段，这个阶段也是软件供应链漏洞引入最最多的阶段，安全要做的包含几部分：一是要发布安全的编码规范，定期给业务的研发同学开展安全培训考试，增加研发的安全开发意识；二是提供一些能力，包括IDE安全组件，培养研发人员的使用习惯，提高代码研发的安全质量；三是建立制品库安全机制，建立版本保鲜和高危组件的入场卡点机制，来提高这些组件漏洞风险被引入的门槛。

第三是测试阶段，安全团队要向研发和测试同学开放安全能力，借助研发测试的资源帮助业务提升安全风险发现能力。其实很多时候，业务并非不愿意修复漏洞，而是他们并不知道漏洞的存在，所以安全测试需要开放这些能力，让业务对安全风险状态有一个感知。这个阶段还有一个常见的问题，很多内部开发的组件也有很多漏洞，比如一些 BI 或者是中台的组件，因此，内部还需要建立一个规范的二方库组件的发布流程，做安全的统一管控，保证上线的二环包的组件是安全的版本，这样可以更高效地降低风险。

第四是在上线阶段，除了之前检测的应用中的代码以及组件的风险，还会引入到系统和中间件的这些服务配置漏洞。在这个阶段，安全团队需要做好检测能力，包括镜像检测能力，以及针对高危漏洞的卡点机制，减少业务带病上线的风险。

第五是运维阶段，需要具备对漏洞风险变化的动态感知和动态防御能力，包括运行环境监测、漏洞情报监测和动态防御机制。

可达性分析的目标是确定某个服务或应用的漏洞是否可被利用，这有助于降低漏洞管理及运营的成本。

分析这个漏洞会发现，commons-io < 2.7的版本中。漏洞产生的原因是没有在getPrefixLength函数中校验入参的非法性，导致使用者在使用这个方法时可能引入路径遍历的漏洞。在检测上可以结合SAST + SCA的能力来检测真正高风险的漏洞。

• 是否引入了这个组件库

• 组件库是否是有风险的版本

• 是否在代码中使用了触发漏洞的方法

• 数据类型是否为受影响的数据类型

• 程序是否可能被外部访问

• 调用触发漏洞的入口是否可被外部访问

• 调用过程中有无控制方法

从去年开始，我们也在漏洞自动化利用分析上进行了一些探索，针对大量的1day漏洞，借助大模型的能力进行自动化分析。整体上就是通过这个四个Agent 的实现（如下图所示），搭建起了漏洞自动化分析的能力，思路上其实不是很复杂。核心就是通过 LLM 通过大模型的代理去模拟安全研究人员和黑客的思维的一个方式，对漏洞做出一个自动化的分析。

总结下来看，软件供应链安全在企业内是一件需要长期投入的事，这个过程中酷和不酷的事情都要做。安全不仅仅是挖漏洞和分析漏洞，在安全能力建设过程中，资产测绘、代码分析、规范和机制的建立等基础能力，与安全检测和分析能力同样重要，所以安全要把地基打牢，才能应对更多、更复杂的安全风险。

另外，大模型给软件供应链安全带来了新的解题思路，它在代码自动修复和漏洞分析、敏感数据识别等场景都有非常不错的表现。大家也可以去探索更多的大模型应用场景和思路，通过大模型去解决更多软件供应链安全风险。

京麒沙龙是由京东安全联合安全社区、生态伙伴共同主办的技术交流平台，聚焦甲方安全建设、安全前沿技术、攻防技术实战等方面的话题，旨在联合安全圈各方力量，通过交流分享、生态合作，共同提升互联网安全水位。

京麒沙龙活动自举办以来，已有上百位来自一线互联网公司、安全公司、安全媒体、安全高校和研究机构的技术专家参与分享，为数万名安全从业者提供了经验和技术借鉴。