4. SBOM 核验触发场景：CI/CD 流水线触发、定时扫描触发、事件驱动触发（镜像推送/部署）

SBOM 核验并非一次性动作，而是需要嵌入到容器镜像与应用的整个生命周期中。根据核验的自动化程度与触发时机，主要分为三类触发场景：CI/CD 流水线触发、定时扫描触发 与 事件驱动触发。理解这三类场景的差异与适用条件，是构建有效核验策略的基础。

4.1 三类触发场景对比

4.2 CI/CD 流水线触发：左移核验

这是最关键的“左移”安全实践。在开发者提交代码或构建镜像时，自动触发 SBOM 生成与核验，将安全问题暴露在最早阶段。

# GitLab CI 示例：在构建阶段后执行 SBOM 核验
build:
  stage: build
  script:
    - docker build -t ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA} .
    - trivy image --format cyclonedx --output sbom.cdx.json ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}
    - trivy image --severity CRITICAL,HIGH --exit-code 1 ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}
  artifacts:
    paths:
      - sbom.cdx.json
    reports:
      cyclonedx: sbom.cdx.json

4.3 定时扫描触发：持续监控与合规漂移检测

即使通过了 CI/CD 核验，已存储的镜像仍可能因新公开的漏洞（如 Log4j）而变得不安全。定时扫描用于检测这种“安全漂移”。

定时扫描通常以 Kubernetes CronJob 或独立调度器形式运行，扫描范围包括所有已批准的镜像仓库。核验结果应写入安全事件数据库，并与告警系统联动。

# Kubernetes CronJob 示例：每日凌晨 2 点扫描仓库
apiVersion: batch/v1
kind: CronJob
metadata:
  name: sbom-scan-cron
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: scanner
            image: aquasec/trivy:latest
            command:
            - trivy
            - image
            - --severity
            - CRITICAL,HIGH
            - --ignore-unfixed
            - registry.example.com/app:latest
          restartPolicy: OnFailure

4.4 事件驱动触发：运行时准入控制

在 Kubernetes 环境中，事件驱动触发通常通过 Admission Webhook 实现。当有镜像被推送或部署请求时，Webhook 拦截请求，提取镜像的 SBOM 或签名信息进行核验。

下图展示了事件驱动触发在镜像推送与部署两个关键节点的核验流程：

4.5 三类触发场景的协同与证据链

在实际生产环境中，这三类触发场景并非孤立运行，而是构成一个完整的核验证据链：

1. CI/CD 触发 生成初始 SBOM 与核验报告，作为“构建时证据”。
2. 定时扫描 持续更新镜像的安全状态，生成“运行时监控证据”。
3. 事件驱动触发 在每次部署时执行准入控制，生成“部署准入证据”。

下表总结了不同触发场景下的证据留存关键字段：