保护软件供应链的安全始于发现和管理“软件工厂”
在当今的软件开发环境中，团队处理分散的资产，例如代码存储库、构建管道和容器映像。虽然这种分布式模型提供了灵活性并加快了生产速度，但它也分散了资产并使治理和安全监督变得复杂，尤其是在云原生应用程序变得越来越普遍的情况下。
因此，当出现安全问题或未经批准的软件工件进入生产环境时，安全团队通常会浪费宝贵的时间来追踪孤立生产工作负载的代码所有者。软件供应链已成为一个关键的攻击面，因此，从开发到构建阶段，尽早收集安全信号至关重要，以避免盲点并确保监控软件开发生命周期 (SDLC) 中的所有资产。
DevSecOps 团队通常缺乏自动化工具来持续映射这种不断变化的开发格局，因为新代码路径和工具经常被引入。信息通常分散在各个平台上，难以出于安全目的进行访问。随着软件在各个阶段的推广，开发平台和工具通常会在开发、集成和部署过程中发生变化。
虽然应用程序安全态势管理 (ASPM) 和可观察性供应商聚合了安全扫描，但它们往往无法提供将代码路径连接到生产的完整视图。
过时资产的存在使问题更加复杂。确定哪些存储库仍在生产中活跃可能是一项艰巨的任务，特别是对于大型组织而言。合并和收购通过增加不同的平台和开发标准使这一问题进一步复杂化。
DevSecOps 团队经常采用手动流程（例如填写清单或标记容器），这些流程非常繁琐、容易出错，并且通常会因为更紧急的优先事项而被搁置一旁。
想象一下保卫不断变化的战场，安全团队需要一张准确的地图来保护他们的资产。这些资产在发展过程中总是在移动，必须识别和保护新的目标。为了解决这个问题，需要一种持续的发现机制来映射正在发生的变化。
最佳实践和框架支持这种方法。例如， 网络安全和基础设施安全局 (CISA) 要求组织验证软件组件的来源，并维护一份全面的清单，作为其 自我证明过程。 同样， NIST 安全软件开发框架 (SSDF) 和 OWASP DevSecOps 成熟度模型 (DSOMM) 强调持续发现和可见性的重要性。
在这篇文章的其余部分，我们将概述应对这些挑战的蓝图，并探讨 Scribe Security 如何帮助组织有效地实现这些功能。
Scribe 的有效发现蓝图
Discovery 生成以图形建模的地图，提供资产、关系和工厂安全态势的视图。这允许：
- 完全的可见性和所有权控制。
- 增强的查询功能。
- 监控 KPI 和安全成熟度指标。
- 更快地识别和确定风险因素的优先次序。
- 初始扫描
初始扫描旨在创建资产的高级图谱，重点是识别需要进一步分析的资产。全面深度扫描可能非常耗时，而且许多资产（例如与生产无关或已过时的资产）可能无关紧要。初始扫描通常会收集存储库名称、ID 和活动统计信息等基本详细信息，但不包括提交或贡献者的完整列表。
一种方法是从“右到左”扫描。通过访问生产环境（例如，通过 K8s 集群 API），扫描器可以识别正在运行的容器镜像——反映业务价值的关键资产。从那里，扫描可以追溯到容器注册表和相关存储库。扫描通常在这里停止，因为注册表和前面的 SDLC 管道之间通常没有直接联系。
互补扫描可以从“左到右”运行，识别不同 SDLC 阶段（例如开发、集成、测试）的代码存储库、构建管道和注册表。
结果是一份跨平台资产的优先列表，可供深度扫描以追踪从代码到生产的沿袭并评估 SDLC 的安全状况。优先顺序基于与生产的相关性、活动水平和新近度等因素。有时，机构对资产重要性的了解有助于指导这一过程。
初始扫描可以定期安排，也可以通过代码推送等事件触发。后续扫描可以应用自动选择标准，例如使用 glob 深度扫描新发现的资产。
- 深层扫描
在确定相关资产的优先级后，深度扫描会收集建立资产之间关系的详细属性，例如分支 ID、提交和提交者 ID 以及管道运行 ID。此扫描的持续时间可能因资产范围和 API 速率限制而异。
到此阶段结束时，资产关系图开始成形，其中围绕代码存储库（包含构建信息）和运行时环境（包含注册表资产）形成连接资产集群。但是，完整的谱系仍不完整，因为注册表通常不存储有关推送构建工件的管道的信息。
- 连接集群
建立清单后，可以通过在管道中安装 CLI 工具来捕获构建来源详细信息或处理 CI 日志来完成谱系。安装是最可靠的方法，可以记录关键属性，例如代码存储库 ID、管道和运行 ID 以及映像 ID。它可以有效地链接以前孤立的集群，并创建从代码到生产的完整端到端谱系。
另一种补充方法是 CI 日志处理，它可以检索相关属性，但需要更多资源并依赖于现有日志。虽然这种方法可以更快地实施，但结合这两种方法可以产生最佳效果 - 对关键管道进行检测，并对新发现的管道进行日志分析，然后对其进行评估以进行进一步检测。
这种聚类方法还考虑将单独的谱系聚合到复杂产品的统一结构中，例如由多个组件（如微服务）组成的 Web 应用程序。
- 软件物料清单 (SBOM)
到目前为止，重点是跨平台连接开发资产，为相关资产建立从代码到生产的清晰血统。现在，注意力转移到软件工件本身的组成。在此步骤中，将从这些工件及其相关代码存储库生成 SBOM，并将其添加到现有库存中。
通过将代码存储库和工件 SBOM 合成为单个 SBOM，并使用逻辑来关联依赖关系并排除不相关的依赖关系（例如开发和测试库），可以得到比任何一个来源单独提供的更准确、更全面的 SBOM。
- 安全态势和 DevSecOPs KPI
持续绘制资产清单及其关系图是评估这些资产安全状况的最佳机会。关键因素包括人类和非人类身份的访问权限、代码签名验证、有风险或易受攻击的依赖关系以及跨各种平台和帐户的安全设置。
这些数据可以汇总到不同的维度，以衡量产品发布、部署到生产的时间以及 DevSecOps 成熟度的 KPI。具体来说，它允许团队评估安全控制的采用情况，例如代码签名和对安全设置的遵守情况，从而帮助跟踪进度并确保稳健的安全实践。
- SDLC 和软件供应链图的可视化和查询
发现过程的一个主要好处是能够将 SDLC 和软件供应链可视化为动态图形或“战斗地图”。这种可视化提供了整个开发生命周期的全面视图，使跟踪资产及其关系变得更加容易。
真正的力量来自于查询图表的能力，使团队能够提出关键问题，例如：
- “哪个组件在构建或部署期间未通过安全检查？”
- “生产中哪些工作负载是孤立的？”
- “是谁做出了导致漏洞的改变？”
- “需要修补的资产归谁所有？”
查询血统可帮助团队确定问题的根本原因，这比手动记录具有明显的优势。手动维护的所有权映射很快就会过时，这通常会导致 DevSecOps 团队低效地搜索正确的利益相关者。相比之下，可查询的图表可确保所有权和责任始终是最新的，从而减少浪费在追踪代码或基础设施责任上的时间。
- 发现工具的部署选项
组织对部署发现工具的需求各不相同，提供灵活的部署选项对于满足不同的安全要求至关重要。一些团队更喜欢通过 SaaS 平台进行远程访问，以简化管理和扩展。另一方面，具有更严格安全协议的团队可能会选择本地扫描器部署，以对敏感凭据（例如开发平台 API 令牌）进行更严格的控制。SaaS 和本地部署之间的选择取决于组织的安全态势、合规性需求和对数据的控制等因素。
结语
保护软件供应链是一场持续的战斗；任何组织都不应该在没有清晰地图的情况下进入这场战斗。通过实施强大的发现流程，您可以全面了解整个 SDLC 和供应链，确保从开发到生产，每项资产都得到核算。借助 Scribe Security 蓝图等工具，您可以构建连接的谱系，生成准确的 SBOM，评估您的安全态势，并可视化开发生态系统中的关键关系。这种级别的洞察力使 DevSecOps 团队能够快速识别漏洞、追踪漏洞来源并保持对其软件格局的最新了解——这对于在当今快节奏和复杂的开发环境中保持领先地位至关重要。
刻划式打标系统 提供全面的发现和治理解决方案，作为确保软件供应链安全的关键推动因素：
- 初始扫描和深度扫描 – 识别并优先考虑跨环境的代码存储库、管道和容器映像等资产，建立相关组件的清单。
- 端到端血统 – 使用 CLI 工具和 CI 日志连接隔离的资产集群，形成从代码到生产的完整谱系。
- 软件物料清单 (SBOM) – 通过综合工件和存储库数据并排除不相关的依赖关系来生成准确的 SBOM。
- 安全态势评估 – 持续评估访问控制、代码签名和易受攻击的依赖项以衡量安全 KPI。
- 可视化和查询 – 可视化整个 SDLC 并支持查询以追踪漏洞、孤立工作负载和资产所有权。
- 灵活部署 – 支持 SaaS 和本地部署，以满足不同的安全需求和对敏感数据的控制。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
