siemens/continuous-clearing
GitHub: siemens/continuous-clearing
面向企业DevSecOps的持续许可证合规工具,自动化扫描第三方组件并生成SBOM,深度集成SW360和FOSSology实现合规流程自动化。
Stars: 31 | Forks: 12



# 介绍
Continuous Clearing Tool 通过接受相应的项目 ID 进行许可证清理,扫描并收集 NPM/NuGet/Maven/Python/Debian 中使用的第三方 OSS 组件,并将其上传到 SW360 和 Fossology。
该工具通过减少创建 SW360 和 FOSSology 工作流的手动工作量,帮助开发者/项目经理加快清理流程。
### 用于 SBOM 的 Continuous Clearing Tool:
为了确保整个 DevOps 供应链的安全,我们需要确保代码是安全的,并且其他强制性安全方面已从头到尾集成到软件开发生命周期中。
为了确保这些实践到位,我们需要为 DevOps 链中的每次自动构建提供软件物料清单 ( SBOM )。此 SBOM 将包含所有第一方和第三方组件的详细信息,包括开发、传递和内部等依赖项。
该工具在逻辑上分为 3 个不同的可执行文件,使其可以根据用户需求作为独立模块使用。
**_注意:此工具创建的 SBOM 遵循 CycloneDX 版本 [v1.6](https://cyclonedx.org/docs/1.6/json/) 和 Siemens SBOM 标准 [v3](https://sbom.siemens.io/v3/format.html)。这些格式确保 SBOM 详细、安全,并符合行业和 Siemens 的特定要求。_**
**_注意:Continuous Clearing Tool 内部使用 [Syft](https://github.com/anchore/syft) 对 debian/alpine 类型项目进行组件检测。_**
# 安装包
### 从 GitHub Release 安装(官方)
#### 使用容器镜像
```
docker pull ghcr.io/siemens/continuous-clearing
```
#### 使用二进制文件
从 [GitHub Releases](https://github.com/siemens/continuous-clearing/releases) 下载 .nupkg 文件
# 通过终端执行
Continuous Clearing Tool 包含 3 个可执行文件。
您可以将 Continuous Clearing Tool 作为容器或 dotnet 包运行,
/appSetting.json
```
2. **SW360 Package Creator** - 此可执行文件期望 `CycloneDX BOM` 作为输入,在 SW360 中创建缺失的组件/发布,将所有组件链接到 SW360 门户中的相应项目,并触发 Fossology 上传。
`注意`:默认情况下,SBOM 包含开发和非开发依赖组件。因此,在 Sw360 中创建组件时,请确保将 *RemoveDevDependency* 标志设置为 `true`,以跳过创建开发依赖组件。
```
SW360PackageCreator.exe --settingsfilepath //appSetting.json
```
3. **Artifactory Uploader** - 此可执行文件将 `SW360PackageCreator.dll` 更新的 `CycloneDX BOM` 作为输入,并将已清理(清理状态 - "Report approved")的组件上传到 Jfrog Artifactory 中的 SIPARTY 发布仓库。
```
ArtifactoryUploader.exe --settingsfilepath //appSetting.json
```
有关配置和执行的详细说明在 [使用文档](doc/UsageDoc/CA_UsageDocument.md) 中提供。
**_注意:ArtifactoryUploader 不适用于 Debian/Alpine 清理。_**
# 开发
这些说明将帮助您在本地计算机上启动并运行项目,用于开发和测试目的。
#### 前置条件
1. 下载 Visual Studio 2022。
2. 下载 Docker 最新版本。
3. 需要在本地加载 Continuous Clearing Tool 的 Docker 镜像。
#### 通过 .NET SDK 构建
* 将仓库克隆到您的本地目录
* 在 `src` 文件夹内,执行以下命令来构建源代码:
```
dotnet build --configuration Release
```
#### 创建 Docker 镜像
在存在 `Dockerfile` 的项目根目录中执行以下命令以创建镜像:
```
docker build -t -f Dockerfile .
```

#### 创建 Dotnet 包
在项目根目录中执行以下命令:
```
nuget pack CA.nuspec
```

# 贡献
我们随时欢迎改进!欢迎通过合并请求记录错误、撰写建议或
贡献代码。要在本地构建和测试解决方案,您应该安装 .NET 8。所有详细信息均列在我们的贡献指南中。
参见 [CONTRIBUTING.md](CONTRIBUTING.md)。
# 许可证
代码和文档遵循 [MIT License](LICENSE)
第三方软件组件列表:
- [ReadmeOSS_continuous-clearing_nupkg](https://htmlpreview.github.io/?https://github.com/siemens/continuous-clearing/blob/main/ReadmeOSS_continuous-clearing_nupkg.html)
- [ReadmeOSS_continuous-clearing_DockerImage](https://htmlpreview.github.io/?https://github.com/siemens/continuous-clearing/blob/main/ReadmeOSS_continuous-clearing_DockerImage.html)
版权所有 2025 Siemens AG
作为容器运行
按以下顺序执行它们以完成完整的许可证清理流程。 1. **Package Identifier** - 此可执行文件接受包文件或 `cycloneDX BOM` 作为输入,并提供 SBOM 文件作为输出。对于每个组件,依赖分类(开发、内部)以及 Jfrog Artifactory 中的可用性将被识别并添加到 SBOM 文件中。 ``` docker run --rm -it -v /path/to/InputDirectory:/mnt/Input -v /path/to/OutputDirectory:/mnt/Output -v /path/to/LogDirectory:/var/log -v /path/to/configDirectory:/etc/CATool ghcr.io/siemens/continuous-clearing dotnet PackageIdentifier.dll --settingsfilepath /etc/CATool/appSetting.json ``` * Input(即 /path/to/InputDirectory -> 存放输入文件的位置) * Output(即 /path/to/OutputDirectory -> 结果文件将存储在此处) * Log(即 /path/to/logDirectory -> 日志将存储在此处) * Configuration(即 /path/to/ConfigDirectory -> 存放配置文件的位置,即 [**appSetting.json**](/src/LCT.Common/appSettings.json)) 2. **SW360 Package Creator** - 此可执行文件期望 `CycloneDX BOM` 作为输入,在 SW360 中创建缺失的组件/发布,将所有组件链接到 SW360 门户中的相应项目,并触发 Fossology 上传。 `注意`:默认情况下,SBOM 包含开发和非开发依赖组件。因此,在 Sw360 中创建组件时,请确保将 *RemoveDevDependency* 标志设置为 `true`,以跳过创建开发依赖组件。 ``` docker run --rm -it -v /path/to/OutputDirectory:/mnt/Output -v /path/to/LogDirectory:/var/log -v /path/to/configDirectory:/etc/CATool ghcr.io/siemens/continuous-clearing dotnet SW360PackageCreator.dll --settingsfilepath /etc/CATool/appSetting.json ``` 3. **Artifactory Uploader** - 此可执行文件将 `SW360PackageCreator.dll` 更新的 `CycloneDX BOM` 作为输入,并将已清理(清理状态 - "Report approved")的组件上传到 Jfrog Artifactory 中的 SIPARTY 发布仓库。 ``` docker run --rm -it -v /path/to/OutputDirectory:/mnt/Output -v /path/to/LogDirectory:/var/log -v /path/to/configDirectory:/etc/CATool ghcr.io/siemens/continuous-clearing dotnet ArtifactoryUploader.dll --settingsfilepath /etc/CATool/appSetting.json ```作为 dotnet 包运行
解压下载的 .nupkg 包,在 tools 文件夹内执行以下命令。 1. **Package Identifier** - 此可执行文件接受包文件作为输入,并提供 CycloneDX BOM 文件作为输出。对于每个组件,依赖分类(开发、内部)以及 Jfrog Artifactory 中的可用性将被识别并添加到 BOM 文件中。 ``` PackageIdentifier.exe --settingsfilepath /标签:Alpine, Cargo, Cilium, Conan, CycloneDX, Debian, DevSecOps, Docker, FOSSology, GPT, Maven, NPM, NuGet, Python, SBOM, SW360, Syft, 上游代理, 云安全监控, 依赖管理, 合规自动化, 安全防御评估, 开源合规, 数据集, 文档安全, 无后门, 漏洞管理, 漏洞验证, 硬件无关, 组件扫描, 西门子, 许可证清理, 请求拦截, 跌倒检测, 软件物料清单, 静态分析