SCM 与流水线插件的代码信任
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
GitHub Branch Source 负责发现仓库、分支和 PR；Pipeline 插件执行仓库里的 Jenkinsfile。两者连起来后，能提交 Jenkinsfile 的人就可能控制构建行为。使用 GitLab 等平台时，应换成其受支持的 Branch Source，并重新核对同样的信任边界。GitHub Branch Source · 多分支安全说明
1. 把发现与执行分开审查#
| 路径 | 需要固定的配置 | 失败时的风险 |
|---|---|---|
| Branch Source 发现 | GitHub App 仓库范围、分支／PR discovery、fork trust policy、Webhook 签名 | 未授权仓库或 fork 代码进入构建 |
| Jenkinsfile 执行 | Jenkinsfile 路径、SCM commit、Job 配置权、Replay 权、Agent 与凭据 | 旧 commit、恶意脚本或不可信 PR 得到发布身份 |
| 发布入口 | 固定受保护主分支和仓库、独立发布 Controller／Agent | 测试 Job 借参数切到生产目标 |
建立 GitHub App 时，只授予插件所需的仓库读取与检查结果写入权限；Webhook 管理权限仅在自动管理 Webhook 时开放。对每种 PR discovery 方式明确记录构建的是 PR head 还是与目标分支合并后的结果，并在构建记录中核对实际 commit。详细设置见Git 与多分支。
以只读发现、回写状态的 GitHub App 为例，先在测试仓库核实下面的权限；如果插件运行所需权限与此不同，应依据当前插件文档增减并记录原因，而不是直接给仓库管理权。
| GitHub App 仓库权限 | 示例级别 | 验收 |
|---|---|---|
| Metadata、Contents、Pull requests | Read | 能发现目标仓库、分支与 PR |
| Checks 或 Commit statuses | Write，仅实际回写的类型 | PR 上出现对应构建结果 |
| Webhooks | 不授予；由平台预建 | 插件不自动创建／修改 Webhook |
预建 Webhook 后，从 GitHub delivery 记录核对签名验收、HTTP 状态和对应 Jenkins 扫描日志；再在构建日志记录 git rev-parse HEAD 与 GIT_COMMIT。如果测试 PR 配置为构建合并结果，这个 SHA 不一定等于 PR head，记录时要写明构建策略。
2. 不可信 PR 的隔离验收#
在测试仓库准备外部 fork PR，修改 Jenkinsfile 试图读取凭据、选择生产 label 和访问云元数据／生产网络。预期是 PR 只进入隔离测试 Controller 与 Agent，读取不到发布凭据，且网络和云端权限拒绝。when { branch 'main' }、Groovy sandbox 或只调整 label 都不能单独构成这条边界。
合并后由受保护发布 Job 构建固定仓库的指定 commit，记录镜像 digest；同一个 digest 经过预生产验证再进入生产。仓库保护应覆盖 Jenkinsfile、ci/、Dockerfile 与受信共享库。验收包含：普通分支测试通过、失败测试阻止合并、fork PR 不拿到发布身份、发布记录能追溯到精确 commit。
3. 插件变更时检查什么#
Branch Source 升级后，在隔离实例重新核对 PR discovery、fork trust policy、Webhook 触发和检查结果回写；不要只以“扫描仓库成功”作为验收。Pipeline 插件组合升级后，运行真实 Jenkinsfile，检查步骤兼容、失败阻断与 Replay 权限。插件依赖和镜像晋级遵循生命周期流程。