我参与的古今建筑博物馆迫使我关注保护它们。例如,一个旧的依赖项可能会变成CVE,或者一个稳固的开源项目可能会商业化。这就是软件材料清单(SBOM)概念产生的地方,用于编目系统的许可证和依赖生态系统。这个构建工件随后会被分析,以确定构成组件是否:
- 易受利用,或者
- 在不可接受的条件下获得许可,例如过于商业化或过于掠夺性。
本文将解释如何使用:
- BitBucket管道生成SBOM,以及
- OWASP的依赖跟踪如何分析它。
了解您的风险
不知道您的代码和容器中潜藏着什么是幸福,但也很危险。然而,通过依赖分析器处理所有组件可能会给出压倒性的反馈。更好的做法是将其仪表板化并融入团队文化,使得依赖问题的数量今天应该总是少于昨天。
维基百科指出:“开放全球应用安全项目(OWASP)是一个在线社区,提供免费可用的文章、方法论、文档、工具和技术,涉及物联网、系统软件和Web应用安全领域。”因此,他们提供一个平台来跟踪和分析系统中的漏洞并不令人惊讶。其最显著的特点是其主仪表板:
中间最大的图表显示了所有被跟踪项目的漏洞数量。关键、中等和低级漏洞的指标显示在下面。依赖跟踪从一个或多个来源获取已知漏洞。其中最显著的是来自美国国家漏洞数据库的常见漏洞和暴露(CVE)列表。每个CVE都被分配一个从未知和低到关键的严重性级别。依赖跟踪会在后台定期使用相关的软件物料清单(SBOM)作为输入进行风险分析。
最大图表下方的部分详细说明了政策违规情况,政策根据重要性进行配置。用户可以将某些依赖项注册为不需要的,或者可以要求某些许可证甚至一组许可证在仪表板上展示并进行报告。这个反馈机制可以按政策进行配置。
顶部部分则描述了投资组合漏洞、面临风险的项目、脆弱组件以及随时间变化的风险评分。
有更多的视图、图表和统计数据,例如审核进度、项目随时间变化的漏洞数量以及组件随时间变化的漏洞数量等,但我们不如把注意力转向 BitBucket 如何生成并发送 SBOM 到 Dependency Track。
BitBucket 准备 SBOM
SBOM 的准备在 BitBucket CI/CD 管道中进行,该管道在拉取请求合并到主分支后执行。这确保了仪表板始终与实际情况保持最新。
我使用了一个包装 syft 的 BitBucket 管道来生成 CycloneDX SBOM。用于代码和容器检查的 syft
命令略有不同。
代码嗅探
从项目根目录分析代码的 syft
命令如下:
syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .
此命令将 SBOM 输出到名为 code-cdx-sbom.json 的文件中,并使用网络从互联网检索许可证信息;例如,从中央 Maven 仓库。
来自syft BitBucket pipe的shiftleftcyber(谢谢!)然后在BitBucket管道的脚本块中配置,以如下方式包装这个syft
命令:
pipe docker //ccideas/syft-bitbucket-pipe1.0.0
variables
SYFT_CMD_ARGS'. --output cyclonedx-json=code-cdx-sbom.json'
SYFT_JAVA_USE_NETWORK'true'
syft项目的自述文件列出了令人印象深刻的支持语言,但我只在Java和JavaScript上使用过它,还有一个Python项目在待办事项中。
你的容器中潜伏着什么?
要扫描你注册表中的一个容器,可以在“docker login”的范围内运行以下命令:
syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry
相应的BitBucket管道是:
pipe docker //ccideas/syft-bitbucket-pipe1.0.0
variables
SYFT_REGISTRY_AUTH_USERNAME sadilar
SYFT_REGISTRY_AUTH_PASSWORD $DOCKER_PWD
SYFT_CMD_ARGS'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'
all-layers
选项指示syft检查容器镜像的所有层,而不仅仅是最终产品。
BitBucket作为存储介质
只需让Dependency Track处理SBOM。我使用了生成SBOM的BitBucket管道的姊妹pipe:
pipe docker //ccideas/sbom-utilities-pipe1.5.0
variables
PATH_TO_SBOM code-cdx-sbom.json
SEND_SBOM_TO_DTRACK'true'
DTRACK_URL https //deptrack.test.s2c.co.za
DTRACK_PROJECT_ID df3327b2-5439-43ab-bb33-1f24228b6074
DTRACK_API_KEY $DTRACK_TEST
我指定了三个输入参数:
- 依赖跟踪实例的 URL
- 要加载 SBOM 的依赖跟踪项目 ID
- 授权上传的 API 密钥
项目 ID 可以通过在项目视图中点击“查看详情”轻松找到:
然后复制底部的对象标识符:
API 密钥 在 自动化 团队的同名输入框中找到,可以从左侧面板的 管理 菜单访问:
结论
过去的事件教会我们,利用弱点往往会导致服务中断,影响到邻近的系统或行业。这会造成意外的开支和不便。恢复过程将使开发人员和资源偏离团队目标。
此外,一个开放项目的许可可能会转变为商业许可,导致组织被追溯征收许可费用。另一方面,由于掠夺性许可条件,可能会要求开源用于获取竞争优势的关键知识产权。
因此,每个开发人员都有责任实施和支持积极的策略来应对这些风险。如果您的代码在 BitBucket 上,上述方法可以帮助您的系统与程序对接。然而,依赖跟踪 API 并不限制仅对 BitBucket 的访问,必须有方法将软件物料清单从其他 CI/CD 管道技术传输到它。
Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track