企业官网建设流程全解析

• 文档
• 教程
• 网络安全

本文基于 OWASP Mobile Application Security Testing Guide（MASTG）中的技术指南 MASTG-TECH-0130，讲解如何用 cdxgen 为 Android 工程生成 CycloneDX 格式的软件物料清单（Software Bill of Materials，SBOM），并上传到 Dependency-Track 平台识别存在已知漏洞的第三方依赖。读完本文，你将掌握一套可复现的依赖成分分析流程，能够在 Android 工程中直接落地执行。

为什么 Android 应用需要 SCA 与 SBOM

现代 Android 应用高度依赖第三方库，依赖安全已成为供应链安全的关键一环。软件成分分析（Software Composition Analysis，SCA）工具会检查依赖的元数据（如包名、版本号），并与 NVD 等公共漏洞数据库比对，从而发现已知漏洞。在 Android 开发中，依赖在构建过程中被解析、编译并最终合并进应用的 DEX 文件，因此 MASTG 强调应在构建环境中扫描依赖，而非仅扫描最终的 APK，这样才能准确覆盖包括传递依赖（transitive dependencies）在内的全部库。

MASTG-TECH-0131 明确指出，分析依赖的首选技术是 MASTG-TECH-0131（构建期 Gradle 插件扫描）与 MASTG-TECH-0130（本文所述的 SBOM 方案）。后者通过生成标准格式的 SBOM，将依赖清单以机器可读的方式交给专业的组件分析平台进行持续监控，两者可互为补充。

工具链总览：cdxgen + Dependency-Track

本方案由 MASTG 仓库中两个通用工具配合完成：

• MASTG-TOOL-0134（cdxgen）：CycloneDX 官方出品的 SBOM 生成器，单条命令即可为大多数应用和容器镜像生成 SBOM。它支持 SwiftPM（iOS）与 Maven（Android）等生态。仓库工具文档特别提醒：虽然 cdxgen 也支持对编译后的 APK/AAB 生成 SBOM，但结果有限且大多不完整——这是因为应用内库的元数据在打包时被移除了。因此官方推荐在 Android 应用项目目录下执行 cdxgen，以获得完整的 SBOM。
• MASTG-TOOL-0132（Dependency-Track）：开源组件分析平台，帮助组织识别并降低软件供应链风险。它依赖 SBOM 识别存在漏洞的依赖，可通过 REST API 接收 SBOM 上传。

步骤一：在项目根目录生成 CycloneDX SBOM

进入要扫描的 Android Studio 工程根目录，执行：

$ cdxgen -t java -o sbom.json

参数说明：

• -t java：指定技术类型（type）为 Java 生态。Android 工程的依赖管理（Gradle/Maven）属于该生态，cdxgen 会据此解析build.gradle/build.gradle.kts中声明的依赖及传递依赖；
• -o sbom.json：指定输出文件名，生成的是标准CycloneDX格式的 JSON 文档。

仓库中的演示案例 MASTG-DEMO-0051 使用的正是这条命令（见 run.sh），生成的示例产物 sbom.json 展示了完整的文档结构：

• bomFormat与specVersion声明为 CycloneDX、规范版本1.5；
• serialNumber为 UUID 形式的唯一序列号；
• metadata.tools.components记录了生成工具（cdxgen10.10.5，publisher 为 OWASP Foundation）；
• metadata.lifecycles标记 phase 为build，表明该 SBOM 取自构建期；
• metadata.component描述了被扫描工程本身（该演示中为 MASTestApp）。

步骤二：Base64 编码并上传 SBOM

Dependency-Track 的 REST API 要求 SBOM 以 Base64 编码后放入 JSON 请求体。先生成编码：

$ cat sbom.json | base64

随后调用 API 上传。以下为 MASTG-TECH-0130 提供的完整请求（注意原文档中X-API-Key末尾的多余>为笔误，此处已修正为规范形式）：

$ curl -X "PUT" "http://localhost:8081/api/v1/bom" \ -H 'Content-Type: application/json' \ -H 'X-API-Key: <YOUR API KEY>' \ -d $'{ "project": "<YOUR PROJECT ID>", "bom": "<BASE64-ENCODED SBOM>" }'

请求参数说明：

• 接口地址http://localhost:8081/api/v1/bom：Dependency-Track 的 SBOM 上传端点（REST API 默认端口 8081）；
• X-API-Key：在 Dependency-Track 中创建的项目级 API 密钥，用于鉴权；
• project：目标项目的 ID，SBOM 会上传到该项目下；
• bom：步骤一生成的sbom.json经 Base64 编码后的字符串。

在真实环境中，建议将编码结果存入 shell 变量（如BOM=$(cat sbom.json | base64 -w0)）再构造请求体，以避免大文件中的换行符破坏 JSON 结构；-d $'...'是 bash 的 ANSI-C 引用语法，用于在请求体内保留换行与特殊字符。

步骤三：在 Dependency-Track 前端核查漏洞依赖

上传完成后，打开 Dependency-Track 的 Web 前端：http://localhost:8080（使用 dependency-track Docker 容器默认设置时，前端端口为 8080）。进入上传 SBOM 时指定的项目，即可查看依赖分析结果：

• 项目中的依赖（components）清单及对应包 URL（purl）；
• 每个依赖命中的已知漏洞（CVE 标识符）与风险等级；
• 存在漏洞的依赖可直接定位到版本，作为升级依据。

关于传递依赖的支持

MASTG-TECH-0130 末尾专门有一条注意说明：

Transitive dependencies are supported by MASTG-TOOL-0132 for Java and Kotlin.

即 Dependency-Track支持 Java 和 Kotlin 的传递依赖分析。由于 Android 工程大量依赖链通过 Gradle 传递解析，这一能力保证了 SBOM 上传后，扫描结果能覆盖依赖树中的间接库，而非仅顶层直接依赖。

仓库中的完整验证链路：测试用例与演示

MASTG 仓库为本文方案提供了可追溯的测试与演示证据：

MASTG-TEST-0274（Dependencies with Known Vulnerabilities in the App's SBOM）将本方案固化为标准测试用例，其执行步骤为：

1. 使用 MASTG-TECH-0130 生成 SBOM，或向开发团队索取 CycloneDX 格式的 SBOM；
2. 将 SBOM 上传到 MASTG-TOOL-0132；
3. 检查 Dependency-Track 项目中是否存在带漏洞的依赖。

判定标准：只要发现存在已知漏洞的依赖，测试即失败（漏洞数量可随时间增长）。该用例关联 MASWE-0044，属于 MASVS-CODE 分类。

MASTG-DEMO-0051则给出了真实运行结果：在某 Android 工程根目录执行cdxgen -t java -o sbom.json后上传，Dependency-Track 识别出200 余个唯一依赖（components），其中7 个存在漏洞的依赖、共 7 个漏洞（演示文档注明该数字可能随时间增加）。其输出样本 output.json 展示了报告条目的典型结构：

{ "group": "com.squareup.okhttp3", "name": "okhttp", "version": "4.8.0", "scope": "optional", "purl": "pkg:maven/com.squareup.okhttp3/okhttp@4.8.0?type=jar", "type": "library", "bom-ref": "pkg:maven/com.squareup.okhttp3/okhttp@4.8.0?type=jar", "properties": [ { "name": "GradleProfileName", "value": "debugAndroidTestCompileClasspath" } ] }

演示的评估结论指出：okhttp有 2 个已知漏洞、okio有 1 个已知漏洞，均应升级到最新版本。这展示了从"生成 SBOM → 上传 → 定位漏洞依赖"的完整闭环，也验证了 SBOM 中 purl（Package URL）格式的依赖标识能被 Dependency-Track 直接解析匹配漏洞库。

方案对比：SBOM 方式与构建期 Gradle 扫描

本方案并非唯一的 SCA 手段。MASTG 同时收录了构建期扫描方案MASTG-TECH-0131，其思路是在 Android 工程app模块的build.gradle中集成 OWASP Dependency-Check Gradle 插件，通过./gradlew dependencyCheckAnalyze在构建环境直接扫描（依赖缓存位于~/.gradle/caches/modules-2/files-2.1），并支持用suppression.xml排除误报。对应测试用例为 MASTG-TEST-0272。

两者的定位差异在于：

• 构建期扫描（MASTG-TECH-0131）：与 Gradle 构建深度绑定，扫描发生在依赖解析与编译阶段，反馈直接，适合开发者在本地或 CI 中即时发现漏洞；
• SBOM 方案（MASTG-TECH-0130）：产出标准化的机器可读清单，上传 Dependency-Track 后可持续跟踪、集中管理，适合跨项目、跨团队乃至面向客户交付时的供应链合规审计。

MASTG 将二者并列为依赖分析的首选技术，实践中可根据团队的审计与合规需求选择或组合使用。

注意事项与常见问题

• 务必在工程根目录执行 cdxgen：如前文所述，对已打包的 APK/AAB 生成 SBOM 会因库元数据被移除而不完整，导致漏报；
• API 密钥管理：上传前需在 Dependency-Track 中为项目配置 API Key，密钥应妥善保管，避免泄露进版本库；
• 漏洞数据时效性：扫描结果依赖 NVD 等漏洞库的更新情况，同一 SBOM 在不同时间扫描可能得到更多漏洞记录，建议定期重新分析；
• 端口约定：前端 8080 与 API 8081 均为 dependency-track Docker 容器的默认设置，如自定义了端口映射，请以实际部署为准；
• 传递依赖覆盖：Java/Kotlin 工程的传递依赖会被 Dependency-Track 纳入分析，但其他生态（如原生 C/C++ 库）的覆盖范围请以工具文档为准。

通过本文的流程，你可以为任意 Android 工程快速建立 SBOM 驱动的依赖成分分析能力，将供应链漏洞识别纳入标准化的可审计流程。

• 文档
• 教程
• 网络安全