使用 OWASP MASTG 对 iOS 依赖进行软件成分分析（SCA）：扫描包管理器工件识别已知漏洞-平芜编程栈

文档
教程
网络安全

【免费下载链接】mastg

The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.

项目地址：https://gitcode.com/gh_mirrors/ow/mastg

点击查看免费下载

本文基于 OWASP Mobile Application Security Testing Guide（MASTG）中的 iOS 技术指南 MASTG-TECH-0133 展开，讲解如何利用 dependency-check 等 SCA 工具扫描 Carthage、CocoaPods、SwiftPM 三种依赖管理器生成的工件文件，从而在不接触源码与完整 Xcode 工程的前提下定位 iOS 应用依赖中的已知 CVE 漏洞。读完本文，你将掌握 SCA 扫描的适用边界、三大包管理器的工件识别方法、完整的扫描命令与 SARIF 结果解读流程，并能结合仓库中的可复现实例（MASTG-DEMO-0052）独立完成一次 iOS 依赖安全审计。

为什么不能直接扫描 IPA：SCA 工具的固有局限

对移动应用做依赖漏洞审计时，一个直观的想法是直接扫描编译产物 IPA。但按照 MASTG 对 dependency-check 工具的描述（见 MASTG-TOOL-0131），SCA 工具通常无法直接扫描 IPA 或 APK，原因有二：

格式已被转换（Transformed format）：第三方库不再以原始形态存在，而是被编译进应用的二进制代码中。例如 iOS 应用中的静态库/框架会被链接进可执行文件，原始的文件边界与依赖标识随之消失。
元数据缺失（Lack of metadata）：在移动应用构建过程中，库的版本号、名称等信息往往被剥离或改写，扫描器无法据此关联到漏洞数据库。

因此，MASTG 的结论是：dependency-check 这类工具最适合在灰盒（gray-box）环境下使用——即至少能拿到构建配置文件时使用。对 iOS 而言，可以直接扫描 CocoaPods 的Podfile、Carthage 的Cartfile等构建文件来识别依赖；对 Android 则对应扫描build.gradle（可参考同系列的 MASTG-TECH-0131）。这构成了本技术指南的核心思路：与其扫描被"编译加工"后的 IPA，不如扫描依赖管理器留下的"原始工件"。

iOS 三大依赖管理器与对应的可扫描工件

iOS 生态中主流的依赖管理器有三个，MASTG 指南逐一给出了它们对应的、可用于 SCA 扫描的工件文件：

依赖管理器	可扫描的工件文件	说明
Carthage	`Cartfile.resolved`	记录已解析并锁定的依赖版本
CocoaPods	`Podfile.lock`或`*.podspec`	Lock 文件锁定精确版本，podspec 描述单个库的元信息
SwiftPM（Swift Package Manager）	`Package.swift`或`Package.resolved`	`Package.resolved`是解析后的锁定清单，`Package.swift`为包描述

需要特别留意的是，开发者可能同时使用多个依赖管理器（例如 CocoaPods 管理一部分库、SwiftPM 管理另一部分），因此审计时可能需要分别运行多次扫描，覆盖每一种管理器留下的工件。

这些工件之所以可被扫描，是因为它们以 Common Platform Enumeration (CPE) 格式列出依赖及其版本。CPE 信息会随依赖被打包进 iOS 应用；扫描工具据此将版本与 National Vulnerability Database（NVD）等漏洞数据库比对，进而找出已知漏洞（CVE）。

工具链准备：dependency-check、NVD API Key 与 SARIF Viewer

执行扫描前需要准备三样东西：

dependency-check（@MASTG-TOOL-0131）：一款开源的软件成分分析（SCA）工具，其目标是检测项目依赖中已公开披露的漏洞。MASTG 官方工具页 MASTG-TOOL-0131 明确记录它同时支持 Carthage、CocoaPods 与 SwiftPM 三种分析器，但这些分析器目前被视为实验性（experimental）功能：它们能给出有效结果，但仍需更多测试来确保漏报/误报率处于可接受水平，因此运行命令时必须显式加上--enableExperimental开关。
NVD API Key：用于在扫描时向 NVD 拉取最新的 CVE 信息。需要在 NVD 官方的开发者页面提交申请获取 API Key。没有 Key 时无法完成实时漏洞数据同步，因此这是运行前的必要步骤。
SARIF Viewer（@MASTG-TOOL-0133）：扫描输出是 SARIF（Static Analysis Results Interchange Format）文件，MASTG 推荐使用 Visual Studio Code（VS Code）配合官方的 SARIF Viewer 插件来可视化查看——该插件的定位在 MASTG-TOOL-0133 工具页中有明确说明，所有已知漏洞会以 CVE 编号加描述的形式列出，便于逐条审查。

三种扫描命令的完整实操

MASTG 指南给出了三条命令模板，分别对应三种依赖管理器。核心参数含义如下：

--enableExperimental：启用实验性分析器（扫描 Swift/CocoaPods/Carthage 工件所必需）；
-f SARIF：指定输出格式为 SARIF；
--nvdApiKey <YOUR-API-KEY>：传入你的 NVD API Key；
-s <file>：指定待扫描的工件文件路径。

SwiftPM 项目——扫描Package.swift或Package.resolved：

$ dependency-check --enableExperimental -f SARIF --nvdApiKey <YOUR-API-KEY> -s Package.resolved

CocoaPods 项目——扫描Podfile.lock或*.podspec：

$ dependency-check --enableExperimental -f SARIF --nvdApiKey <YOUR-API-KEY> -s Podfile.lock

Carthage 项目——扫描Cartfile.resolved：

$ dependency-check --enableExperimental -f SARIF --nvdApiKey <YOUR-API-KEY> -s Cartfile.resolved

两条重要约束：

一次只能扫描一个文件：扫描 CocoaPods 或 Carthage 时，复用同一条命令、把-s指向对应的管理器文件即可；
无需整个工程：扫描依赖管理器生成的工件文件就够了，不需要访问完整的 Xcode 工程或源码——这正体现了本技术的灰盒友好特性。

实战验证：用仓库 Demo 复现一次 SwiftPM 扫描

仓库中的可复现示例 MASTG-DEMO-0052 完整演示了上述流程在真实 Xcode 工程上的落地，对应测试用例 MASTG-TEST-0273。其操作步骤与指南完全一致：

在 Xcode 工程的根目录运行 dependency-check，扫描 Package.resolved。Demo 附带的 run.sh 给出了脚本化的命令写法：

$NVD_API_KEY="YOUR_NVD_API" dependency-check --enableExperimental -f SARIF --nvdApiKey $NVD_API_KEY -s Package.resolved

扫描产出 SARIF 文件，用 VS Code 的 SARIF Viewer 插件打开，逐条审查报告中的漏洞实例。

Demo 的真实输出记录在 output.txt 中，展示了 SARIF 2.1.0 格式下每个漏洞条目的完整字段，包括：

rule.id：CVE 编号（如CVE-2020-9861、CVE-2022-1642）；
shortDescription/fullDescription：漏洞标题与详细说明，指明受影响组件（如pkg:swift/swift-nio@2.33.0）及其风险描述；
properties：CVSS 评分信息（如 CVSS v3 基础分、攻击向量、可利用性与影响评分）以及漏洞数据来源（source: NVD）。

从 Demo 的实际扫描结果看，示例依赖swift-nio至少存在 2 个已知漏洞：CVE-2022-3918 与 CVE-2022-1642，结论是应将该库升级到最新版本。同时 Demo 的评估环节特意强调：报告中可能包含误报（false positives），需要逐条人工复核——这与指南中"分析器处于实验阶段"的警告相互印证。

注意事项与误报处理

结合指南原文与 Demo 评估，实操中需记住以下几点：

多管理器并存：项目若同时使用多个依赖管理器，需分别扫描每种管理器留下的工件，避免漏扫；
实验性分析器：Swift/CocoaPods/Carthage 三类分析器在 dependency-check 中标记为 experimental，扫描结果可能包含漏报或误报，关键结论需人工确认；
结果复核：对每个上报的 CVE，应结合应用实际使用该依赖的方式判断其真实可利用性，而不是机械地全量升级；
只扫工件：无需把整个 Xcode 工程或源码暴露给扫描工具，工件文件足以完成版本识别与漏洞比对。

延伸：SBOM + Dependency-Track 的替代路径

除直接扫描工件文件外，MASTG 还提供了另一条 SCA 路径（详见 MASTG-TECH-0132）：使用 cdxgen（MASTG-TOOL-0134）为 SwiftPM 项目生成 CycloneDX 格式的软件物料清单（SBOM），再上传至 Dependency-Track（MASTG-TOOL-0132）这一组件分析平台进行持续跟踪。该方式适合需要持续性供应链风险管理的场景——Dependency-Track 通过 REST API 接收 SBOM，组织可在项目维度长期监控依赖风险。值得注意的限制是：目前 cdxgen 仅支持 SwiftPM 的 SBOM 生成，Carthage 与 CocoaPods 暂不支持，且不覆盖传递依赖（transitive dependencies）。相较而言，本文主讲的 dependency-check 工件扫描方式覆盖全部三大依赖管理器，更适合一次性、轻量级的灰盒审计；两条路径可根据团队所处的安全成熟度阶段组合使用。

小结

本指南的核心方法论可以浓缩为一句话：iOS 应用的依赖版本信息在编译进 IPA 时会被剥离，因此要转向依赖管理器留下的工件文件（Cartfile.resolved、Podfile.lock/*.podspec、Package.swift/Package.resolved）进行 SCA 扫描。借助 dependency-check 的实验性分析器、NVD API Key 与 VS Code SARIF Viewer，审计人员可以在不接触源码的情况下快速获得依赖的 CVE 清单；再结合仓库中的 MASTG-DEMO-0052 复现脚本与真实输出样例，即可把这一流程直接落地为可重复的日常安全测试环节。