GitLab CI 构建环境安全的核心是前置控制而非事后审计：强制容器隔离、阻断高危行为、模板集中管控、动态权限熔断、基线扫描嵌入流水线，任一环节拒绝即终止构建。

GitLab CI 构建环境的安全性检查，核心不是“在构建里查安全”，而是“让构建本身无法绕过安全约束”。重点在于前置控制执行环境、阻断高危行为、自动拦截风险项，而不是等 job 运行完再审计。

强制隔离容器运行时权限

所有 CI job 必须在受控容器中运行，禁止任何直连宿主机的路径：

• 禁用 shell 和 ssh executor，只允许 docker 或 kubernetes 类型 Runner
• 容器启动时必须设 read_only: true，仅显式挂载 /tmp、/builds 等必要可写路径
• 严格禁止 bind mount 宿主机敏感目录：如 /var/run/docker.sock、/proc、/sys、/etc
• 镜像内默认指定非 root 用户（例如 user: 1001），或在 job 中统一覆盖 user: 字段

阻断恶意 CI 脚本注入链路

.gitlab-ci.yml 不应由开发人员自由编辑，而应作为受信产物被引用：

Digital Twin Discharge Drafter

用于撰写患者出院小结、制定个性化出院指导、模拟出院后结局、降低再入院率

下载

• 将 CI 模板移出业务仓库，统一托管在私有模板库（如 infra/ci-templates），项目仅通过 include: 引用固定 tag 版本
• 启用 GitLab 16.10+ 的 include_validation 功能，要求被 include 的 YAML 必须来自授权项目且带 GPG 签名
• 模板库设置为 private，推送权限仅限 CI 管理员组；合并请求强制双人审批 + 自动签名验证流水线

运行时动态权限熔断

每个 job 启动前，必须向可信策略服务做实时授权校验：

• 启用 CI_JOB_JWT，获取含触发者身份、项目 ID、ref、stage 等上下文的短期 JWT
• Runner 集成本地 OPA（Open Policy Agent）agent，在 job 执行前传入 JWT 和脚本内容，执行策略判断
• 策略中硬编码拦截高危操作：如 docker run --privileged、nsenter、mount --bind、chroot 等命令匹配即拒绝

自动化基线扫描嵌入流水线

把安全检查变成不可跳过的构建步骤，失败即终止：

• 用 Trivy image 扫描构建出的镜像，--severity CRITICAL --exit-code 1 直接阻断流水线
• 用 InSpec 校验 Runner 主机配置（如是否启用 user namespace、seccomp profile 是否加载）
• 用 Checkov 或 Conftest 检查 .gitlab-ci.yml 自身是否合规（如是否误用了 pull_request_target、是否缺失 rules 限制）
• 启用 pre-commit hook 或 GitLab branch protection，拦截含 password=、aws_secret 等敏感字符串的提交

不复杂但容易忽略：安全检查的价值不在报告多好看，而在它能否真正卡住构建出口。只要一个环节能拒绝非法行为，就比十个事后审计更有意义。