SCA 与漏洞管理

• CVE 标识与编号规则
• CVSS 评分维度与等级
• 工程中的使用

CVE（Common Vulnerabilities and Exposures）是公开披露的漏洞标识，由 CNA（CVE Numbering Authority）分配，编号格式为 CVE-年份-序号，每个 CVE 对应一项已公开的漏洞及其描述。CVSS（Common Vulnerability Scoring System）是评估漏洞严重程度的量化标准，从攻击向量、攻击复杂度、所需权限、用户交互、机密性/完整性/可用性影响等维度打分，最终换算为 0-10 分，并映射为 none、low、medium、high、critical 五个等级。工程上先用 CVSS 判断严重程度，再结合可利用性（EPSS）与可达性决定修复优先级。

CVE 是漏洞的"身份证"，CVSS 是"严重度标尺"，二者结合是漏洞管理与修复排期的起点，但 CVSS 只反映固有严重度，需结合业务上下文补充。

• CWE 的概念与作用
• CWE Top 25 的含义
• 与 CVE 的关系

CWE（Common Weakness Enumeration）是软件弱点的分类体系，用编号（如 CWE-79 XSS、CWE-89 SQL 注入）描述某类代码缺陷，是"弱点类型"的字典。CVE 描述具体漏洞实例，CWE 描述漏洞所属的弱点类型——一个 CVE 可归属到一个或多个 CWE。CWE Top 25 是 SANS/MITRE 每年基于真实 CVE 数据与漏洞利用情况统计出的"最危险弱点"榜单，用于指导开发团队的防御重点与代码审查、静态分析规则的优先级。工程上常把 CWE 作为 SAST 工具的告警分类标准，并据此制定修复策略。

CWE 提供"弱点分类"的公共语言，CWE Top 25 帮助团队聚焦最常被利用的弱点，是安全编码与测试的优先级依据。

• SCA 的原理
• 主流工具对比
• 落地方式

SCA（Software Composition Analysis）通过分析项目的依赖清单（如 package.json、go.mod、requirements.txt）与锁定文件，将组件及其版本与漏洞数据库（NVD、GHSA、OSV 等）比对，识别存在已知 CVE 的依赖。主流工具：OWASP Dependency-Check 是开源免费、依赖 NVD 数据库；Snyk 是商业 SaaS，支持多语言、漏洞库更新快、提供可达性分析；Trivy 开源、主打容器镜像与 IaC 扫描，也支持依赖扫描。工程上在 CI 中接入 SCA，设置门禁（高危漏洞阻断构建）并生成报告，作为漏洞管理的基础数据源。

SCA 聚焦"第三方组件"这一供应链风险面，是 SAST/DAST 覆盖不到的领域；工具选择需权衡开源/商业、语言覆盖、数据库更新速度与门禁能力。

• SLA 分级模型
• 各级时限的设定依据
• 工程落地

漏洞响应 SLA 按严重程度分级设定时限：critical（严重）24 小时内响应/修复，high（高）7 天内，medium（中）30 天内。分级依据是漏洞威胁程度与业务影响：critical 通常可被远程利用、无需/低权限即可影响核心资产，需立即处置；high 影响面大但限制较多；medium 影响有限。工程上需要有漏洞跟踪机制（如工单系统）、明确的负责人与升级路径，并将 SLA 纳入考核与告警，确保到期未修复自动升级通报。SLA 的"响应"可先临时缓解（如绕开、加防护），再彻底修复。

分级 SLA 让有限的安全资源优先处理最危险漏洞，避免"一刀切"导致的响应延迟或资源浪费，是漏洞管理成熟度的体现。

• 三大数据库的差异
• 覆盖率与更新速度
• 选型建议

NVD（National Vulnerability Database）由美国 NIST 维护，是 CVE 的权威数据库，覆盖最广但更新与评分（CVSS）有时滞后；GHSA（GitHub Security Advisories）由 GitHub 维护，覆盖 GitHub 生态软件包，与 Dependabot 深度集成，更新较快；OSV（Open Source Vulnerabilities）由 Google 维护，面向开源生态，提供结构化数据与 API，覆盖多语言包管理生态，更新及时。工程上常组合使用多个数据库以提升覆盖率：SCA 工具通常聚合多个来源，避免单一数据库遗漏。选择时关注语言覆盖、更新延迟与 API 可用性。

单一漏洞库存在覆盖盲区与更新滞后，聚合多源（NVD + GHSA + OSV）能提高检出率，这正是多数 SCA 工具的做法。

• 可利用性与严重度的区别
• EPSS 的原理
• 结合使用

漏洞严重度（CVSS）描述"有多严重"，而可利用性（exploitability）描述"实际被利用的可能性"，两者不同。EPSS（Exploit Prediction Scoring System）由 FIRST 提供，基于海量威胁情报数据（利用代码、攻击样本、漏洞被利用的观察）用机器学习模型预测"某漏洞在未来 30 天内被利用的概率"，输出 0-1 的分数。工程上把 EPSS 与 CVSS 结合：高 CVSS 且高 EPSS 的漏洞优先修复，低 EPSS 的高严重度漏洞可暂缓，从而把有限的修复资源投入最可能被利用的漏洞。

CVSS 是静态固有严重度，EPSS 是动态利用概率，二者结合能更精准地排序修复优先级，避免"只修高分不修真实风险"。

• 可达性概念
• 与静态依赖的区别
• 工程意义

可达性（reachability）指漏洞所在的代码路径是否真的被应用调用。仅静态依赖（static dependency）指依赖被引入但漏洞代码路径从未被调用，此时漏洞虽存在但不可实际利用；真实可利用（reachable）指漏洞代码路径被实际调用，可被攻击者利用。工程上通过可达性分析（如 Snyk 的 reachability 分析、代码调用图分析）减少误报，把修复精力聚焦到真实可达的漏洞，避免为"不可达"的漏洞空耗资源。但需注意：可达性判断基于当前代码，未来调用变化可能使漏洞变为可达。

可达性分析让 SCA 从"有漏洞"提升到"真能被打"，是降低误报、聚焦真实风险的关键进阶能力。

• Dependabot security updates 原理
• 自动 PR 的流程
• 落地与门禁

Dependabot security updates 是 GitHub 提供的自动安全更新功能：当依赖存在已知漏洞（来自 GHSA 数据库）时，Dependabot 自动创建修复漏洞的 PR（升级到修复版本），并附上漏洞说明与影响范围。配合 CI 测试，PR 通过后由维护者合并即可完成修复。工程上可配置自动合并策略（对安全更新）以加快修复，同时结合分支保护与测试门禁，确保修复不引入回归。Dependabot 还提供 version updates（定期版本更新）与 alerts（漏洞告警）。

Dependabot security updates 把"发现漏洞"到"创建修复 PR"自动化，显著缩短漏洞修复周期，是 GitHub 生态内 SCA 响应闭环的关键。

• GitLab Dependency Scanning 原理
• 内置集成方式
• 与 CI 的协同

GitLab Dependency Scanning 是 GitLab 内置的依赖漏洞扫描功能，基于 Gemnasium 分析器，可扫描多种语言的依赖清单（如 Maven、npm、pip、Go 等），与漏洞数据库比对并生成安全报告。它作为 Job 集成到 GitLab CI/CD 流水线中，扫描结果展示在 MR 的 Security 报告中，可在 Merge Request 中直接看到漏洞详情，并支持设定安全门禁（如超过阈值阻断合并）。它与 GitLab 的 SAST、DAST、Secret Detection 等共同构成内置的安全扫描能力。

GitLab 的集成式扫描把依赖漏洞检测"嵌入"现有 CI 与 MR 流程，无需额外 SaaS，降低落地门槛，适合已使用 GitLab 的平台化企业。

• 容器镜像扫描原理
• 各工具特点
• 落地方式

容器镜像扫描（container image scanning）分析镜像层中的软件包清单（通过 SBOM 或包管理器元数据），与漏洞数据库比对，识别镜像内置的组件漏洞。Grype 是 Anchore 的开源扫描器，支持多数据库且与 Syft（SBOM 生成）集成，输出依赖漏洞清单；Anchore 提供企业级镜像安全平台，支持策略与门禁；Clair 是 CoreOS 的静态镜像分析器，提供 API 供容器仓库集成。工程上把扫描接入 CI（构建后用工具扫描镜像）或容器仓库（如 Harbor、Quay 集成），设定漏洞门禁阻止含高危漏洞的镜像发布。

容器镜像扫描解决"镜像里的依赖漏洞"这一运行期风险，与源码级 SCA 互补，是镜像交付前必须过的安全关卡。

• Snyk 的能力
• 多语言与多仓库扫描
• SaaS 集成方式

Snyk 是商业 SaaS 漏洞管理平台，核心能力是 SCA（依赖漏洞扫描），同时覆盖 SAST、容器、IaC。它支持 30+ 种语言与主流包管理器，可扫描多仓库（通过 GitHub、GitLab、Bitbucket 集成自动发现仓库），并提供 SaaS 管理后台统一查看所有仓库的漏洞、优先级与修复建议。Snyk 提供 CLI 与 CI 集成（如 Snyk Action），支持门禁阻断与自动修复 PR（fix PR）。其优势在于漏洞库更新快、可达性分析、多仓库统一视图与团队协作。

Snyk 的 SaaS 模式把"多语言 + 多仓库 + 统一管理"整合，适合需要集中治理供应链漏洞的企业，但需权衡商业成本与数据上云。

• Trivy 的多模态能力
• 各扫描类型
• 落地方式

Trivy 是开源的多模态安全扫描器，覆盖多个安全面：容器镜像扫描（分析镜像层依赖漏洞）、文件系统扫描（扫描项目依赖与源码）、IaC 扫描（检测 Terraform、CloudFormation 等基础设施即代码的配置错误）、依赖（SCA）扫描、以及密钥泄漏检测。它基于多漏洞数据库（NVD、GHSA、OSV 等），有 CLI 与 CI 集成，可输出多种格式（JSON、SARIF）。工程上常用 Trivy 在 CI 中扫描镜像与 IaC，配合流水线门禁。

Trivy 以"单二进制多模态"著称，用一个工具覆盖镜像、依赖、IaC、密钥多个扫描面，适合精简工具链、统一 CI 门禁。

• 三类扫描各自覆盖范围
• 各自的盲区
• 互补组合

三类扫描覆盖不同安全面：SAST（静态应用安全测试）分析源码，能发现逻辑/注入类漏洞，但看不到运行时配置、部署环境与真实交互；DAST（动态应用安全测试）运行时探测应用，能发现实际暴露的配置与交互问题，但看不到源码内部逻辑；SCA（软件成分分析）只针对第三方组件依赖漏洞，不覆盖自研代码。三者互补：SAST 覆盖"自研代码逻辑"，DAST 覆盖"运行期实际暴露"，SCA 覆盖"第三方组件"，组合使用才能形成较完整的应用安全覆盖，避免单一工具的盲区。

没有一种扫描能覆盖全部风险面，按"源码-运行时-组件"三层次组合 SAST/DAST/SCA 是安全测试的标准做法。

• 可达性分析原理
• 降低误报的作用
• 局限性

SCA 的基础检测只报告"依赖的某个版本含已知漏洞"，会造成大量误报（很多漏洞路径未被调用）。可达性分析（reachability analysis）通过构建调用图，追踪漏洞代码是否被应用实际调用：若应用代码从未调用到含漏洞的函数/路径，则该漏洞标注为"不可达"（unreachable），降低优先级；若可达则标记为高危。工程上利用可达性分析把修复精力聚焦到真实可利用的漏洞，并结合 EPSS 排序。局限是可达性分析基于当前代码快照，代码演化后可达性可能改变，且复杂间接调用可能分析不完整。

可达性分析让 SCA 更加"精准"，从"有漏洞"走向"真能被打"，是减少误报、提升漏洞修复效率的关键技术。

• CVSS 与 EPSS 的差异
• 组合排序方法
• 工程实践

仅按 CVSS（严重度）排序会高估很多"严重但从未被利用"的漏洞。结合 EPSS（可利用概率）排序更贴近真实风险：把漏洞按"高严重度 + 高可利用性"优先修复，对"低可利用性"的漏洞可暂缓或批量处理。工程上可构建风险矩阵（横轴 CVSS、纵轴 EPSS），划分修复优先级：critical 且高 EPSS 立即修复，低 EPSS 的高严重度漏洞纳入常规排期。同时结合可达性，把"可达 + 高可利用 + 高严重"作为最高优先级，实现稀缺资源的精准投入。

CVSS 回答"多严重"，EPSS 回答"多可能被利用"，二者结合（再加可达性）能避免"只修高分不修真实威胁"的偏差，是漏洞排期的成熟方法。

• 传递依赖漏洞
• lockfile 固定版本的缓解
• 修复方式

传递依赖漏洞指漏洞位于间接依赖中，直接依赖看似正常但某个传递依赖含 CVE。SCA 工具通过解析完整依赖树（含锁定文件）识别传递依赖漏洞。缓解手段：lockfile 固定实际解析版本，使漏洞可复现、可追溯；修复时通过升级直接依赖或使用 override（如 npm overrides、Go replace、Maven dependencyManagement）强制传递依赖升级到修复版本；若上游未修复，可临时使用补丁（patch-package）或等待维护者更新。SCA 需默认扫描传递依赖，否则会漏报大量真实风险。

传递依赖漏洞是供应链风险主体，lockfile + 全量扫描 + override 是识别与修复的完整闭环。

• SLA 分级的落地
• 门禁阻断策略
• 配套机制

SLA 分级（critical 24h、high 7d、medium 30d）从"处置时限"约束漏洞修复，门禁阻断策略从"发布关口"约束漏洞流出：在 CI/发布流水线中设置漏洞门禁，当存在超过阈值（如 critical/high）的未修复漏洞时阻断合并或发布。二者配套形成闭环：SLA 驱动"尽快修复"，门禁保证"未修复不放行"。工程上需考虑豁免机制（如暂不可达、仅内部使用可提豁免单）以避免过度阻断影响交付，并定期审计门禁的豁免情况。

SLA 管"修复时限"，门禁管"发布准入"，配套才能既保证安全又不过度拖累交付，豁免机制是二者平衡的关键。

• SBOM 作为 SCA 输入
• SBOM 作为资产清单
• 双重作用

SBOM 是软件物料清单，列出软件包含的所有组件、版本与依赖关系。作为 SCA 输入：SBOM 提供结构化的组件清单，SCA 工具可直接解析 SBOM 与漏洞库比对，快速识别漏洞，避免重复解析依赖；作为漏洞响应资产清单：当某漏洞信息公开时，可基于 SBOM 快速定位"哪些产品/版本使用了受影响组件"，实现"一漏洞、全清单"的响应，支撑及时修复与通知。SBOM 的双重作用让它成为供应链安全与漏洞管理的数据基础。

SBOM 既是"扫描输入"（加速漏洞检测）又是"资产地图"（支撑漏洞响应定位），是一份数据多场景复用的关键资产。