SBOM自动生成工具
发表于：2023-08-30 |

前言

做了这么久了，感觉再不出点成果之类的要被老师push了qaq…

总结一下目前比较流行的几种SBOM自动生成工具。

Salus（Microsoft Sbom Tool）

The (Microsoft) SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts.

该工具适用于Windows、Linux和Mac。只能生成SPDX2.2格式的SBOM。

安装

Github仓库里面有安装命令，直接按照步骤走就能用了。

使用

命令行

1
sbom-tool generate -b <drop path> -bc <build components path> -pn <package name> -pv <package version> -ps <package supplier> -nsb <namespace uri base>

drop path用来放置生成的SBOM文件的路径，build components path用来放置源文件夹，namespace uri base用来表示命名空间，其他参数看名字能知道意思。（实测参数随便乱填也能生成SBOM，虽然生成出的SBOM不一定正确）

“命名空间”（namespace uri base）：每个 SBOM 都有一个唯一的命名空间，用于唯一标识 SBOM，我们为 SBOM 内的命名空间字段生成一个唯一标识符，但是我们需要一个对整个组织通用的基本 URI。

使用以上命令即可生成一个SPDX2.2格式的SBOM。值得注意的是，后面跟的六个参数缺一不可。。。微软的SBOM工具可能更多是提供给软件开发者使用（而不是软件使用者），因为部分要求提供的参数（比如命名空间）使用者并不一定了解相关信息。

输入

Salus有两种输入：

  1. 可执行文件（容器镜像，container image）
  2. 源代码（文件目录，directory）

输出

Salus输出格式：spdx-json

Salus生成的 SBOM，包含了基于 SPDX 规范的四个主要部分：

  1. 文档创建信息

    例如软件名称、SPDX 版本 / 许可证、文档创建者、创建时间等。

  2. 文件部分（files）

    组成软件的文件列表，每个文件都包含有一些属性、以及 SHA-1 / SHA-256 内容哈希值。

  3. 包部分（packages）

    构建软件时使用的包列表，每个包都具有名称、版本、供应商、哈希值、包 URL（purl）、软件标识符等属性。

  4. 关系部分（relationships）

    SBOM 不同元素之间的关系列表，比如文件和包。

具体操作展示

这里展示一下我使用Salus生成SBOM的具体操作以及效果。

扫描的软件包是NPM软件包nunjucks，源文件夹中的软件包是直接从官方给的代码仓库中clone下来的。可以看出检测的结果相对来说比较合理，检测出了四个NPM软件包组件，并且将分析出的SBOM结果以json格式保存到了输出文件夹中。

生成出的SPDX2.2格式的SBOM如下图所示（原文件太长了，只截屏了一部分）：

注：只能说不知道微软官方是怎么使用这款工具的，其实我感觉到现在也没太摸索明白。在github仓库中，微软官方给了一个自己生成的SBOM样例，是为微软这款SBOM tool生成的SPDX2.2格式的SBOM。然而从我这边为他的工具生成的SBOM始终与sample文件夹中微软给的SBOM示例不太一样。猜想是和相关组件的SBOM有关，这个问题在后面介绍这款工具生成SBOM的原理时会给出一点解释。

原理

SBOM tool通过扫描源文件夹以搜索 *.csproj 或 package.json 等项目文件，以查看使用哪些组件来构建包。该工具使用[组件检测](https://github.com/microsoft/component-detection)来扫描组件和依赖项，访问其 Github 页面以获取有关支持组件的更多信息。包名称和版本代表 SBOM 正在描述的包。

组件检测 (CD)是一种包扫描工具，旨在在构建时使用。它生成跨各种软件包生态系统的所有检测到的组件的基于图形的输出（其实就是第一张截图里面的表格）。

组件检测还可以用作库来检测您自己的应用程序中的依赖关系。

总结

我们知道我们必须包含 SPDX 2.2 规范中的所有强制字段以及特定的可选字段，以便为我们的首次实现建立基线。虽然供应商名称、包版本、包校验和和关系字段在 SPDX 中是可选的，但我们将它们设为 Microsoft 产品的强制字段。

值得一提的是，Salus 还可参考其他 SBOM 文档来捕获完整的依赖关系树。

优点：

  1. 可扩展性强

    提供开发者api，同时可以部署在Windows、Linux和MacOS上。

  2. 提供了SPDX相关格式的说明

  3. 可以通过联网来获取依赖项的有关信息

  4. 用户可以自己提供SPDX中的信息

缺点：

  1. 生成的SBOM数据格式过少（只有SPDX）

  2. 不支持扫描文件或包来获取许可证信息（相关工作正在推出）

  3. 运行时无法忽略.git文件夹

  4. 无法分析可执行文件（容器镜像）

  5. 对源文件夹要求过高（来自组件检测特征概览）

  6. 完整的依赖关系树被扁平化，而不是保留其原始结构

  7. 运行部署难度较大

    该工具要想正确运行，需要提供大量命令行参数

  8. 很多包在分析时并没有正确分析出package部分

  9. 对软件包的分析生成的SBOM中错误信息较多

Syft

Syft 是一个生成软件物料清单（SBOM）命令行工具，支持文件系统和容器镜像。

Syft开源项目是Anchore的基础项目之一。Anchore从事 SBOM 相关业务已有六年之久，Syft产品相对来说比较成熟。

它可以生成包括 JSON， CycloneDX 和 SPDX 在内的多种格式的 SBOM。Syft 输出的 SBOM 可以被 Grype 用于漏洞扫描。使用Cosign 将 SBOM 添加为证明文件，可以将生成的 SBOM 和镜像一起发布。这使得镜像的消费者可以对 SBOM 进行验证，并将其用于后续的分析。

此外，Syft还有一个比较独特的功能，它可以实现 SBOM 格式之间的互相转换，例如 CycloneDX、SPDX 和 Syft 自己的格式。

目前，Syft 适用于 Linux、macOS 和 Windows。

安装

直接按照Github仓库里面的教程来安装即可，难度较小。

使用

命令行

输入

Syft 可以从多种来源生成 SBOM：

1
2
3
4
5
6
7
8
# catalog a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
syft path/to/image.tar

# catalog a Singularity Image Format (SIF) container
syft path/to/image.sif

# catalog a directory
syft path/to/dir
排除文件路径
1
syft <source> --exclude './out/**/*.json' --exclude /etc
输出

Syft 的输出格式也可以使用 -o(或--output) 选项进行配置：

1
syft <image> -o <format>

可用的formats有：

Syft还允许自定义输出的 SBOM 格式（也即指定输出模版）。

正在实现的功能

  1. 格式转换

    从现有SBOM快速创建不同格式的 SBOM，而无需从头开始重新生成 SBOM

  2. 格式验证

具体操作展示

Syft的操作较为简单，并且命令行中没有过多输出，所以这里不展示命令行操作界面，只展示一下最终生成的 SBOM 的样式。

原理

目前来看，Syft的原理似乎是扫描本地磁盘上所有相关的库与工程等，与Salus相比它似乎缺少了一个联网的功能（有待验证）。

总结

优点：

  1. 易于操作，部署工作简单

  2. “just scan everything” philosophy

    如果生成的SBOM有缺失项，Syft会从文件系统的根目录开始扫描，直到找到相关项为止。

  3. 平台可扩展性强，可以灵活选择生成SBOM的格式

    可以部署在Windows、Linux和MacOS上。可以自主选择表格格式、SPDX或者CycloneDX格式的SBOM，且格式之间可以相互转换。

缺点：

  1. 完整依赖关系的扫描只针对构建后目录扫描模式(?)

    如果采用容器镜像扫描的话，则无法构建完整的依赖关系（无法联网）。

  2. “just scan everything” philosophy (?)

    JSON中会出现虚假条目。

  3. 格式不严格

    或者说没有公开工具采用的格式。

Dependencytrack

以下内容参考该博客。

Dependency-Track是一个智能组件分析平台，允许组织识别和降低软件供应链中的风险。Dependency-Track通过利用 SBOM 的功能，采取了一种独特且非常有益的方法。这种方法提供了传统软件组合分析（SCA）解决方案无法实现的功能。Dependency-Track监控其投资组合中每个应用程序所有版本的组件使用情况，以便主动识别整个组织的风险。该平台采用API优先设计，非常适合在CI/CD环境中使用。

这里先放一个Dependencytrack的官方文档链接：https://docs.dependencytrack.org/。

安装

安装步骤

先狠狠吐槽一下，官方文档给的安装说明是真的差劲。。。按他那个说明安装困难极大（反正我是没装上）。

直接参考上面的博客，安装步骤如下：

在命令行窗口中依次执行下面的代码：

1
2
3
4
5
docker pull dependencytrack/bundled
docker volume create --name dependency-track
docker images
docker run -d -m 8192m -p 8080:8080 --name dependency-track -v dependency-track:/data dependencytrack/bundled
docker ps

然后直接通过浏览器访问8080端口即可（http://0.0.0.0:8080/）。

进入网页后使用admin/admin登录进去，成功登录后会让你重新设置admin账户的密码。重新设置即可安装完成。使用admin修改后的账户重新登陆DependenyTrack。

Docker镜像的使用

这里简单补充一点 docker 知识。

  1. 查看所有 docker 容器中的镜像。

    可以从中获取自己想要的Container ID，然后就可以针对不同的ID启动不同的镜像了。

    1
    docker ps -a

  2. 启动镜像

    1
    docker start Container-ID

  3. 关闭镜像

    1
    docker stop Container-ID

安装完毕后，下一次打开此 Docker 镜像只需要通过 docker start Container-ID 命令启动即可。

这里值得注意的是，在使用docker start Container-ID命令启动镜像之后，有可能打不开相应的镜像。这个时候可以使用docker ps -a命令查看所有镜像，观察刚刚启动的镜像的情况。

当此时镜像的健康状态是starting的时候，说明镜像正在启动。

当此时镜像的健康状态是unhealthy的时候，说明镜像的启动出现了问题，需要关闭镜像重新启动（先docker stop Container-ID再docker start Container-ID）。

（下面这个截图是本地截的，本地跑失败了555）

当此时镜像的健康状态是healthy的时候，说明镜像启动成功。

（下面这个截图是服务器截的，红色框内的是我的 docker 镜像）

使用

Dependencytrack界面介绍

  1. Dashboard：为仪表盘，作为组件漏洞的统计展示
  2. Projects：为项目，一般来说，一个bom.xml文件创建一个工程；也有特殊情况，如果一个项目里面包含多个微服务，每个微服务都有一个bom.xml，则会为每个微服务创建项目。
  3. Component：可进行相关组件的搜索，如搜索fastjson，右边为存在fastjson的项目。
  4. Vulnerabilities：漏洞库，没啥好解释的，注意更新就行。
  5. Licenses：顾名思义，组件使用的Licenses库，如Apache
  6. Policy Management
  7. Administration：这里进行后台管理配置，自动化构建需要在这里获取apikey，记得选用具有上传权限的apikey，似乎可以与 Jenkins 联动，但是我没尝试过

分析SBOM

Dependencytrack主要其实是用来分析 cycloneDX 格式的SBOM的。

这里我用 Syft 生成 numpy 库的 cycloneDX 格式的 SBOM 后上传到 Dependencytrack 上进行分析。

分析步骤：

  1. 点击右边栏，进入Projects。
  2. 通过 Create Porject创建项目，填写项目名称，项目类型，点击Create进行创建。
  3. 然后在Project页面找到刚创建的项目，点击项目名称进入项目，目前由于没有上传bom.xml也就是软件物料文件，所以没有数据显示。
  4. 点击Components->Upload Bom进行上传。这里上传了本地分析的numpy的SBOM。

完成上述所有步骤后，就可以观察 numpy 的 SBOM 的分析情况了。

总结

少有的可视化工具，非常有用！

notes
上一篇:
Diary3
下一篇:
IP container

    • Copyright © 2023 MScofield | Powered by Hexo | Theme Bamboo

    万般付之一笑，共偕老