系统研发过程中，开源组件的使用频率持续上升，这要求安全部门在开源软件的管理上加大投入。然而，现有产品难以与企业研发流程顺畅结合，且企业内部构建软件成分分析（SCA）能力面临诸多挑战，对此我们应如何妥善应对？
开源治理痛点
现在，系统中采用的开源组件越来越多，这要求安全部门在开源软件管理方面加大投入。不过，经过对众多产品的调查分析，我们发现它们由于风险数据库不够完善、与现有研发流程结合不紧密、性能和社区支持不全面等问题，难以融入企业内部研发流程，这给企业的安全治理带来了很大挑战。
一些企业在采纳开源组件时，由于风险数据库中缺少关键数据，无法迅速识别潜在隐患，这会对产品的安全性造成影响。
企业SCA建设难题
在企业内部培养SCA能力时，会遇到不少难题。首先，在产品与运营层面，问题频发；其次，跨部门合作中，沟通不畅，导致工作效率低下；再者，系统稳定性不足，产品故障频发，严重干扰了研发进程；最后，业务和安全部门对风险的理解存在差异，使得安全措施难以得到有效执行。
在某个企业里，业务部门觉得某些开源组件足够使用，而安全部门则认为风险太高，两方意见不一致。
业务安全协作问题
在实际情况中，业务人员并不反对安全事务，但缺乏有效的手段。他们对于新引入的软件是否安全缺乏了解，对如何调整配置以提升开源组件的安全性也不甚明了。这种情况往往导致业务和安全部门之间的协作不顺畅，进而影响了企业的整体安全状况。
业务人员不假思索地采纳了开源组件，却忽视了潜在的安全风险，这为企业安全留下了潜在隐患。
挖掘SCA需求
业务和安全部门均对组件安全有特定需求，SCA技术正好能迎合这些需求。因此，在SCA的建设过程中，需持续深挖这些需求。通过和各团队紧密协作交流，我们可以准确把握业务部门对组件安全的真实看法，进而明确建设方向和关键点，从而更有效地为企业提供支持。
通过与业务团队的交流，我们了解到他们对于开源组件的安全评估速度有着更高的期望。
数据基础设施建设
构建SCA能力，首先要从基础数据和操作规程着手。在威胁情报体系化建设的阶段，组件漏洞的信息已经存在。然而，以前我们只限于“漏洞即风险”的看法，数据仅限于包含组件漏洞的风险信息。如今，随着综合评估的需求增加，我们需要让这些信息承担更多研发安全风险管理的职责。
在搭建与数据有关的基础设施过程中，确立明确的指标标准十分关键，这样可以防止因平台故障而造成服务的大面积失效。
SCA能力落地考量
技术方案实施过程中，企业内部的安全工具，比如HIDS Agent和RASP，能从主机端对SCA构建过程进行逆向验证。然而，由于各企业的基础设施、核心技术架构、主机监控能力各有差异，SCA的实施必然面临挑战。
从安全服务供应商的视角来看，对于SCA相关产品的构建，未来应当追求更轻便和开放的合作模式。同时，在研发流程的框架内，还需梳理清楚系统在SBOM级别上的数据依赖关系。
各位读者，在你们公司提升SCA能力的过程中，有没有遇到什么特别的情况？欢迎在评论区交流讨论。觉得这篇文章有帮助，别忘了点赞和转发！
