״软件供应商必须承担责任 当他们未能履行对消费者、企业或关键基础设施提供商（白宫）的谨慎义务时。
如今，任何软件提供商都应该承担更大的责任，通过合同协议、软件发布和更新、通知以及漏洞缓解来确保软件的完整性和安全性。最近，跨部门工作组 ESF（持久安全框架）发布了指南，其中包括推荐的最佳实践和标准，以帮助客户在软件供应链内实施安全措施。在本文中，我将进一步深入探讨利用 SBOM 驱动的风险评分作为分类和优先级有效机制的实用建议。
危害软件供应链的常见方法仍然存在，包括利用软件设计缺陷、将易受攻击的第三方组件合并到软件产品中、在软件产品最终交付之前用恶意代码渗透供应商的网络以及将恶意软件注入到已部署的软件中在客户环境中。
软件物料清单（斯博姆）已成为软件安全和软件供应链风险管理的关键要素。 SBOM 用作嵌套清单，提供构成软件组件的成分列表。
SBOM 的大规模运营需要系统部署、产品开发以及软件供应商和消费者之间的数据交换方面的工具自动化和标准化。
有一些重要的机器可读的 SBOM 标准格式 得到业界的支持。 CycloneDX 和 SPDX 定义了 SBOM 创建、分析和共享的方式。 VEX 是安全公告的补充形式，用于指示一个或多个产品是否受到已知漏洞的影响。因此，它具有表明产品不受特定漏洞影响的好处，即使该漏洞存在于其 SBOM 中。
将企业内部署的软件产品之间的 SBOM 内容关联起来可以为应用程序安全、事件响应和取证团队、风险管理和采购提供强大的见解。组织需要为内部产品生成和管理大量 SBOM 数据，并使用需要有效管理的外部数据。因此，有必要支持 过程 SBOM自动化风险管理驱动 大规模地。
使用 SBOM 和风险评分
风险评分可以作为从 SBOM 内容生成简要概述的一种手段，从而能够与外部数据源进行快速比较，并根据收到的 SBOM 和优先级促进迅速决策。
- SBOM 提高了透明度，从而改善了客户组织的软件资产管理、补丁管理、技术债务差距识别和漏洞管理。它还具有提取组件来源以验证完整性和信任的潜力。
- 分析企业中实施的软件产品之间的 SBOM 内容一致性，可以为事件响应团队、风险管理和采购流程验证提供宝贵的见解。
将 SBOM 转化为大规模风险信息 – 风险评分的基本原理
每个 AppSec 专业人员和 CISO 面临的一个关键挑战是管理产品和服务中的警报疲劳。包括评估来自第三方软件组件的外部风险。
实施的主要障碍是过时的合同或基于许可证的支持，这可能会影响下游补丁和产品更新的可用性，以及软件产品（无论是开源还是闭源）内依赖关系的复杂性呈指数增长。
A 风险评分 是一种用于预测软件及其组件当前和未来风险的各个方面的指标，可以有效地支持大规模优先级划分。
风险评分 = 概率 x 影响
风险评分允许组织根据定义的风险因素了解其软件供应链风险，并预测企业中给定软件产品的潜在未来风险。
有效的风险评分可以是从 1 到 10 的等级（例如 CVSS 和记分卡），因此我们可以将每个风险组成部分与 1 到 10 的等级对齐，以便于参考。
汇总风险评分：在许多复杂的系统和系统的系统中，可能有多个 SBOM 作为集体解决方案的一部分，因此也是风险评分的集合。
风险评分组成部分：
1.漏洞： 使用 CVE 枚举映射已知漏洞 CVSS 分数来自 NVD、OSV 和 Github Advisories 等可用源。
2. 供应商的背景： 来自供应商的 VEX 和咨询上下文可能会改变使用上下文中漏洞评分的决定。将 SBOM 与漏洞关联可以启用风险标记，而 VEX 文档则允许消费者对漏洞进行优先级排序。
3. EPSS 3.0： FIRST 的可利用性指标，预测未来 0 天内被利用的概率（1.0 到 30 之间）。这是一个有效的 附加似然层 CVSS 分数有助于优先处理最重要的 CVE。
4. 电动车：CISA 还创建了一个公开的威胁情报源，如今被称为 CISA KEV（已知可利用漏洞）目录. 该目录包含 CISA 确认已被利用或正在积极利用的所有已识别 CVE 的约 5%。因此，这是优先解决高影响漏洞的一个很好的起点。此外，这是您在最终批准新版本发布之前要验证的清单的一部分。
5. 威胁情报—— 添加额外 威胁和漏洞来源提供已知的恶意软件包 （示例：来自 Snyk、Sonatype、Graynoise 等的私人源）
6. OSS 声誉： 开放 SSF 记分卡独立评估影响软件供应链不同部分的性能衡量指标，包括开源项目的源代码、构建、依赖项、测试和项目维护声誉（1-10 级）。
7. 随着时间的推移表现：产品/软件包版本的 MTTR（平均修复时间）关键漏洞可以提供安全风险性能的相关指标。
8。 碰撞 和背景。在这方面，基于软件产品的业务上下文的优先级将有助于对漏洞林进行优先级和分类。
几个例子是
- 模块/产品的关键性：这是否是关键任务（敏感性或关键性）
- 我在多少种产品中存在该特定漏洞？
- 服务/组件的外部性暴露
9. 合规暴露 – 许可证： 专有和开源软件许可证对于验证组织法律政策的合规性都很重要。
风险评分层概念 – 将风险指标添加到 SBOM：
- Start 开始 具有基于 SBOM 数据的 CVE 枚举和 CVSS 评分。
- 使用并添加 VEX 上下文来重新确定关键性的优先级
- 评估具有高 EPSS 分数（即 0.6-1.0）的 CVE
- 优先考虑 KEV 列表 – 至 先地址。
- 通过 OpenSSF 信誉评分 (1-10) 进行评估 – 识别有风险的依赖项。
- 分析 暴露 到外部网络（使用CVSS向量）
- 评估通过以下方式累积风险 产品数量 每个漏洞。
- 评估由 标签 特定容器 SBOM 对业务的重要性。
- 读码器 违规 根据公司许可政策使用 SBOM 依赖性分析存在风险。
- 分享和 管理数据 as 证明 在一个协作平台中，通过 API 和机器可读的方式将工作流程连接到 Jira 等其他系统。
利用 SBOM 进行风险评分以实现实际用例：
- 通过使用风险指标来确定跨产品的修补工作计划的优先级，对产品进行持续的漏洞分类。
- 根据风险指标并排比较产品。
- 在部署/发布之前比较并批准新版本更新。
- 使用产品版本的风险评分阈值跟踪技术债务缺口。
- 创建关于我最关键产品的前 50 个风险的快速报告。
- 影响分析可加速事件响应——以防在野外发现被积极利用的漏洞。在这种情况下， 时间很重要 快速确定我受到的影响以及这次曝光的热图的爆炸半径是多少。
如何使用 Scribe Hub 平台进行有效的风险管理：
- 集中式SBOM管理平台 – 创建、管理和共享 SBOM 及其安全方面：漏洞、VEX 建议、许可证、声誉、可利用性、记分卡等。
- 构建和部署安全软件 – 通过在 CI/CD 管道的每个阶段持续签名和验证源代码、容器映像和工件来检测篡改。
- 自动化并简化 SDLC 安全 – 控制风险 在您的软件工厂中，通过将安全和业务逻辑转换为由护栏强制执行的自动化策略来确保代码的可信度
- 启用透明度。提高交货速度 – 赋予安全团队履行职责的能力，简化安全控制，同时不妨碍开发团队交付成果。
- 执行政策。展示合规性 – 监控和执行 SDLC 策略和治理，以增强软件风险状况并证明您的业务所需的合规性。
两个例子 抄写员中心 提供风险分析功能：
每个 SBOM 映射的漏洞，通过 CVSS、VEX、EPSS 和 KEV 数据进行风险评分。
SBOM 版本性能随时间变化的时间序列表明 MTTR 是修复已识别的关键漏洞的平均时间。
总结
SBOM 驱动的风险评分使组织能够通过评估预定义的风险因素并预见与企业内特定软件产品相关的潜在未来风险来评估供应链风险。风险评分用作预测与软件及其组件相关的当前和未来风险的定量度量。
该评分指标源自 SBOM、VEX 等源的指标，并与支持供应链风险管理 (SCRM) 的内容保持一致。在应用或评估风险评分时，应考虑软件的使用环境、访问或隔离方式以及其支持的流程和系统等因素。
Scribe Hub 是一个协作平台，旨在大规模提取、管理、证明收集和 SBOM 风险评分分析。该平台可有效处理多个外部数据源，以处理复杂的系统和软件产品的复杂性。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
