performing-sca-dependency-scanning-with-snyk
本技能涵盖使用 Snyk 实施软件成分分析(SCA, Software Composition Analysis),在 CI/CD 流水线中检测存在漏洞的开源依赖项。内容包括扫描包清单和锁文件、自动修复拉取请求生成、许可证合规检查、已部署应用程序的持续监控,以及与 GitHub、GitLab 和 Jenkins 流水线的集成。
Best use case
performing-sca-dependency-scanning-with-snyk is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
本技能涵盖使用 Snyk 实施软件成分分析(SCA, Software Composition Analysis),在 CI/CD 流水线中检测存在漏洞的开源依赖项。内容包括扫描包清单和锁文件、自动修复拉取请求生成、许可证合规检查、已部署应用程序的持续监控,以及与 GitHub、GitLab 和 Jenkins 流水线的集成。
Teams using performing-sca-dependency-scanning-with-snyk should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/performing-sca-dependency-scanning-with-snyk/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How performing-sca-dependency-scanning-with-snyk Compares
| Feature / Agent | performing-sca-dependency-scanning-with-snyk | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
本技能涵盖使用 Snyk 实施软件成分分析(SCA, Software Composition Analysis),在 CI/CD 流水线中检测存在漏洞的开源依赖项。内容包括扫描包清单和锁文件、自动修复拉取请求生成、许可证合规检查、已部署应用程序的持续监控,以及与 GitHub、GitLab 和 Jenkins 流水线的集成。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 使用 Snyk 执行 SCA 依赖扫描
## 适用场景
- 当应用程序使用可能包含已知漏洞的开源包时
- 当合规要求需要追踪和修复存在漏洞的依赖项时(PCI DSS、SOC 2)
- 当 CI/CD 中需要自动修复 PR 来处理存在漏洞的依赖项时
- 当许可证合规需要了解开源许可证义务时
- 当已部署依赖项需要针对新披露漏洞进行持续监控时
**不适用于**扫描专有应用程序代码中的逻辑漏洞(使用 SAST),运行时漏洞检测(使用 DAST),或单独进行容器操作系统包扫描(使用 Trivy 作为免费替代方案)。
## 前置条件
- Snyk 账户(免费层级涵盖每月最多 200 次开源测试)
- 已安装 Snyk CLI 或配置 Snyk GitHub/GitLab 集成
- 已使用 API 认证令牌设置 SNYK_TOKEN 环境变量
- 包含支持的包清单的项目:package.json、requirements.txt、pom.xml、go.mod、Gemfile 等
## 工作流程
### 步骤 1:安装并认证 Snyk CLI
```bash
# 安装 Snyk CLI
npm install -g snyk
# 通过 Snyk 认证
snyk auth $SNYK_TOKEN
# 测试连接
snyk test --json | jq '.summary'
```
### 步骤 2:在 CI/CD 流水线中扫描依赖项
```yaml
# .github/workflows/dependency-scan.yml
name: Dependency Security Scan
on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
- cron: '0 8 * * 1' # 每周一上午 8 点
jobs:
snyk-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Run Snyk to check for vulnerabilities
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: >
--severity-threshold=high
--fail-on=upgradable
--json-file-output=snyk-results.json
- name: Upload results to Snyk
if: always()
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
command: monitor
args: --project-name=${{ github.repository }}
- name: Upload SARIF
if: always()
run: |
npx snyk-to-html -i snyk-results.json -o snyk-report.html
```
### 步骤 3:配置 Snyk 支持多种语言
```bash
# Python 项目扫描
snyk test --file=requirements.txt --severity-threshold=high --json > snyk-python.json
# Java/Maven 项目
snyk test --file=pom.xml --severity-threshold=medium --json > snyk-java.json
# Go 模块扫描
snyk test --file=go.mod --severity-threshold=high --json > snyk-go.json
# Docker 镜像依赖扫描
snyk container test myapp:latest --severity-threshold=high --json > snyk-container.json
# 单体仓库:扫描所有项目
snyk test --all-projects --severity-threshold=high --json > snyk-all.json
# IaC 扫描(附加功能)
snyk iac test terraform/ --severity-threshold=medium --json > snyk-iac.json
```
### 步骤 4:为组织配置 Snyk 策略
```yaml
# .snyk 策略文件
version: v1.25.0
ignore:
SNYK-JS-LODASH-1018905:
- '*':
reason: "lodash 中的原型污染。在我们的使用场景中无法利用——用户输入不会到达受影响的函数。"
expires: 2026-06-01T00:00:00.000Z
created: 2026-02-23T00:00:00.000Z
SNYK-PYTHON-REQUESTS-6241864:
- '*':
reason: "requests 重定向处理中的 SSRF。已通过代理层的允许列表缓解。"
expires: 2026-04-01T00:00:00.000Z
patch: {}
# CI 失败的严重性阈值
failOnSeverity: high
```
### 步骤 5:启用自动修复拉取请求
```bash
# Snyk fix:为存在漏洞的依赖项生成修复 PR
snyk fix --dry-run # 预览更改
# 本地应用修复
snyk fix
# 通过 Snyk 控制台启用自动修复 PR:
# 1. 导航到组织设置 > 集成 > GitHub
# 2. 启用"自动修复拉取请求"
# 3. 设置"仅修复直接依赖"或"修复直接和传递依赖"
# 4. 配置目标分支(main 或 develop)
```
### 步骤 6:许可证合规扫描
```bash
# 检查许可证合规性
snyk test --json | jq '.licensesPolicy'
# 通过组织设置配置 Snyk 许可证策略:
# - 批准的许可证:MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC
# - 限制的许可证:GPL-3.0, AGPL-3.0(著作权风险)
# - 未知许可证:标记为需人工审查
```
## 核心概念
| 术语 | 定义 |
|------|------|
| SCA | 软件成分分析(Software Composition Analysis)——识别开源依赖项中的漏洞和许可证风险 |
| 传递依赖(Transitive Dependency) | 直接依赖项的依赖项,开发者通常看不到,但仍是漏洞攻击面 |
| 修复 PR(Fix PR) | Snyk 自动生成的拉取请求,将存在漏洞的依赖项升级到已修复版本 |
| Snyk Monitor | 持续监控模式,监视已部署项目中的新披露漏洞 |
| 漏洞利用成熟度(Exploit Maturity) | Snyk 对漏洞是否存在已知利用程序、概念验证或无已知利用的评估 |
| 可达漏洞(Reachable Vulnerability) | 应用程序代码实际调用到的函数中存在的漏洞,而非仅存在于依赖项中 |
| 许可证策略(License Policy) | 组织级规则,定义哪些开源许可证被批准、限制或需要审查 |
## 工具与系统
- **Snyk Open Source**:SCA 工具,支持 10+ 语言生态系统的依赖扫描
- **Snyk CLI**:用于本地和 CI/CD 依赖扫描的命令行界面
- **Snyk Advisor**:评估维护状况、流行度和安全信号的包健康度评分工具
- **OWASP Dependency-Check**:使用 NVD 数据进行漏洞匹配的免费替代 SCA 工具
- **npm audit / pip-audit**:用于基本漏洞检查的语言特定内置审计工具
## 常见场景
### 场景:分诊关键传递依赖漏洞
**场景背景**:Snyk 报告传递依赖项中存在严重 RCE 漏洞(Java 应用程序中的 log4j)。直接依赖项尚未发布补丁。
**方法**:
1. 使用 `snyk test --json` 并检查依赖路径,识别哪个直接依赖项引入了存在漏洞的传递依赖
2. 检查漏洞利用成熟度:如果为"Mature"或"Proof of Concept",立即优先处理
3. 如果不存在直接修复,使用 Snyk 的补丁机制或在构建配置中覆盖传递版本
4. 对于 Maven:添加 `<dependencyManagement>` 部分以强制使用传递依赖的安全版本
5. 对于 npm:在 package.json 中添加 `overrides` 部分以固定安全版本
6. 如果尚无可用补丁,添加带有到期日期的 Snyk 忽略
7. 监控直接依赖项是否发布了更新传递依赖版本的版本
**常见陷阱**:以"我们不直接使用该函数"为由忽略传递漏洞是有风险的。攻击者可以跨依赖边界链接漏洞。版本覆盖可能会破坏直接依赖项和传递依赖项之间的 API 兼容性。
## 输出格式
```
Snyk 依赖扫描报告
=============================
项目: org/web-application
清单: package.json
依赖项: 342(47 直接,295 传递)
扫描日期: 2026-02-23
漏洞摘要:
严重: 1 (1 可修复)
高危: 4 (3 可修复)
中危: 12 (8 可修复)
低危: 23 (15 可修复)
严重:
SNYK-JS-EXPRESS-1234567
包: express@4.17.1(直接)
严重性: Critical (CVSS 9.8)
利用: Mature
修复: 升级至 express@4.21.0
路径: express@4.17.1
高危:
SNYK-JS-JSONWEBTOKEN-5678901
包: jsonwebtoken@8.5.1(传递)
严重性: High (CVSS 7.6)
利用: Proof of Concept
修复: 升级 passport@0.7.0(会同步升级 jsonwebtoken)
路径: passport@0.6.0 > jsonwebtoken@8.5.1
许可证问题:
[RESTRICTED] GPL-3.0: some-package@1.2.3(通过 other-pkg 传递)
质量门控: 失败(1 个严重漏洞有可用修复)
```Related Skills
scanning-network-with-nmap-advanced
使用 Nmap 的脚本引擎、时序控制、规避技术和输出解析,对授权目标网络执行高级网络侦察, 发现主机、枚举服务、检测漏洞并识别操作系统。
scanning-kubernetes-manifests-with-kubesec
使用 Kubesec 对 Kubernetes 资源清单执行安全风险分析,识别错误配置、权限提升风险以及与安全最佳实践的偏差。
scanning-infrastructure-with-nessus
Tenable Nessus 是业界领先的漏洞扫描器,用于识别网络基础设施(包括服务器、工作站、网络设备和操作系统)中的安全弱点。
scanning-docker-images-with-trivy
Trivy 是 Aqua Security 开源的综合性漏洞扫描器,用于检测容器镜像中操作系统软件包、语言特定依赖项的漏洞、错误配置、密钥和许可证违规,并集成到 CI/CD 流水线,支持 SARIF、CycloneDX 和 SPDX 等多种输出格式。
scanning-containers-with-trivy-in-cicd
本技能涵盖将 Aqua Security 的 Trivy 扫描器集成到 CI/CD 流水线中,用于全面的容器镜像漏洞检测。包括扫描 Docker 镜像中的操作系统包和应用依赖 CVE、检测 Dockerfile 中的错误配置、扫描文件系统和 Git 仓库,以及建立基于严重性的质量门禁以阻止有漏洞的镜像部署。
scanning-container-images-with-grype
使用 Anchore Grype 扫描容器镜像的已知漏洞(Vulnerability),支持基于 SBOM 的匹配和可配置的严重性阈值。
performing-yara-rule-development-for-detection
通过识别可执行文件中的唯一字节模式、字符串和行为指标,开发精准的 YARA 恶意软件检测规则,同时将误报率降至最低。
performing-wireless-security-assessment-with-kismet
使用 Kismet 通过被动射频监控进行无线网络安全评估,检测流氓接入点(Rogue AP)、隐藏 SSID、弱加密和未授权客户端。
performing-wireless-network-penetration-test
执行无线网络渗透测试,通过捕获握手包、破解 WPA2/WPA3 密钥、检测流氓接入点以及使用 Aircrack-ng 和相关工具测试无线网络分段,评估 WiFi 安全性。
performing-windows-artifact-analysis-with-eric-zimmerman-tools
使用 Eric Zimmerman 的开源 EZ Tools 套件(包括 KAPE、MFTECmd、PECmd、LECmd、JLECmd 和 Timeline Explorer)执行全面的 Windows 取证制品分析,解析注册表 hive、预取文件、事件日志和文件系统元数据。
performing-wifi-password-cracking-with-aircrack
在授权无线安全评估中捕获 WPA/WPA2 握手包,并使用 aircrack-ng、hashcat 和字典攻击进行离线密码破解, 以评估密码短语强度和无线网络安全状况。
performing-web-cache-poisoning-attack
在授权安全测试期间,通过未纳入缓存键的头部和参数毒化缓存响应,利用 Web 缓存机制向其他用户投递恶意内容。