引言

最近我们在和一些客户沟通,大家都提出了一些问题：

Q1：当企业通过 SBOM（软件物料清单）初步掌握了软件资产的“成分表”后，那已有的存量软件资产该如何有效管控？长期累积的“技术债”又该如何安全化解？

从场景来看：

Q2：对于部分行业（如汽车、工业控制等）常常面临仅获取二进制代码（如车载 ECU 固件等）无源码的情况下，传统依赖源码解析的 SBOM 生成方式是否适用？（是否可以基于二进制生成）？

Q3：党政机关、关键信息基础设施运营单位常面临两类困境：一是早期委托开发的系统外包团队解散，无资产维护文档；二是系统承载敏感数据（如政务数据、涉密信息），无法中断服务，导致 SBOM 揭示的技术债（如 EOL 数据库、高危开源组件）难以直接修复。

我们可以把这类问题总结为：如何从“看清企业技术资产”到“管好企业技术债”（SBOM 时代的技术债的治理逻辑）。

过时软件、终止生命周期（EOL/EOS）系统等技术债，早已潜藏于多数企业 IT 环境。停更的操作系统、无人维护的数据库、弃用的开源库虽还在撑业务，但 SBOM 的 “透明化能力”，进一步暴露了存量软件资产中的大量潜在风险。

Forrester 近期调查显示，仅 21%的 IT 决策者称组织无显著技术债，79%面临中高风险技术债；若不及时处理，会随时间累积修复人力、资金等额外成本，还可能衍生新的运营隐患。

对 CISO 与工程负责人而言，SBOM 不仅能 “看清存量”，更能作为工具将隐性技术债转化为可管控、可化解的明确任务，避免风险从潜在隐患演变为爆炸式危机。

技术债与 EOL 软件

SBOM 的核心价值之一是精准定位存量资产中的 EOL/EOS 组件，这类组件正是技术债引发安全风险的“重灾区”。

相关研究数据显示：

图 1：EOL 软件的风险数据汇总

典型案例

• WannaCry 勒索软件事件中，98%被感染机器运行 EOL 的 Windows 7，若当时企业已通过 SBOM 识别出这些存量 Windows 7 设备，提前制定迁移计划，就可大幅降低感染率。

• Log4Shell 漏洞爆发时，超 50%受影响应用已处于 EOL 状态，由于缺乏供应商补丁，企业只能仓促应急，而 SBOM 本可提前标记这些 EOL 应用的 Log4j 依赖版本，为缓解措施争取时间。

• 2023 年美国联邦机构数据泄露事件，根源是 EOL 的 Adobe ColdFusion 服务器，若通过 SBOM 持续跟踪该组件的生命周期，便可避免漏洞暴露超一年未处理的被动局面。

SBOM 的出现，正是让这些已知但未处理的风险，从“隐性债务”转化为“显性任务”，为企业争取风险化解的窗口期。

即使有 SBOM 赋能资产透明化，技术债为何依旧持续堆积？

SBOM 提供的“透明化”只是基础，若缺乏相匹配的管控机制与协作流程，技术债仍会在流程盲区中隐性增加。

以下三类场景是企业从“看清资产”到“管好债务”的主要障碍：

图 2：技术债堆积的核心障碍与案例

研究显示，70%的企业安全部门仅在紧急事件（如 Log4Shell）时才介入技术债处理，而不是通过 SBOM 提前参与生命周期管理，这种 “孤岛模式” 让 SBOM 的风险预警价值完全失效。

以 SBOM 为核心的技术债治理框架

企业化解技术债的关键，在于将 SBOM 从“资产清单”升级为“治理工具”，通过“识别-评估-规划-控制-观测-协作”的闭环，实现存量资产的全生命周期管控。

安势信息根据长期服务各行业头部客户的丰富实战经验，总结出以下用于解决企业“SBOM 之后如何管”的实操方法：

1、基于 SBOM 的存量资产精准发现

管好资产的前提是摸清家底，而 SBOM 能突破传统清点方式的局限，实现显性+隐性资产的全覆盖：

1.1 SBOM 生成的技术路径

SBOM 可通过源码或二进制两种路径生成，需根据场景选择：

图 3：SBOM 生成的技术路径

1.2 源码级与二进制级 SBOM 对比

图 4：源码级与二进制级 SBOM 对比

1.3 资产发现的实操动作

• 显性资产梳理：通过 SBOM 记录操作系统（如 Windows Server 2016）、数据库（如 MySQL 5.7）、商业软件（如 SAP ECC 6.0）等核心资产的版本号、支持周期及 EOL 日期，避免漏报； 
  

• 隐性组件穿透：SBOM 可深入应用内部，识别依赖的开源库（如 Log4j 2.0）、第三方插件等隐性组件，解决“影子 IT”问题。
  

• 工具联动增效：将 SBOM 与 IT 资产管理工具集成，自动同步资产状态变化（如新增组件、版本更新等），减少人工维护成本。

2、SBOM+威胁情报的风险评估

并非所有技术债都需紧急处理，企业需结合 SBOM 数据与业务实际，制定差异化优先级：

2.1 核心评估维度：

• 暴露程度：基于网络访问路径，判断资产是否面向互联网（如电商平台的前端服务器）、是否处于核心网段（如财务系统数据库）； 
  

• 业务重要性：关联 SBOM 与业务流程，识别支撑核心业务（如支付、生产调度等）的资产，这些资产若存在技术债，风险等级需上调； 
  

• 漏洞关联性：将 SBOM 中的组件版本与 NVD、CISA KEV 目录联动，例如，SBOM 中标注的 Log4j 2.14.1 可直接关联 CVE-2021-44228 漏洞，若该组件用于日志收集系统，且存储敏感数据，则需列为“最高优先级”；

2.2 技术债风险评估矩阵：

图 5：技术债风险评估

*仅供参考，具体处理周期请根据各企业自身业务情况及机制。

3、结合 SBOM 依赖图谱的修复规划

针对高优先级技术债，需基于 SBOM 的依赖关系，制定不中断业务的升级计划：

图 6：EOL 资产修复规划流程图

4、基于 SBOM 的补偿性控制

部分存量资产（如老旧工业控制系统、定制化 ERP）因业务绑定无法短期升级，需通过 SBOM 制定精准防护措施，常规场景与特殊场景（党政机关、关键信息基础设施）措施差异如下：

图 7：补偿性控制措施对比

5、SBOM 动态更新与持续观测

从一次性治理到常态化管控。技术债治理不是一劳永逸的项目，需通过 SBOM 的动态更新，实现长期管控：

• SBOM 实时同步：建立资产变更-SBOM 更新联动机制，例如，开发团队新增一个开源库后，需在 24 小时内更新 SBOM；IT 部门更换服务器操作系统版本后，同步修改 SBOM 中的对应条目； 
  

• 漏洞实时监测：将 SBOM 与漏洞扫描工具集成，每周自动扫描 SBOM 中的组件，发现新漏洞立即推送至安全团队，从而实现实现快速响应； 
  

• 定期评审复盘：每季度召开技术债评审会，基于 SBOM 数据复盘修复效果。例如，对比上季度与本季度的 EOL 资产数量、高危漏洞数量，评估治理进度，调整后续计划。

6、以 SBOM 为载体的跨团队协作

打破孤岛效应。技术债治理需 IT、安全、工程团队协同，而 SBOM 可成为“共同语言”：

图 8：跨团队协作职责与 SBOM 应用

协作机制：

• 共享数据看板：通过可视化看板展示资产状态、漏洞风险、修复进度，确保目标一致；

• 月度协同会：基于 SBOM 数据讨论重点问题，协调资源；

• 责任到人：在 SBOM 中为每个技术债项标注负责人、修复时限与验收标准，避免推诿。

最终，技术债治理的目标不是消灭所有旧资产，而是通过 SBOM 的全生命周期管控，让存量资产安全可控，为企业创新腾出资源与精力，毕竟可控的技术债远胜于失控的风险。

关于安势信息

上海安势信息技术有限公司是国内先进的软件供应链安全治理解决方案提供商，核心团队来自 Synopsys、华为、阿里巴巴、腾讯、中兴等国内外企业。安势信息始终坚持 DevSecOps 的理念和实践，以 AI、多维探测和底层引擎开发等技术为核心，提供包括清源 CleanSource SCA（软件成分分析）、清源 SCA 社区版、清正 CleanBinary (二进制代码扫描)、清流 PureStream（AI 风险治理平台）、清本 CleanCode SAST（企业级白盒静态代码扫描）、可信开源软件服务平台、开源治理服务等产品和解决方案，覆盖央企、高科技、互联网、ICT、汽车、高端制造、半导体 &软件、金融等多元化场景的软件供应链安全治理最佳实践。

欢迎访问安势信息官网https://www.sectrend.com.cn 或发送邮件至 info@sectrend.com.cn 垂询。