20、构建安全：依赖漏洞扫描、供应链安全、签名密钥保护、构建环境隔离
说实话，构建安全这个话题，很多团队都是出了事才想起来补课。我见过不少项目，代码写得挺漂亮，但构建环节全是窟窿——第三方库随便加、签名密钥明文存、构建环境谁都能碰。这就像你装修了个豪华客厅，但大门没锁。
今天咱们就把这四块硬骨头啃下来：依赖漏洞怎么扫、供应链怎么防篡改、签名密钥怎么护住、构建环境怎么隔离。嗯，每一条都是我踩过坑之后总结出来的。
核心观点：构建安全不是运维的事，也不是安全团队的事。它是每个Android开发者的基本功。你写的代码再安全，如果构建管道被人下了毒，一切都白搭。
20.1 依赖漏洞扫描：别让第三方库成为定时炸弹
我个人习惯，每次引入新依赖之前，先问自己三个问题：这个库还维护吗？有没有已知漏洞？它的传递依赖安不安全？
说白了，你依赖的库可能又依赖了别的库。那个“别的库”可能已经爆出了高危漏洞，而你完全不知情。
20.1.1 OWASP Dependency-Check
OWASP Dependency-Check 是个开源工具，它会分析你的项目依赖，然后跟国家漏洞数据库（NVD）比对。我一般在 CI 里把它配成强制门禁——有高危漏洞就直接让构建失败。
用法很简单，在 build.gradle 里加个插件：
// 项目级 build.gradle
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'org.owasp:dependency-check-gradle:9.0.9'
}
}
// 模块级 build.gradle
apply plugin: 'org.owasp.dependencycheck'
dependencyCheck {
failBuildOnCVSS = 7 // CVSS 7分以上直接失败
suppressionFile = 'dependency-check-suppressions.xml' // 误报忽略文件
formats = ['HTML', 'JSON']
}运行 ./gradlew dependencyCheckAnalyze，它会生成一份报告。里面会列出每个依赖的 CVE 编号、严重等级、以及修复建议。
我的经验：第一次跑这个工具，大概率会扫出一堆漏洞。别慌，很多是低危或者误报。你需要维护一个 suppression.xml 文件，把确认安全的漏洞忽略掉。但记住，每周要重新审视一次这个文件。
20.1.2 Snyk：更智能的漏洞扫描
Snyk 跟 OWASP 的区别在于，它不光告诉你“有漏洞”，还会告诉你“怎么修”。而且它支持实时监控——你合并代码后，Snyk 会自动扫描新的依赖。
我建议把 Snyk 集成到 GitHub Actions 或者 GitLab CI 里。配置大概长这样：
# .github/workflows/snyk.yml
name: Snyk Security Scan
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Snyk
uses: snyk/actions/gradle@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high为什么要用两个工具？我个人习惯是：OWASP 做本地开发时的快速检查，Snyk 做 CI 里的持续监控。两者互补，不冲突。
20.2 构建供应链安全：从源头到产线都要防
供应链攻击这几年越来越猖獗。你想想看，攻击者不需要攻破你的代码，只需要在你依赖的某个库里藏一段恶意代码，就能一锅端。
我记得 2021 年有个事件，某个 npm 包被植入了后门，影响了成千上万个项目。Android 生态也一样，Gradle 插件、Maven 仓库、甚至 Android SDK 本身，都可能成为攻击目标。
20.2.1 依赖锁定与哈希校验
Gradle 默认会缓存依赖，但缓存可能被污染。我建议开启依赖锁定功能：
// 在 gradle.lockfile 中锁定所有依赖版本
dependencyLocking {
lockAllConfigurations()
}
// 生成锁文件
// ./gradlew dependencies --write-locks锁文件生成后，把它提交到 Git 仓库。每次构建时，Gradle 会校验依赖的哈希值是否跟锁文件一致。如果有人篡改了远程仓库的包，构建就会失败。
注意：锁文件不是万能的。如果攻击者同时篡改了锁文件和仓库里的包，你依然会中招。所以还需要配合签名验证。
20.2.2 使用私有仓库与镜像
我见过不少团队直接从 jcenter（已停服）或者未经验证的第三方仓库拉依赖。这太危险了。正确的做法是：
- 搭建内部 Maven 仓库（比如 Nexus 或 Artifactory）
- 所有外部依赖先同步到内部仓库
- 内部仓库只允许经过安全审核的版本通过
这样，你的构建环境根本不接触外网，依赖来源完全可控。
20.3 签名密钥保护：丢了密钥等于丢了身份
Android 应用的签名密钥，说白了就是你的数字身份证。密钥丢了，你连自己发的更新包都签不了。更可怕的是，如果密钥被偷，攻击者可以用它签名恶意应用，冒充你的身份。
我曾经接手过一个项目，签名密钥就明文写在 local.properties 里，还提交到了 Git 仓库。嗯，那感觉就像把银行卡密码贴在ATM机上。
20.3.1 密钥存储的最佳实践
| 做法 | 推荐等级 | 说明 |
|---|---|---|
| 密钥文件放在 CI 的 secrets 中 | ✅ 推荐 | 本地开发用 debug 密钥，发布用 CI 管理的 release 密钥 |
| 使用 Android Keystore 系统 | ✅ 推荐 | 硬件级保护，密钥无法被导出 |
| 密钥文件加密后提交到 Git | ⚠️ 谨慎 | 需要配合解密脚本，且解密密码要单独管理 |
| 密钥文件明文提交到 Git | ❌ 禁止 | 这是最危险的做法，没有之一 |
我个人推荐的做法是：在 CI 环境变量里配置密钥库的 base64 编码，构建时再解码成文件。这样密钥既不在代码里，也不在本地磁盘上。
// build.gradle 中的签名配置
android {
signingConfigs {
release {
storeFile = file(System.getenv("KEYSTORE_FILE") ?: "debug.keystore")
storePassword = System.getenv("KEYSTORE_PASSWORD") ?: "android"
keyAlias = System.getenv("KEY_ALIAS") ?: "androiddebugkey"
keyPassword = System.getenv("KEY_PASSWORD") ?: "android"
}
}
}20.3.2 密钥轮换与过期管理
密钥不是永久的。我建议每年轮换一次签名密钥。Android 支持密钥轮换，但要注意：新密钥签名的应用包名必须跟旧密钥一致，否则用户无法升级。
轮换步骤：
- 用旧密钥生成一个签名轮换证书
- 在 Google Play Console 中上传新密钥
- 用新密钥签名下一个版本
避坑指南：我曾经因为忘记备份旧密钥，导致应用无法发布紧急更新。后来我养成了习惯：密钥文件一式三份，分别存在公司保险柜、云存储（加密后）和离线硬盘里。
20.4 构建环境隔离：别让脏环境污染你的构建
构建环境隔离，说白了就是让每次构建都在一个干净、可复现的环境里运行。你想想看，如果构建机器上同时跑着好几个项目，依赖版本互相冲突，或者有人不小心装了恶意软件，你的构建结果还能信吗？
20.4.1 使用 Docker 容器化构建
Docker 是目前最成熟的构建环境隔离方案。每个构建任务启动一个全新的容器，构建完就销毁。环境完全一致，不受宿主机影响。
一个典型的 Android 构建 Dockerfile：
FROM openjdk:17-jdk
# 安装 Android SDK 和 Gradle
RUN apt-get update && apt-get install -y wget unzip
RUN wget https://dl.google.com/android/repository/commandlinetools-linux-9477386_latest.zip
RUN unzip commandlinetools-linux-*.zip -d /opt/android-sdk
ENV ANDROID_SDK_ROOT=/opt/android-sdk
ENV PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/latest/bin
# 接受许可证并安装必要组件
RUN yes | sdkmanager --licenses
RUN sdkmanager "platforms;android-34" "build-tools;34.0.0"
# 设置工作目录
WORKDIR /app
COPY . .
# 执行构建
CMD ["./gradlew", "assembleRelease"]在 CI 里，每次构建都基于这个镜像启动新容器。构建产物从容器里拷贝出来，容器直接销毁。
20.4.2 构建环境的网络隔离
有些团队会把构建环境放在内网，不直接访问外网。依赖只能从内部仓库拉取。这样做的好处是：即使某个外部仓库被攻破，你的构建也不会受影响。
但要注意，网络隔离不能太死板。比如 Gradle 插件需要从 Gradle Plugin Portal 下载，Android SDK 需要从 Google 的服务器更新。你需要维护一个白名单，或者定期同步到内部镜像。
知识体系总览
下面这张图，把构建安全的四个维度串起来了。你可以把它当作一个检查清单：
总结
构建安全这件事，说白了就是四个字：防、控、管、隔。依赖漏洞要防，供应链要控，密钥要管，环境要隔。每一条单独拿出来都不难，难的是把它们串成一个体系，并且坚持执行。
我见过太多团队，安全策略写得天花乱坠，但实际执行起来漏洞百出。别让你的项目成为下一个反面教材。从今天开始，把依赖扫描加进 CI，把密钥从代码里移走，把构建环境装进 Docker 容器。嗯，这些事花不了多少时间，但能救你于水火之中。