依赖包有已知漏洞？CNB 构建时自动扫描拦截

摘要：

依赖包里的已知漏洞往往藏在构建过程深处，人工排查难以覆盖。腾讯云 CNB 在构建时自动运行代码安全扫描，结合 secrets 与 SCA 能力识别开源组件风险，并可通过仓库配置文件定制扫描范围与告警处理，帮助团队在代码合入前把住依赖安全关。

一、依赖漏洞：供应链风险就藏在构建环节

现代软件项目很少从零编写全部代码，一个应用往往依赖成百上千个开源组件。这些依赖通过包管理器层层引入，构成了软件的供应链。问题在于，供应链中的任何一个环节都可能携带已知漏洞——可能是某个 npm 包的旧版本存在路径穿越缺陷，也可能是某个 Python 依赖命中了公开的 CVE 编号。

这类风险有两个典型特征。其一，隐蔽性强。漏洞存在于间接依赖中，开发者很少逐层审查完整的依赖树，肉眼几乎无法发现。其二，传播面广。一旦含漏洞的依赖被打进镜像或制品，风险就会随构建产物流向测试、预发乃至生产环境。

传统做法是在项目上线前人工核对依赖版本、订阅漏洞公告、再手动升级。这套流程对大型项目而言成本高、覆盖窄，且高度依赖开发者的主动意识。更现实的情况是，很多含漏洞的依赖在代码合入主干时就已经进入，等到被发现时往往已经扩散。

把安全检测前移到构建环节，让流水线在代码提交和合并请求阶段自动识别已知漏洞依赖，是更有效的应对方式。腾讯云 CNB（Cloud Native Build）作为 AI Native Git 平台，把代码安全扫描内置到云原生构建流程中，正是为了在依赖进入制品之前完成拦截。

二、CNB 代码安全扫描：构建时把住依赖关

CNB 的代码安全扫描能力用于在仓库中检查两类风险：敏感信息（secrets）和开源组件风险（software-composition-analysis，简称 SCA）。前者关注代码中是否误提交了密钥、令牌等敏感内容，后者则聚焦依赖的开源组件是否存在已知漏洞。两项能力默认开箱即用，无需额外开通即可在构建时运行。

对于本文关注的依赖漏洞问题，关键在于 SCA 能力。它在构建过程中分析项目依赖，识别所使用的开源组件，并与公开的漏洞信息比对，从而发现命中已知漏洞的依赖包。这样一来，安全检查不再是上线前的事后补救，而是嵌入到每一次构建和合并请求之中，与研发流程同步进行。

扫描的触发与构建流程天然绑定。当开发者提交代码、发起合并请求或流水线被触发时，安全扫描随之运行，结果反馈到流水线状态中。团队可以在构建日志和扫描结果里查看命中的组件及其风险等级，据此决定是否升级、替换或调整依赖。

这种"构建即扫描"的模式，把依赖漏洞的发现时点从上线后大幅提前到代码合入前。越早发现，修复成本越低，风险扩散的范围也越小。

三、SCA 如何识别并拦截已知漏洞依赖

SCA 的核心动作是把项目实际使用的开源组件与漏洞知识库进行比对。构建时，扫描器会解析项目的依赖声明文件和锁文件，梳理出完整的组件清单及其版本，再逐一与已知漏洞数据匹配。

当某个依赖组件命中已知漏洞时，扫描会给出对应的告警，并标注风险等级。团队可以基于告警信息判断处置优先级：高危漏洞的依赖优先升级或替换，低危且暂时无替代方案的则可以记录在案、择期处理。

需要强调的是，SCA 识别的是"已知漏洞"，即已经被公开收录、有明确 CVE 编号或安全公告的漏洞。它帮助团队系统化地处理已暴露的风险，而不是承诺发现所有未知问题。把已知漏洞依赖挡在构建环节之外，已经是供应链安全中务实且高收益的一环。

配合分支保护规则，团队还可以把安全扫描结果作为合并请求的准入门槛。例如要求含高危漏洞告警的合并请求必须经过处理或审批才能合入，从而让"依赖不带病入库"成为团队默认的研发纪律。

四、用配置文件定制扫描策略

虽然扫描默认开箱即用，但不同项目的依赖结构和安全要求各不相同。CNB 允许通过仓库中的配置文件对扫描进行定制。配置文件默认放在仓库的 .cnb/security/ 目录下，未提供配置时会使用平台内置的默认配置，扫描照常进行。

配置的核心能力包括四个方面：指定扫描范围、关闭某个能力、拆分配置、按规则处理告警。下面给出一份结构示例，展示这些能力如何组合使用。

# 文件路径：.cnb/security/code_scan_config.yml
# 以下为能力示意，实际字段以平台文档为准

# 指定扫描范围：只扫描指定路径
scan_range:
  include:
    - "src/**"

# 关闭某个能力：例如本项目暂不启用 secrets 检查
disable:
  - secrets

# 拆分配置：把不同模块的扫描规则拆分到独立文件
include:
  - ".cnb/security/scan-backend.yml"
  - ".cnb/security/scan-frontend.yml"

# 规则化忽略告警（Beta）：按路径、严重级别等条件忽略
ignore_rules:
  - path: "test/**"
    severity: low

这份示例对应了配置文件的几项核心能力。

a. 指定扫描范围：通过范围配置把扫描聚焦到真正需要检测的目录，避免对第三方代码或生成产物做无谓扫描。

b. 关闭某个能力：当项目暂时只需要 SCA 而不需要敏感信息检查时，可以单独关闭 secrets 能力，让扫描更贴合项目实际。

c. 拆分配置：对于前后端分离或多模块的仓库，可以用 include 把不同模块的扫描规则拆到独立文件中分别维护，避免单文件臃肿。

d. 规则化忽略告警（Beta）：针对测试代码、示例代码等场景中出现的低危告警，可以按路径、严重级别等条件规则化忽略，减少噪声、让团队聚焦真正需要处理的告警。

此外，仓库中还可以新增 .scanignore 文件，采用 gitignore 语法排除无需扫描的路径。例如依赖目录、构建产物目录、第三方 vendored 代码等，都可以通过 .scanignore 排除，避免产生大量无意义的告警。

在提交配置文件之前，可以用 validate 插件检查配置是否合法，避免因配置语法错误导致扫描行为不符合预期。这一习惯值得纳入团队的配置管理流程。

五、让扫描真正发挥作用的关键

配置好扫描只是起点，让扫描持续产生价值还需要几项配套习惯。

首先是把扫描结果纳入合并请求评审。让安全告警随合并请求一起呈现，使依赖漏洞在代码合入主干之前就被看见、被处理，而不是等到上线后才发现。

其次是建立告警处置的优先级。高危漏洞优先修复，低危漏洞结合业务影响评估后择期处理，避免团队在海量告警中失去重点。规则化忽略能力在这里能帮上忙——把确属误报或无关紧要的告警按规则排除，保持告警列表的清爽。

第三是定期回顾扫描范围。项目的依赖结构会随时间变化，扫描范围和忽略规则也应随之调整，确保扫描始终覆盖真正需要关注的部分。

最后是把配置文件纳入版本管理。.cnb/security/ 目录下的配置和 .scanignore 都应随代码一起提交，让扫描策略成为团队共享、可追溯的"安全即代码"的一部分，这也契合 CNB"配置即代码"的原则。

六、从依赖入手，筑牢供应链安全基线

依赖漏洞是软件供应链中最常见也最容易被忽视的风险之一。依靠人工排查，既难覆盖庞大的依赖树，也难以跟上持续出现的漏洞公告。把安全扫描内置到构建流程，让已知漏洞依赖在合入前就被识别和拦截，是性价比很高的安全基线建设。

腾讯云 CNB 通过开箱即用的 secrets 与 SCA 扫描能力，把依赖安全检查嵌入每一次构建和合并请求；同时提供仓库级配置文件，让团队可以按项目实际定制扫描范围、能力和告警处理规则。这套机制让依赖安全从"上线后补救"前移到"合入前拦截"，帮助研发团队用较低成本守住供应链安全的关键关口。

如果你的团队也在为依赖漏洞排查头疼，不妨在仓库的 .cnb/security/ 目录下新增一份 code_scan_config.yml，开启 SCA 扫描并设定适合项目的扫描范围，让已知漏洞依赖在构建环节就被自动识别和拦截。

了解更多产品详情：腾讯云 CNB