漏洞管理Skill：把多层面安全扫描、SBOM 与风险优先级一次性装进 CI/CD
核心结论速览：
- 它是什么：一个面向 DevSecOps 的 AI 技能，覆盖容器镜像、SAST、DAST、SCA、秘密扫描五类安全扫描，并生成 SBOM、做基于风险的漏洞优先级划分。
- 它的独特之处：不只是"调用某个扫描工具"，而是把扫描策略、CVSS/EPSS/KEV 综合定级、P0–P4 的 SLA 层级、CI/CD 五阶段安全门串成一套可落地的方法论。
- 它怎么用：通过自然语言向 AI 助手描述你的技术栈与目标（例如"帮我配置 GitHub Actions 的容器扫描门"），技能会输出对应的命令、配置和门禁阈值建议。
- 谁最适合：正在搭建 DevSecOps 流程的平台工程师、SRE、安全工程师，以及需要满足 SBOM 合规要求（如行政命令 14028）的团队。
- 注意事项：技能给出的是模式与配置模板，实际执行仍需在本地或 CI 环境中安装 Trivy、Grype、Semgrep 等工具；具体安装入口与版本以官方说明为准。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息：
| 项目 | 内容 |
|---|---|
| 中文名 | 漏洞管理 |
| 英文名 | managing-vulnerabilities |
| 技能 ID | 13404 |
| 定位 | 在 CI/CD 管道中实施多层面安全扫描、SBOM 生成与基于风险的漏洞优先级划分 |
它解决什么问题？
在没有统一规范的情况下，团队做漏洞管理常常陷入三种困境：一是"扫描工具满天飞"，容器用一个工具、依赖用另一个工具、密钥泄露靠人工发现，结果散落在各处；二是"告警疲劳"，一个镜像扫出几百个 CVE，不知道先修哪个，最后干脆全部忽略；三是"合规说不清"，被审计问到"你们组件的完整清单在哪"时拿不出标准格式的 SBOM。
这个技能把这些零散问题整合为一套结构化答案：在哪几个层面扫、用什么工具扫、扫完怎么排优先级、排完怎么卡在 CI/CD 里、误报怎么管理。
一键安装 AI 技能的思路与步骤：
- 确认前提环境：你需要在支持技能调用的 AI 助手客户端或开发环境中工作，并已具备基本的 CI/CD 仓库与容器构建能力。
- 找到技能入口：在技能市场/技能库/插件中心中搜索技能中文名「漏洞管理」或英文名「managing-vulnerabilities」，也可直接使用技能 ID 13404 定位（不同平台的入口名称与路径不同，具体以官方说明为准）。
- 一键启用：选中该技能并启用后，它会在后续对话中作为可调用的能力被加载。
- 验证是否生效：向助手提一个典型问题，例如"我们用的是 GitLab CI，想在构建阶段对镜像做关键漏洞拦截并生成 CycloneDX 格式的 SBOM，应该怎么配？"如果返回中包含 Trivy 命令、
--exit-code 1、--format cyclonedx等内容，说明技能已正常加载。 - 进阶验证：继续追问"这个 CVE 的 EPSS 分数很高，按你们的 SLA 应该归到哪个优先级"，如果返回中有 P0–P4 分级逻辑与对应时限，说明优先级划分能力也已就绪。
提示：技能的安装命令、订阅方式、是否收费等具体信息，本技能详情中并未提供，请以官方说明为准。
该技能的主要功能和特点
1. 五层面扫描策略，一次性覆盖全链路
| 扫描层面 | 检测对象 | 推荐工具 | 触发时机 |
|---|---|---|---|
| 容器镜像扫描 | 操作系统包、语言依赖、二进制文件 | Trivy（默认）、Grype（准确度优先）、Snyk Container | 每次构建、基础镜像变更、注册库准入 |
| SAST 静态测试 | 源代码安全缺陷 | Semgrep、Snyk Code、SonarQube | 每次提交、PR 检查、主干保护 |
| DAST 动态测试 | 运行中应用的漏洞 | OWASP ZAP、StackHawk、Burp Suite | 预发布环境测试、API 验证 |
| SCA 成分分析 | 第三方依赖与许可证 | Dependabot、Renovate、Snyk Open Source | 每次构建、依赖升级 |
| 秘密扫描 | 硬编码密钥与凭据 | Gitleaks、TruffleHog、GitGuardian | 预提交钩子、仓库扫描、制品检查 |
2. 双格式 SBOM 生成：同时支持 CycloneDX（偏 DevSecOps，安全导向、带原生漏洞引用、体积轻）与 SPDX（偏法律合规，ISO/IEC 5962:2021 标准，政府/国防常用格式），并能给出 Syft、Trivy 的具体生成命令。
3. 基于风险的优先级划分，而不是只看 CVSS：把 CVSS 基础分、EPSS 利用概率、CISA KEV 在野利用状态、资产关键性、网络暴露度五个因子加权成单一优先级分数，并映射到 P0–P4 的 SLA 层级。
4. CI/CD 五阶段渐进式安全门：从预提交（小于 10 秒）→ PR 检查（小于 5 分钟）→ 构建（小于 2 分钟）→ 预部署（10–30 分钟）→ 生产运行时，逐层收紧阈值，兼顾安全与开发速度。
5. 与普通扫描工具相比强在哪：普通工具只回答"有哪些漏洞"，这个技能额外回答"先修哪个"“多久必须修完”“在哪一步拦住它”“误报怎么登记豁免”。它把策略与流程一并输出，而非单一命令。
6. 配套治理能力：包含 .trivyignore 误报抑制规范（要求写明理由与审查日期）、OPA 策略即代码、修复 SLA 跟踪脚本思路，以及渐进式披露的六份参考文档索引（工具选择、SBOM、优先级框架、CI/CD 模式、修复流程、策略即代码）。
如何使用该技能？
步骤一：明确你的场景与约束
先用一句话描述背景，例如："我们是 20 人团队，用 GitHub Actions，镜像基于 Debian，需要满足内部合规对整个组件清单的要求。"信息越具体，输出越贴合。
步骤二：让技能给出扫描层组合
直接问："按我们的情况，应该上哪些扫描层、各自用什么工具？"技能会依据其工具选择速查表给出组合，例如容器用 Trivy、源码用 Semgrep、密钥用 Gitleaks、依赖用 Dependabot。
步骤三：生成 SBOM 配置
输入示例：
# 生成 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
输出说明：助手会解释每个参数的作用，并告知 SBOM 应作为构建制品长期存储，用于后续增量扫描与审计举证。
步骤四：配置安全门阈值
输入示例：“我希望构建阶段遇到 CRITICAL 就失败，但不想被还没出补丁的漏洞卡住。”
参考输出（技能中的常见模式）：
trivy image --exit-code 1 --ignore-unfixed --severity HIGH,CRITICAL myapp:latest
配合 .trivy.yaml 统一配置：
severity: HIGH,CRITICAL
exit-code: 1
ignore-unfixed: true
vuln-type: os,library
skip-dirs:
- node_modules
- vendor
ignorefile: .trivyignore
步骤五：做优先级排序
输入示例：“给我看看 Log4Shell 按你们的模型应该排在哪一级。”
技能给出的计算逻辑为：
优先级分数 = (CVSS × 0.3) + (EPSS × 100 × 0.3) + (KEV × 50) + (资产 × 0.2) + (暴露度 × 0.2)
代入 CVE-2021-44228：CVSS 10.0、EPSS 0.975、KEV 命中、关键资产、互联网可访问，得分为 82.65，判定为 P0 关键，24 小时 SLA。
步骤六：生成 CI 管道配置
输入示例："帮我把这套流程写成 GitHub Actions 的三段式作业。"技能会输出包含 secrets、sast、container 三个 job 的完整 YAML，其中 container job 依赖前两者通过，并上传 sbom.json 作为制品。
步骤七：建立误报与豁免流程
在 .trivyignore 中按规范登记：
# 风险接受：在我们的用例中不可利用
CVE-2023-67890
# 仅开发依赖项，不进入生产
CVE-2023-11111
助手会强调：每条豁免都要写理由、留审查日期、走审批留痕，避免抑制文件变成"黑洞"。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 漏洞管理Skill（本技能） | DevSecOps 方法论与配置生成助手 | 五层扫描策略、SBOM 双格式、CVSS/EPSS/KEV 优先级模型、五阶段安全门、OPA 策略模式 | 低：通过 AI 助手自然语言调用，无需额外部署；底层扫描工具仍需自行安装 | 团队从 0 搭建安全扫描流程、需要成体系的优先级与门禁规范 | 优势：输出的是完整方法论与可复制配置，跨工具、跨平台；不足：不直接执行扫描，最终效果依赖所接入工具的真实运行 |
| Trivy 单工具直用 | 一体化开源扫描器 | 镜像/文件系统/配置/SBOM 扫描 | 中：需在本地或 CI 中安装并自行编写管道 | 已有明确工具选型、只需执行层的团队 | 优势：单点能力强、轻量快速；不足：只解决"扫"，优先级划分、SLA、多层面协同需自行设计 |
| Snyk 商业平台 | 商业一体化 AppSec 平台 | SCA、容器、代码、IaC 扫描与修复建议 | 中高：需账号订阅与仓库接入 | 有预算、追求开箱即用仪表盘与修复 PR 自动化的团队 | 优势：商业支持完善、开发者体验好；不足：按用量计费成本较高，深度定制受平台限制 |
| GitHub 原生方案（Dependabot + CodeQL + 秘密扫描） | 平台内置安全能力 | 依赖更新、代码扫描、密钥检测 | 低：仓库内开关即用 | 已全量托管在 GitHub 的项目 | 优势：零部署、与 PR 流程天然融合；不足：跨平台（GitLab/Jenkins）不可用，容器镜像深度扫描与 SBOM 合规输出需额外补足 |
| 手工脚本 + 多工具拼接 | 自研方案 | 任意组合开源工具 | 高：需自行维护编排、阈值、告警 | 大型平台团队，有专职安全工程人力 | 优势：完全可控可定制；不足：维护成本高、知识沉淀在个人，团队更替易断档 |
选型建议：若你的痛点是"不知道流程该怎么设计"，先用本技能把方法论和配置模板拉通；若痛点是"工具跑不起来"，则需要补装 Trivy/Grype 等执行层；若痛点只是"依赖更新提醒"，平台原生的 Dependabot 往往已够用。
该技能的典型应用场景与实际体验情况
场景一：初创团队第一次给 CI 加安全门
角色：后端负责人，团队 8 人，刚把服务容器化上线。痛点是想加安全检查又怕拖慢发布节奏，也不清楚该在哪个环节卡。
使用方式：向技能提问"我不想让 CI 慢太多，最该先加哪一层？"技能建议先上预提交钩子做秘密扫描（小于 10 秒）+ 构建阶段容器扫描（小于 2 分钟），PR 阶段的 SAST 可放到第二阶段再引入。
实际体验：上手几乎零门槛，得到的是一条渐进路线图而非一堆工具列表，能直接拿去和团队沟通排期。注意点是技能给出的是模式，具体耗时仍取决于你的镜像体积与规则集规模。
场景二：合规审计前突击准备 SBOM
角色：安全合规专员，被要求提交产品完整组件清单。痛点是不知道该用哪种格式、导出后怎么保证可持续更新。
使用方式：提问"我们需要满足合规要求，该用 CycloneDX 还是 SPDX？"技能明确回答：CycloneDX 偏 DevSecOps 与漏洞跟踪，SPDX 偏法律合规且为政府/国防首选；并给出 Trivy 与 Syft 两套生成命令。
实际体验：格式选型的决策依据清晰，省去了大量查资料时间。注意事项是 SBOM 需要作为构建制品长期归档，否则下一次审计又要重来。
场景三：高危漏洞爆发时的紧急定级
角色：SRE，半夜收到 Log4Shell 类高危漏洞预警，需要立刻判断是否停服修补。
使用方式：把 CVSS、EPSS、是否在 KEV、资产等级、是否公网暴露五项输入给技能，直接得到优先级分数与 SLA 结论。
实际体验：最有价值的是它把"KEV 命中"作为独立加分项（权重 50），这比单看 CVSS 分数更贴近真实风险——很多 CVSS 9.8 的漏洞因为利用条件苛刻其实并不紧急。注意点是资产关键性与暴露度需要你们自己有准确数据，否则输入失真会导致定级偏差。
场景四：误报泛滥后的抑制治理
角色：平台工程师，团队开始集体无视扫描告警。痛点是 .trivyignore 里堆了几十条没人知道来历的豁免。
使用方式：请技能设计一套误报管理规范，输出包括：每条豁免必须写明理由、标注审查日期、区分"误报"与"风险接受"与"仅开发依赖"三类。
实际体验：这套分类恰恰是多数团队缺失的。注意事项是规范建立后仍需人工执行审批，技能无法替你判断某个 CVE 在当前业务中是否真的不可利用。
该技能能为用户带来的价值
效率提升：从"查资料一周"到"问一句拿到方案"
DevSecOps 流程设计涉及五类扫描工具、两种 SBOM 格式、三套评分体系（CVSS/EPSS/KEV）和多个 CI 平台的配置语法。按传统方式，一个团队从零调研到跑通最小可用流程通常需要数天到数周。本技能把这些知识压缩成可直接复用的命令、YAML 与阈值表，把前期调研成本大幅压缩。
门槛降低：安全能力不再专属于安全团队
优先级模型的价值在于"可解释"。当一个 CVE 被判为 P2、30 天修复时，团队能清楚看到是 CVSS 落在 7.0–8.9 区间，还是 EPSS 达到了 0.05 阈值——而不是面对一个黑箱评级。这让开发团队能自行判断、自行排期，减少了对安全专家的日常依赖。
可量化收益：告警量与修复节奏同时可控
- 通过
--ignore-unfixed，只对已有补丁的漏洞拦截构建，避免被"无解漏洞"卡死流水线； - 通过 P0–P4 分级，把修复资源集中在 24 小时内的真正紧急项上，而非平均用力；
- 通过渐进式门禁（预提交 10 秒、构建 2 分钟），把安全检查的开销控制在可接受范围内。
长期价值：把安全实践沉淀成组织资产
技能附带的六份参考文档索引（工具选择、SBOM 指南、优先级框架、CI/CD 模式、修复流程、策略即代码）以及示例目录结构，本身就是一套可以写进团队规范的知识骨架。随着 .trivyignore 豁免记录、SLA 跟踪和 OPA 策略的积累，团队会形成自己的安全基线，而不是每次换人都重新摸索。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
在支持技能调用的 AI 助手环境中，通过技能市场或插件中心搜索中文名「漏洞管理」、英文名「managing-vulnerabilities」，或直接用技能 ID 13404 定位并启用即可。技能详情中未说明具体的安装命令、订阅方式与收费标准，请以官方说明为准。需要注意的是，技能本身提供的是扫描策略、配置模板与方法论，底层的 Trivy、Grype、Semgrep 等工具仍需你在本地或 CI 环境中自行安装。
Q2：它能直接帮我扫描镜像吗？还是只给建议？
它输出的是可执行的命令与配置（如 trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest），但执行动作发生在你本机或 CI 环境中。你可以把它理解为"一位熟悉 DevSecOps 的顾问，随时给你写好的脚本和阈值建议"，而不是一个替你跑扫描的托管服务。
Q3：CVSS、EPSS、KEV 三个分数我该看哪个？
技能的做法是三个一起看，并加权计算。CVSS 衡量"漏洞本身有多严重"（0–10），EPSS 衡量"未来被利用的概率"（0–1），KEV 是美国 CISA 维护的"已被在野利用"清单。仅有高 CVSS 但 EPSS 极低、又不在 KEV 中的漏洞，优先级会被显著下调；反之，进入 KEV 的漏洞会获得 +50 的权重加成。这正是它的价值——避免只看 CVSS 造成的告警疲劳。
Q4：和 Snyk、GitHub 原生安全功能比，该怎么选？
看你缺什么。缺"流程设计"和"优先级方法论"，选本技能；缺"开箱即用的托管平台与修复 PR 自动化"，且预算充足，可考虑 Snyk；项目全量托管在 GitHub、只需要依赖更新与代码扫描，原生 Dependabot + CodeQL 往往够用。三者并不互斥——常见组合是用本技能设计门禁与 SLA 规则，底层执行层再按需选择开源或商业工具。
Q5：扫出来的误报太多，团队开始无视告警了怎么办？
这正是技能的误报管理模块要解决的问题。它建议维护 .trivyignore 抑制文件，并强制三类标注：真正的误报、有理由的风险接受、仅存在于开发依赖中的漏洞。配合 OPA 策略即代码和定期审查机制，可以避免抑制文件演变成无人知晓来历的"黑洞"。不过请记住：某个 CVE 在你们业务中是否真的不可利用，最终仍需人工判断，技能无法替代这一决策。