name: 漏洞管理 description: 在CI/CD管道中实施多层面安全扫描（容器、SAST、DAST、SCA、秘密检测），生成软件物料清单（SBOM），并进行基于风险的漏洞优先级划分。用于构建DevSecOps工作流、确保合规性或建立容器部署安全门。

漏洞管理

在容器、源代码、依赖项和运行应用程序中实施全面的漏洞检测和修复工作流。本技能涵盖多层面扫描策略、SBOM生成（CycloneDX和SPDX）、使用CVSS/EPSS/KEV的基于风险优先级划分以及CI/CD安全门模式。

何时使用此技能

在以下情况调用此技能：

在CI/CD管道中构建安全扫描
生成软件物料清单（SBOMs）以符合合规性
使用基于风险的方法优先处理漏洞修复
实施安全门（在关键漏洞时使构建失败）
在部署前扫描容器镜像
检测秘密、错误配置或代码漏洞
建立DevSecOps实践和自动化
满足法规要求（SBOM指令、行政命令14028）

多层面扫描策略

漏洞管理需要在多个层面进行扫描。每个层面检测不同类型的安全问题。

层面概述

容器镜像扫描

检测操作系统包、语言依赖项和二进制文件中的漏洞
工具：Trivy（全面）、Grype（准确度重点）、Snyk Container（商业）
时机：每次容器构建、基础镜像选择、注册表准入控制

SAST（静态应用程序安全测试）

分析源代码以在运行时前发现安全缺陷
工具：Semgrep（快速、语义）、Snyk Code（开发者优先）、SonarQube（企业级）
时机：每次提交、PR检查、主分支保护

DAST（动态应用程序安全测试）

测试运行应用程序的漏洞（黑盒测试）
工具：OWASP ZAP（开源）、StackHawk（CI/CD原生）、Burp Suite（手动+自动）
时机：预部署环境测试、API验证、认证测试

SCA（软件成分分析）

分析第三方依赖项以查找已知漏洞
工具：Dependabot（GitHub原生）、Renovate（高级自动化）、Snyk Open Source（商业）
时机：每次构建、依赖项更新、许可证审计

秘密扫描

防止秘密被提交到源代码
工具：Gitleaks（快速、可配置）、TruffleHog（熵检测）、GitGuardian（商业）
时机：预提交钩子、仓库扫描、CI/CD工件检查

快速工具选择

容器镜像 → Trivy（默认选择）或 Grype（准确度重点）
源代码 → Semgrep（开源）或 Snyk Code（商业）
运行应用程序 → OWASP ZAP（开源）或 StackHawk（CI/CD原生）
依赖项 → Dependabot（GitHub）或 Renovate（高级自动化）
秘密 → Gitleaks（开源）或 GitGuardian（商业）

详细工具选择指南，请参见 references/tool-selection.md。

SBOM生成

软件物料清单（SBOMs）提供软件组件和依赖项的完整清单。为合规性和安全透明度所需。

CycloneDX vs. SPDX

CycloneDX（推荐用于DevSecOps）

安全重点，由OWASP维护
原生漏洞引用
快速、轻量级（JSON/XML/ProtoBuf）
最适合：DevSecOps管道、漏洞跟踪

SPDX（推荐用于法律/合规）

许可证合规重点，ISO标准（ISO/IEC 5962:2021）
全面的法律元数据
政府/国防首选格式
最适合：法律团队、合规审计、联邦要求

生成SBOMs

使用Trivy（CycloneDX或SPDX）：

# CycloneDX格式（推荐用于安全）
trivy image --format cyclonedx --output sbom.json myapp:latest

# SPDX格式（用于合规）
trivy image --format spdx-json --output sbom-spdx.json myapp:latest

# 扫描SBOM（比重新扫描镜像更快）
trivy sbom sbom.json --severity HIGH,CRITICAL

使用Syft（高准确度）：

# 生成CycloneDX
syft myapp:latest -o cyclonedx-json=sbom.json

# 生成SPDX
syft myapp:latest -o spdx-json=sbom-spdx.json

# 管道传输到Grype进行扫描
syft myapp:latest -o json | grype

全面的SBOM模式和存储策略，请参见 references/sbom-guide.md。

漏洞优先级划分

并非所有漏洞都需要立即处理。使用CVSS、EPSS和KEV基于实际风险进行优先级划分。

现代基于风险优先级划分

步骤1：收集指标

指标	来源	目的
CVSS基础分数	NVD、供应商公告	漏洞严重性（0-10）
EPSS分数	FIRST.org API	利用概率（0-1）
KEV状态	CISA KEV目录	主动利用的CVE
资产关键性	内部CMDB	如果受损的业务影响
暴露度	网络拓扑	互联网可访问 vs. 内部

步骤2：计算优先级

优先级分数 = (CVSS × 0.3) + (EPSS × 100 × 0.3) + (KEV × 50) + (资产 × 0.2) + (暴露度 × 0.2)

KEV: 如果在KEV目录中为1，否则为0
资产: 1（关键）、0.7（高）、0.4（中）、0.1（低）
暴露度: 1（互联网可访问）、0.5（内部）、0.1（隔离）

步骤3：应用SLA层级

优先级	标准	SLA	行动
P0 - 关键	KEV + 互联网可访问 + 关键资产	24小时	紧急立即修补
P1 - 高	CVSS ≥ 9.0 或 (CVSS ≥ 7.0 且 EPSS ≥ 0.1)	7天	在冲刺中优先处理，尽快修补
P2 - 中	CVSS 7.0-8.9 或 EPSS ≥ 0.05	30天	正常冲刺规划
P3 - 低	CVSS 4.0-6.9，EPSS < 0.05	90天	积压，维护窗口
P4 - 信息	CVSS < 4.0	无SLA	跟踪，机会性处理

示例：Log4Shell（CVE-2021-44228）

CVSS: 10.0
EPSS: 0.975（97.5% 利用概率）
KEV: 是（CISA目录）
资产: 关键（支付API）
暴露度: 互联网可访问

优先级分数 = (10 × 0.3) + (97.5 × 0.3) + 50 + (1 × 0.2) + (1 × 0.2) = 82.65
结果：P0 - 关键（24小时SLA）

完整的优先级划分框架和自动化脚本，请参见 references/prioritization-framework.md。

CI/CD集成模式

多阶段安全管道

在管道阶段实施渐进式安全门：

阶段1：预提交（开发者工作站）

工具：秘密扫描（Gitleaks）、SAST（Semgrep）
阈值：阻止高置信度秘密、关键SAST发现
速度：< 10秒

阶段2：拉取请求（CI管道）

工具：SAST、SCA、秘密扫描
阈值：无关键/高漏洞、无秘密
速度：< 5分钟
操作：阻止PR合并直至修复

阶段3：构建（CI管道）

工具：容器扫描（Trivy）、SBOM生成
阈值：生产依赖项中无关键漏洞
工件：SBOM存储、扫描结果上传
速度：< 2分钟
操作：关键发现时构建失败

阶段4：预部署（预发布环境）

工具：DAST、集成测试
阈值：无关键/高DAST发现
速度：10-30分钟
操作：门控到生产部署

阶段5：生产（运行时）

工具：持续扫描、运行时监控
阈值：在已部署镜像中检测到新CVE时警报
操作：警报安全团队，计划修补

示例：GitHub Actions多阶段扫描

name: 安全扫描管道

on: [push, pull_request]

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          extra_args: --only-verified

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit

  container:
    runs-on: ubuntu-latest
    needs: [secrets, sast]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .

      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: HIGH,CRITICAL
          exit-code: 1

      - name: 生成SBOM
        run: |
          trivy image --format cyclonedx \
            --output sbom.json myapp:${{ github.sha }}

      - uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

完整的CI/CD模式（GitLab CI、Jenkins、Azure Pipelines），请参见 references/ci-cd-patterns.md。

使用Trivy进行容器扫描

Trivy是容器扫描的推荐默认工具：全面、快速且CI/CD原生。

基本用法

# 扫描容器镜像
trivy image alpine:latest

# 使用严重性过滤器扫描
trivy image --severity HIGH,CRITICAL alpine:latest

# 发现时失败（用于CI/CD）
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

# 生成SBOM
trivy image --format cyclonedx --output sbom.json alpine:latest

# 扫描文件系统
trivy fs /path/to/project

# 扫描Kubernetes清单
trivy config deployment.yaml

配置（.trivy.yaml）

severity: HIGH,CRITICAL
exit-code: 1
ignore-unfixed: true  # 仅在可修复漏洞时失败
vuln-type: os,library
skip-dirs:
  - node_modules
  - vendor
ignorefile: .trivyignore

忽略误报（.trivyignore）

# 误报
CVE-2023-12345

# 接受风险并附理由
CVE-2023-67890  # 风险接受：在我们的用例中不可利用

# 开发依赖项（不在生产中）
CVE-2023-11111  # 仅开发依赖项

GitHub Actions集成

- name: Trivy扫描
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: HIGH,CRITICAL
    exit-code: 1

- name: 上传到GitHub安全
  uses: github/codeql-action/upload-sarif@v2
  if: always()
  with:
    sarif_file: trivy-results.sarif

替代方案：Grype用于准确度

Grype侧重于最小化误报，并与Syft配合用于SBOM生成。

重要提示： 使用Grype v0.104.1或更高版本（早期版本中凭证泄露CVE-2025-65965已修补）。

基本用法

# 扫描容器镜像
grype alpine:latest

# 使用严重性阈值扫描
grype alpine:latest --fail-on high

# 扫描SBOM（更快）
grype sbom:./sbom.json

# Syft + Grype工作流
syft alpine:latest -o json | grype --fail-on critical

何时使用Grype

项目对误报敏感
SBOM优先工作流（使用Syft生成，Grype扫描）
需要第二意见验证
Anchore生态系统用户

完整的工具比较和选择标准，请参见 references/tool-selection.md。

安全门和阈值

渐进式阈值策略

通过渐进式门平衡安全性和开发速度。为PR检查（快速、高/关键）、构建（全面）和部署（严格、仅关键）配置不同阈值。

策略即代码

使用OPA（开放策略代理）进行自动化策略执行。创建策略以拒绝关键漏洞、强制执行KEV目录检查并实施环境特定规则。

完整的策略模式、基线检测和OPA示例，请参见 references/policy-as-code.md。

修复工作流

自动化修复

设置自动化工作流以每日扫描、提取可修复漏洞、更新依赖项并自动创建修复拉取请求。

SLA跟踪

跟踪漏洞修复相对于SLA目标（P0：24小时、P1：7天、P2：30天、P3：90天）。监控逾期漏洞并在需要时升级。

误报管理

维护抑制文件（.trivyignore），附带文档化理由、审查日期和批准跟踪。实施误报分类和批准的工作流。

完整的修复工作流、SLA跟踪器和自动化脚本，请参见 references/remediation-workflows.md。

与相关技能集成

构建CI管道

添加安全阶段到管道定义
配置SBOM存储的工件
使用漏洞阈值实施质量门

秘密管理

集成秘密扫描（Gitleaks、TruffleHog）
检测时自动轮换秘密
使用预提交钩子进行预防

基础设施即代码

使用Trivy配置扫描Terraform和Kubernetes清单
在部署前检测错误配置
使用OPA强制执行策略即代码

安全强化

应用扫描结果的修复指导
选择安全基础镜像
实施安全最佳实践

合规框架

生成SBOM用于SOC2、ISO 27001审计
为合规报告跟踪漏洞指标
为安全控制提供证据

快速参考

基本命令

# Trivy：使用严重性过滤器扫描镜像
trivy image --severity HIGH,CRITICAL myapp:latest

# Trivy：生成SBOM
trivy image --format cyclonedx --output sbom.json myapp:latest

# Trivy：扫描SBOM
trivy sbom sbom.json

# Grype：扫描镜像
grype myapp:latest --fail-on high

# Syft + Grype：SBOM工作流
syft myapp:latest -o json | grype

# Gitleaks：扫描秘密
gitleaks detect --source . --verbose

常见模式

# CI/CD：关键时构建失败
trivy image --exit-code 1 --severity CRITICAL myapp:latest

# 忽略未修复漏洞
trivy image --ignore-unfixed --severity HIGH,CRITICAL myapp:latest

# 仅扫描OS包
trivy image --vuln-type os myapp:latest

# 跳过特定目录
trivy fs --skip-dirs node_modules,vendor .

渐进式披露

本技能提供基础的漏洞管理模式。更深入主题：

工具选择： references/tool-selection.md - 完整决策框架
SBOM模式： references/sbom-guide.md - 生成、存储、消费
优先级划分： references/prioritization-framework.md - CVSS/EPSS/KEV自动化
CI/CD集成： references/ci-cd-patterns.md - GitLab CI、Jenkins、Azure Pipelines
修复： references/remediation-workflows.md - SLA跟踪、误报
策略即代码： references/policy-as-code.md - OPA示例、安全门

工作示例：

examples/trivy/ - Trivy扫描模式
examples/grype/ - Grype + Syft工作流
examples/ci-cd/ - 完整管道配置
examples/sbom/ - SBOM生成和管理
examples/prioritization/ - EPSS和KEV集成脚本

自动化脚本：

scripts/vulnerability-report.sh - 生成执行报告
scripts/sla-tracker.sh - 跟踪修复SLA
scripts/false-positive-manager.sh - 管理抑制规则