安全左移这四个字，在CI/CD流水线里经常被翻译成：把扫描插件往前挪一格。
就这么简单？真不是。
我跑过几次企业内部的流水线评审，最常见的画面是：SAST 卡在合并请求上，开发者盯着三百条告警，安全同学在群里说“先修高危”。三天后，项目延期，负责人把门禁改成 warning。故事结束。风险还在。
问题不在工具。问题在左移不是位置变化，是决策变化。谁能在代码合并前说“不”？谁负责修？修不完谁拍板？这些没定，扫描器放哪儿都只是装饰。
代码库不是保险箱
很多人把安全左移的起点放在 IDE 插件。有用，但有限。真正的第一道门是版本库。
提交钩子可以拦密钥，pre-commit 能跑 lint 和 secrets 扫描。但麻烦在于，开发者本地环境千奇百怪，钩子能被跳过。–no-verify 一敲，世界清净。所以服务端必须兜底：pre-receive 或合并请求流水线。这里的重点是别只报不轮换。扫出 AWS key，第一件事是吊销，第二件事是查调用日志。只建工单，等于把炸弹留在历史里。
依赖也要管。锁文件、私有源、命名空间投毒，这些不是新话题，但经常被“以后再说”拖到生产。一个私有包名少个字母，构建机就把内部 token 发给外部源。防御不复杂：锁文件必须提交，源必须固定，CI 里禁止动态安装最新版。代价是升级麻烦。对，就是麻烦。安全左移的很多工作，本质是提前吃麻烦。
分支保护也得配合。CODEOWNERS 能保证安全相关文件有人看，但别把安全团队设成所有目录 owner。那样他们变瓶颈，PR 排长队。更实际的做法：把高风险路径列出来，比如认证、加密、IaC 模块、Dockerfile。其余放行。安全不是平均用力。
构建阶段最容易被忽略的脏活
代码过了，构建就安全？未必。CI runner 经常是权限最大的机器。它能读制品仓库、推镜像、拿云凭据。如果跑不受信任的 PR，等于把钥匙交给陌生人。
我见过一个团队用长期 AK/SK 放在 CI 变量里。后来有人加了一行 curl，把环境变量打到日志。幸好日志权限控制住了。不然云上资源可能被开成矿场。这事不玄。改法也清楚：用 OIDC 换短期凭据，按流水线最小权限授权。构建缓存要隔离，PR 的缓存别和生产分支共用。缓存投毒不是电影桥段，是真实存在的攻击面。
制品侧，SBOM 和签名别只当合规作业。SBOM 要能回答“这个漏洞影响哪些镜像”。签名要能在部署前验证。SLSA 等级可以慢慢爬，但制品不可变、来源可追溯这条底线得先有。否则出了事，只能靠猜。
镜像构建还有个老问题：基础镜像太大。里面塞满工具链和 shell。攻击面跟着膨胀。多阶段构建、distroless、非 root 运行，这些都不新鲜。新鲜的是，很多团队把“能跑”当终点。能跑和能安全地跑，中间差着权限、网络策略和只读文件系统。
策略门禁别做成收费站
左移到最后，都会碰到门禁。门禁设计不好，安全团队就成了收费站。每辆车都拦，每辆车都查，路就堵了。
比较能落地的做法是分级。低危给建议，不阻断。中危要求限期修，但允许带 issue 合并。高危和密钥泄露直接阻断。策略即代码，放进版本库，和业务代码一起评审。OPA、Conftest、Kyverno 都能干这事。关键不是选哪个，是策略要能被测试、被解释、被申诉。
误报治理也得有人管。安全工具不是圣旨。一个误报反复出现，开发者会学会忽略所有告警。这比没有扫描更糟。每月看一次门禁拦截数据，分清楚哪些是真风险，哪些是规则太糙。把高频误报干掉，比加新工具更有价值。
度量别搞太复杂。修复时长、逃逸到生产的缺陷数、门禁绕过次数，够用了。别拿扫描告警总数当 KPI。那只会鼓励大家关规则。
左移不是把安全团队累死
说到底，CI/CD流水线安全左移不是把安全工程师塞进每个环节。那撑不住。它更像把安全约束变成工程系统的一部分。提交时拦密钥，构建时收权限，部署前验签名，运行时留审计。每一层都不完美，但叠起来，攻击成本就上去了。
还有个反直觉的点：左移不等于所有事都在开发阶段解决。有些风险只有运行时才看得清。比如 SSRF、权限绕过、业务逻辑漏洞。左移能做的是把已知的、重复的、机器能判的，尽量提前。剩下的交给运行时防护和应急响应。别让左移背所有锅。
如果你正准备改造流水线，先从一件事开始：把长期凭据换成短期凭据。就这一件。做完再谈别的。真的，很多花哨方案，不如先把这个洞堵上。