企业级Nexus实践：守护软件供应链安全
Nexus Repository Manager（Sonatype Nexus）企业级实践指南（开源视角）
铁律：私有仓库不是“可选项”，而是软件供应链安全的底线。
一次直连公网拉包，可能让你在凌晨三点处理 Log4j 级别的全网告警。
一、Nexus 核心功能（开源企业必备）
Nexus 是业界标准的二进制制品仓库管理平台，支持多格式、多协议，核心能力如下：
| 功能 | 开源版（OSS） | 企业增强建议 |
|---|---|---|
| 统一制品存储 | 支持 Maven、npm、PyPI、Docker、Helm 等 | 按语言/团队划分仓库前缀（如 java-releases, fe-npm） |
| 依赖代理与缓存 | 代理 Maven Central、npmjs 等 | 配置 只读代理，禁止自动下载 SNAPSHOT（防污染） |
| 权限与安全控制 | 基础 RBAC + LDAP/SSO 集成 | 角色最小化：开发者仅可读 public-group，发布者需单独授权 |
| 漏洞扫描 | （仅 Pro 版） | 开源替代方案：集成 Dependency-Track + OWASP Dependency-Check |
| 高可用与灾备 | （仅 Pro） | OSS 可通过 NFS + 定时快照 实现基础灾备（/nexus-data 备份） |
| 审计与合规 | 操作日志（谁、何时、上传/下载何物） | 日志接入 ELK 或 Loki，设置“高危操作”告警（如删除 release） |
关键建议：即使使用 OSS 版，也必须启用 匿名访问关闭 + 强制 HTTPS，防止内部资产外泄。
二、三大核心仓库类型（企业标准配置）
1. 代理仓库（Proxy Repository）
- 作用：安全代理公共仓库（如
repo1.maven.org,registry.npmjs.org）。 - 行为：
- 首次请求时从公网拉取并缓存；
- 后续请求直接返回本地缓存，构建速度提升 5–10 倍（实测数据）。
- 企业规范：
- 禁止直连公网：所有 CI/CD 和开发者必须通过代理仓库拉取依赖；
- 黑名单机制：在 Nexus 中配置 Routing Rules，拦截高危 groupId（如
com.github.fakelib）； - 缓存策略：对
SNAPSHOT设置 TTL（如 24h），避免长期占用存储。
2. 宿主仓库（Hosted Repository）
- 作用：存储企业自研构件（JAR、Docker 镜像、npm 包等）。
- 标准分类（命名规范）：
internal-releases：正式版本（如1.2.0），不可变（Immutable）；internal-snapshots：开发快照（如1.2.1-SNAPSHOT），允许覆盖；thirdparty：无法从公网获取的闭源 JAR（如 Oracle JDBC），手动上传。
- 安全要求：
- 禁止上传含敏感信息的制品（如
application-prod.yml打包进 JAR）； - 发布流程必须走 CI（如
mvn deploy），禁止手动上传生产包。
- 禁止上传含敏感信息的制品（如
3. 仓库组（Repository Group）
- 作用：聚合多个仓库为单一入口，简化客户端配置。
- 推荐组合（Maven 示例）：
maven-public (group) ├── maven-central (proxy) ├── aliyun-maven (proxy) # 国内加速 ├── internal-releases (hosted) └── internal-snapshots (hosted) - 查找顺序：从上到下，优先使用内部版本（如你发布了
com.example:utils:1.0，则不会拉取公网同名包）。 - 开发者体验：
pom.xml中 无需声明任何<repository>，所有配置下沉到settings.xml。
三、为什么企业必须使用私有仓库？（五大不可逆理由）
| 风险 | 无私有仓库 | 有 Nexus 私有仓库 |
|---|---|---|
| 构建不可靠 | Maven Central 波动 → CI 失败 | 本地缓存 → 构建成功率 >99.9% |
| 安全失控 | 引入含 CVE 的包（如 log4j 2.14.1） | 通过 人工审核 + 自动扫描 拦截高危版本 |
| 资产泄露 | 自研中间件误传至 Maven Central | 宿主仓库内网隔离，公网不可达 |
| 协作低效 | “微信发 JAR” → 版本混乱 | 统一发布/引用，版本可追溯 |
| 合规审计难 | 无法回答“谁用了哪个依赖” | 完整审计日志 + 制品元数据（SBOM 基础） |
真实教训：某公司因未用私有仓库，CI 直连 JCenter（已停服），导致 2021 年 3 月全量构建失败，损失数小时大促准备时间。
四、立即落地：开源企业标准配置
✅ settings.xml 模板（开发者 & CI 通用）
<settings><mirrors><mirror><id>nexus-public</id><mirrorOf>*</mirrorOf><url>http://nexus.yourcompany.com/repository/maven-public/</url></mirror></mirrors><servers><server><id>internal-releases</id><username>ci-deployer</username><password>${env.NEXUS_PASSWORD}</password></server></servers><profiles><profile><id>nexus</id><repositories><repository><id>central</id><url>http://central</url> <!-- 被 mirror 覆盖，仅占位 --><releases><enabled>true</enabled></releases><snapshots><enabled>true</enabled></snapshots></repository></repositories></profile></profiles><activeProfiles><activeProfile>nexus</activeProfile></activeProfiles>
</settings>CI 流水线检查项（Jenkins/GitLab CI）
# 检查 pom.xml 是否包含非法 repository（防绕过）
if grep -r "<repository>" pom.xml | grep -v "nexus.yourcompany.com"; thenecho " 禁止直连公网仓库！"exit 1
fi# 发布到 releases 仓库（仅 tag 触发）
mvn deploy -DaltDeploymentRepository=internal-releases::default::http://nexus.../internal-releases行动建议（现在立刻做！）
- 部署 Nexus OSS：用 Docker 5 分钟启动：
docker run -d -p 8081:8081 --name nexus sonatype/nexus3 - 创建标准仓库组：按上述
maven-public结构配置； - 全团队切换
settings.xml：通过 Ansible 或配置管理工具统一下发； - 集成漏洞扫描：部署 Dependency-Track，每日扫描仓库中所有制品。
记住：Nexus 不是“又一个工具”，而是你软件供应链的“国境线”。
在这里设卡，比在生产环境救火容易一万倍。
现在立刻去检查你的 pom.xml —— 如果还有 <repository> 指向 repo1.maven.org，马上改！