DevSecOps 与软件供应链安全¶

如何对云原生交付系统开展威胁建模？¶

技术说明

先确定资产、信任边界、数据流和攻击者能力，再枚举威胁，而不是从安全工具清单开始。对代码仓库—CI—制品库—部署控制面—运行时画数据流图，标出人、工作负载、第三方集成和管理平面。可用 STRIDE¹ 辅助检查伪装、篡改、抵赖、信息泄露、拒绝服务和权限提升，但要转化为具体滥用案例，如“被攻陷 PR runner 是否能签生产镜像”。

风险按可能性、影响和现有控制排序，控制优先消除长期凭证、缩小信任域、强制隔离与验证，再考虑检测。每个假设绑定测试或证据：权限图、审计事件、签名验证、攻击路径演练。模型随架构、供应商和权限变化更新；把所有风险标“低”或只讨论互联网入口，会遗漏 CI、内部身份和控制面等高价值路径。

实践经验

某平台曾把 fork PR 与主分支构建放在同一自托管 runner 池。威胁建模发现不可信代码可读取残留工作区并访问元数据身份。团队先禁止外部 PR 使用特权池、轮换可能暴露的凭证并核查审计日志；随后按信任级别拆池、使用短期身份和一次性执行环境。隔离增加了队列与成本，因此为低风险公开构建配置无密钥共享池，而发布池保留严格串行和审批。

面试回答要点

如何在云和 Kubernetes 中落实最小权限 IAM？¶

技术说明

人和工作负载身份分离，优先联邦登录、短期令牌和 workload identity，避免共享用户与静态 access key。权限从任务所需动作、资源范围、条件和时效推导；Kubernetes ServiceAccount 不应默认绑定宽泛 ClusterRole，云角色用命名空间、服务账号、环境和受众条件约束信任。部分云 IAM² 可用显式 deny、组织级边界和权限上限限制局部管理员误配；Kubernetes 原生 RBAC³ 权限则是纯加法，没有 deny 规则，未被任何规则允许的请求才会被拒绝，对对象字段的限制应交给准入策略。

落地需结合权限使用数据、策略模拟和访问审查：先观察实际调用，再在测试环境收紧；高风险操作采用 JIT⁴、审批、MFA 和会话审计。撤权前评估异步任务、灾备和夜间值班路径。对权限拒绝率、长期密钥数、过期例外、未使用授权和跨账号信任做持续检测，防止 IaC 之外的漂移。

实践经验

某应用为读取一个存储桶使用账号级管理员角色，扫描发现角色还能删除备份。团队先建立只读策略并在影子环境验证访问日志，灰度切换后移除旧绑定；写入任务则单独角色、限定前缀。一次撤权导致旧版定时任务失败，说明仅看近七天使用不足。长期用 90 天证据、业务 owner 确认和自动到期例外，并保留受审计的 break-glass 角色。

面试回答要点

Secrets 的完整生命周期应如何管理？¶

技术说明

生命周期包括生成、存储、分发、使用、轮换、吊销和审计。secret 不进入源码、镜像、普通日志或共享配置；由受控密钥系统加密保存，工作负载通过身份换取短期凭证，或由 CSI/sidecar 注入内存/受限文件。环境变量易被进程转储和调试工具读取，并非所有场景的首选。传递时要防止命令行参数、构建缓存和错误输出泄露。

轮换要支持重叠窗口和双凭证：先发布新凭证、验证消费者加载，再吊销旧凭证；数据库等系统需控制连接存活期。泄露响应包括立即缩小权限/吊销、搜查使用范围、取证与替换，而不是仅删除 Git 历史。监控 secret 年龄、读取异常、轮换失败、未绑定 owner 和扫描发现，备份中的旧密钥也按敏感数据处理。

实践经验

某 API token 被 CI 调试日志打印，团队最初只隐藏日志。审计显示 token 已被下载到外部日志后端，且有效期一年。应急先吊销、限制供应商入口、检索调用记录并通知 owner，再更换所有引用；长期改用 OIDC 短期令牌、输出脱敏和 canary secret 检测。立即吊销造成一个遗留任务中断，因此事后建立消费者清单与双凭证轮换，而非以延长凭证寿命换稳定。

面试回答要点

PKI、mTLS 与证书轮换的关键边界是什么？¶

技术说明

PKI⁵ 以根 CA 建立信任，通常用离线根签中间 CA，再由短期签发器给工作负载证书。mTLS⁶ 同时验证服务端和客户端身份，但加密不等于授权：应用仍须根据 SPIFFE ID、SAN 或服务身份执行策略。证书验证包含链、用途、名称、时间和吊销/短有效期；不要依赖 CN 的模糊匹配，也不要把同一根信任无限扩展到所有环境和租户。

轮换要区分叶证书、签发中间 CA 和根 CA。根轮换的通用安全顺序是“先分发同时包含旧、新信任锚的 trust bundle—确认验证端已加载—切换签发—等待旧证书清退且旧锚使用归零—移除旧根”；中间 CA 轮换还要确认客户端是否错误地固定了中间证书。交叉签发、alternate chain 或服务端提供兼容链并非所有 TLS 栈都一致支持，只能在完整客户端矩阵验证后采用。轮换还需覆盖离线客户端、时钟偏差、长连接和缓存，并监控到期分布、签发失败、握手失败、证书身份与旧锚使用量。

实践经验

某内部网关更换中间 CA 后，约 8% 老客户端 TLS 失败。抓包和握手日志显示它们仅信任旧链，且配置热加载未生效。团队先恢复旧链签发并降低受影响流量权重，再发布同时包含旧、新锚的 trust bundle，逐一重载客户端后切换新链；长期建立根轮换演练、客户端清单和 30/14/7 天到期告警。双信任阶段扩大了暂时信任面，因此限定窗口并审计旧锚使用，确认旧证书清退后才移除旧根。

面试回答要点

如何隔离和加固 CI Runner？¶

技术说明

Runner 执行仓库提供的代码，应按不可信计算处理。按来源和权限拆池：fork/PR、受信主分支、发布签名任务不能共享持久宿主或凭证。优先一次性 VM/Pod、只读基础镜像、无特权模式、受限网络出口和最小 ServiceAccount；禁挂宿主 Docker socket、云元数据和其他作业工作区。缓存按信任域和内容摘要隔离，防止缓存投毒。

凭证只在获批 job 阶段按 OIDC⁷ 换取短期令牌，环境保护与人工审批控制生产权限。Runner 镜像、依赖和控制程序要固定版本、扫描并快速补丁；日志脱敏、作业审计和网络流量用于检测外传。终止后销毁计算与临时盘，验证没有残留进程。高隔离会增加启动延迟，可通过预热的无密钥镜像池折中。

实践经验

安全演练在 PR 作业中读取到上一任务留下的 .npmrc。团队立即停用池、吊销 token、检查包仓库访问并清理缓存；证据表明宿主复用和全局工作目录是根因。长期改为一次性 runner、每信任域缓存和 OIDC 发布，外部 PR 无秘密且禁止出站到内网。冷启动增加约一分钟，因此仅预拉公共镜像，不复用带状态执行环境。

面试回答要点

CI/CD 如何用 OIDC 联邦取代长期云密钥？¶

技术说明

CI 平台为 job 签发短期 OIDC token，云 STS 验证 issuer、签名、audience 及 subject 等 claims 后换取临时角色凭证。信任策略必须精确绑定组织、仓库、分支/环境、工作流和受保护上下文；只验证 issuer 而允许任意仓库，会把整个 SaaS 租户变成信任域。token 受众专用、寿命短，权限仍按目标资源最小化。

部署应先建立只读或测试角色，记录 claim 样本和拒绝原因，再灰度生产。防止可修改工作流在获得生产权限前执行任意代码：保护工作流文件、环境审批和 CODEOWNERS，并固定第三方 action。审计要把云会话映射回 commit、workflow run 和审批人；准备身份提供方不可用时的受控 break-glass，而不是保留常驻万能 key。

实践经验

某迁移初期把 subject 条件写成仓库通配符，测试仓库也能假设生产角色。策略模拟和 CloudTrail 会话证据发现问题后，团队先收紧到受保护环境并撤销旧静态 key，再加入工作流路径审批。严格条件导致分支命名变化时部署失败，因此将 claim 契约纳入测试并提供短期人工角色。相较长期密钥，故障面转为联邦可用性，但泄露窗口和轮换负担显著降低。

面试回答要点

SBOM 的作用、格式和运营方式是什么？¶

技术说明

SBOM⁸ 描述制品包含的组件、版本、依赖关系、标识和供应商信息，常见标准有 SPDX 与 CycloneDX。它帮助回答“受某漏洞影响的制品有哪些”，但不是漏洞报告，也不能证明组件真实来自可信构建。应在构建环境针对最终镜像/包生成，与制品 digest 绑定并作为发布附件保存；仅扫描源码会漏掉基础镜像、系统包和构建后引入内容。

质量比“有文件”更重要：覆盖率、可解析标识、依赖层级、许可证字段和生成器版本要验证。SBOM 进入资产/漏洞系统后，持续匹配新披露而非只在构建时查一次；制品删除和例外也要同步。对外共享需考虑内部包名等信息泄露，按受众提供合适视图，但不能篡改与发布制品绑定的原始记录。

实践经验

高危库披露后，团队搜索仓库依赖文件认为无影响，运行镜像却由旧基础层携带该库。镜像级 SBOM 对 digest 查询确认 37 个制品受影响，先阻止新部署并按暴露面排序修复；长期在最终镜像生成 SPDX/CycloneDX、签名关联并每日重评漏洞。生成 SBOM 增加流水线时间，因此并行执行且仅在发布门禁等待质量校验，开发快照异步处理。

面试回答要点

如何对容器和其他制品进行签名与验证？¶

技术说明

签名把身份对制品 digest 的声明绑定起来，标签可变，不能作为信任锚。可采用托管密钥或 Sigstore keyless：后者由 OIDC 身份获得短期证书，并把签名/证明记录到透明日志。验证不仅是“有签名”，还要检查允许的 issuer、subject、工作流、仓库、目标 digest、证书链和透明日志。keyless 证书在日后验证时通常已经过期，正确语义是用 Rekor inclusion time 或受信时间戳证明签名发生时证书处于有效期，而不是要求证书在当前时刻仍有效；不同环境可定义不同信任策略。

签名密钥需硬件或 KMS 保护、最小调用权限、轮换和吊销方案；keyless 则要保护 CI 身份和工作流。镜像复制到新 registry 后 digest 通常不变，但重新打包会失效。门禁上线采取 audit→warn→enforce，先处理历史制品和紧急回滚；离线/灾备时要设计可验证的信任材料缓存与有时限 break-glass。

实践经验

某集群策略只检查签名对象存在，攻击演练用测试项目身份签名后成功部署。审计发现 verifier 未限制 subject。团队先切为告警并阻止未知 issuer，随后将生产策略绑定受保护发布工作流、仓库和 digest，重签关键历史镜像。严格执行曾阻止一次紧急回滚，因此预先维护已验证回滚集合和双人 break-glass，所有例外进入审计和事后复核。

面试回答要点

Provenance 与 SLSA 解决什么问题？¶

技术说明

Provenance⁹ 是关于制品如何产生的可验证声明，通常包含 builder 身份、源仓库与 revision、构建参数、依赖材料和输出 digest。它与 SBOM 互补：SBOM 说“里面有什么”，provenance 说“谁在什么受控过程里从哪些输入构建”。SLSA¹⁰ 提供供应链完整性框架和等级/要求，用来评估构建平台与来源证明，采用时应标注规范版本并按官方要求核对，而非自创“SLSA 认证”营销结论。

高价值属性是证明由受信构建服务自动生成、调用者不能任意伪造，构建隔离且来源可追溯。验证器把证明 subject digest 与实际制品匹配，并校验 builder、仓库、分支与参数政策。provenance 可能包含敏感参数，需最小披露；可复现构建有助核验但不等于 provenance，也不是所有生态都能立即实现。

实践经验

一次镜像标签指向未知重建版本，仓库提交记录无法解释差异。团队用 registry digest、流水线日志和不完整证明限定影响，先冻结晋级并从已验证 digest 回滚；长期由隔离构建器生成 in-toto 格式 provenance，签名后随制品存储，部署只接受指定 builder 与受保护分支。门禁让本地手工热修无法直上生产，因此建立受审计的紧急构建流程，而不是开放绕过。

面试回答要点

漏洞扫描如何覆盖代码、依赖、镜像和运行环境？¶

技术说明

扫描是多层证据：SAST 找潜在代码模式，SCA/依赖扫描识别已知组件漏洞，secret/IaC 扫描发现凭证与配置风险，镜像扫描覆盖 OS 包和最终文件系统，DAST 在运行接口验证部分行为，运行时资产盘点确认真正暴露版本。单个 CVE 分值不足以排序，要结合可利用性、网络暴露、执行路径、数据敏感度、修复可用性及正在运行的制品。

门禁按风险和环境分层：新增严重且可利用问题阻止发布；存量进入有 SLA¹¹ 的治理；无修复版本可用补偿控制与限时例外。扫描器数据库更新会让同一制品结果变化，因此保存扫描时间、DB 版本与 SBOM，持续重评。抑制需绑定精确组件/digest、理由、owner 和到期日，不能用全局忽略文件长期掩盖。

实践经验

某高危 CVE 触发数百告警，实际只有三项互联网服务加载易受攻击模块。团队用 SBOM、运行清单、调用路径和入口策略排序，先隔离三项并更新，其余按 SLA 处理；而非全面停发。后续加入 EPSS/厂商分析等辅助证据但不自动取代人工判断。一次基础镜像更新引入兼容回归，说明补丁也需金丝雀和回滚，安全速度不能跳过稳定性验证。

面试回答要点

Kubernetes 准入控制应如何设计和渐进落地？¶

技术说明

准入控制位于认证、授权之后，在对象持久化前执行变更或校验。内置 Pod Security Admission 负责 Pod 安全级别；ValidatingAdmissionPolicy 用 CEL 校验请求对象、参数和授权上下文，适合限制镜像必须使用 digest、特权、hostPath、资源和标签等对象内字段，但不能主动访问 registry 做密码学签名验证。签名、provenance 或外部信誉检查需要能读取相应信任材料/registry 的策略引擎或 validating webhook，并单独设计缓存、超时与故障策略。变更型策略应谨慎，隐式改写会让 Git 清单与实际对象不一致；校验型规则错误信息需指出字段、原因和修复路径。

策略按 audit/warn/enforce 渐进，先统计命中、识别系统命名空间和合法例外，再限制新工作负载，最后治理存量。webhook 必须考虑超时、failurePolicy、可用性和调用环路：安全关键策略可 fail closed，但若控制器没有独立 HA，可能阻断全站发布；低风险元数据检查可 fail open 并告警。例外绑定 namespace/workload、owner、理由和到期日，策略与测试都版本化。

实践经验

某集群直接启用“禁止 root”强制规则，核心存储插件升级被拒，节点修复受阻。审计命中记录显示系统组件未经过兼容盘点。团队先回到 warn、为精确镜像 digest 创建短期例外，再修复镜像与安全上下文；长期以策略单元测试、影子集群和系统组件清单灰度。例外扩大风险面，所以限制账号、镜像和期限，并在部署后自动撤销。

面试回答要点

容器与 Kubernetes 运行时安全如何构建？¶

技术说明

运行时安全建立在预防和检测两层。预防包括非 root、只读根文件系统、删除 capabilities、seccomp/AppArmor/SELinux、禁止特权和宿主挂载、资源限制、NetworkPolicy、ServiceAccount 最小权限与节点隔离。镜像使用最小基线并固定 digest。注意容器不是强安全边界，对不可信多租户代码可采用沙箱运行时或独立节点/集群。

检测基于进程、系统调用、文件、网络、Kubernetes audit 和云控制面事件建立行为规则，例如容器启动 shell、写敏感路径、访问元数据或创建特权 Pod。规则需结合工作负载身份和版本降低噪声，响应动作分为记录、隔离网络、冻结副本和终止；自动 kill 可能破坏取证或可用性，必须按置信度和业务等级设门槛。节点镜像补丁和漂移检查同样重要。

实践经验

检测系统发现 Web Pod 启动异常 shell 并连接未知地址。团队先在负载均衡摘除副本、保留节点/容器快照、吊销 ServiceAccount token，再用审计日志确认无集群写操作；随后修补应用漏洞并限制出口。直接删除 Pod 虽快，却会丢失证据且重建后继续受攻击。长期启用只读根、默认拒绝网络和行为基线，同时演练隔离动作的可用性副作用。

面试回答要点

如何设计端到端安全的软件供应链？¶

技术说明

端到端链路从受保护源码开始：强身份与分支规则、依赖固定和审核；隔离的一次性构建器从声明输入构建；生成测试结果、SBOM 与 provenance；以受控身份对 digest 签名；制品库不可变、跨环境按 digest 晋级；部署端验证签名、来源和政策。生产部署不重新构建，防止测试与上线制品不同。

控制要覆盖第三方 action、构建镜像、包仓库和管理平面自身更新，并为每一步留可关联审计。信任根、签名服务和 CI 控制面属于最高价值资产，需独立权限和恢复方案。安全门禁不可用时预先定义 fail 策略与 break-glass，紧急路径仍由可信构建生成证明；否则一次事故就会永久绕过体系。

实践经验

某团队虽扫描镜像，却允许运维从笔记本重打 tag 推生产，导致实际 digest 未经过测试。发现后先冻结可变 tag 部署、盘点运行 digest 与流水线记录，回滚未知制品；长期实行 build-once、签名、不可变仓库和准入验证。严格流程使紧急修复多几分钟，因此预建快速流水线并保持小批次，而不是保留个人推送权限。

面试回答要点

多账号云环境的安全基线与组织级护栏怎样设计？¶

技术说明

按生产、非生产、安全、日志和共享服务拆账号/订阅，组织级策略限制高危区域、关闭审计、公开存储、长期根凭证等动作。集中身份联邦与 MFA，日志写入独立安全账号并防篡改；网络出口、DNS、密钥和镜像可集中提供但保留故障隔离。护栏区分预防、检测与响应，不能只靠一组 deny 规则，因为过严策略也可能阻断灾备。

Landing Zone 通过 IaC 创建账号、基线角色、日志、配置检查与预算，持续检测手工漂移。break-glass 身份离线保护、双人启用、短时有效且实时告警。跨账号信任精确限制 principal、external ID/条件和组织边界。合规证据自动收集控制状态，但截图“已开启”不能替代配置历史与演练。

实践经验

一次子账号误把对象存储设为公网，组织检测十分钟后才报警。团队先撤销策略、检查访问日志和对象敏感度，再用组织级预防控制禁止公网 ACL；确需公开的静态站点走专用分发账号。全局 deny 曾阻碍应急日志共享，因此为安全账号建立精确例外并测试。长期以新账号自动基线和漂移修复缩短暴露窗口，而非依赖人工月检。

面试回答要点

零信任与服务间 mTLS 应如何落地而不流于口号？¶

技术说明

零信任核心是每次访问基于可验证身份、设备/工作负载状态、资源和上下文做最小授权，不因“在内网”默认可信。服务网格可自动签发短期身份和 mTLS，但只开启加密还不够；授权策略要从服务调用图推导，默认拒绝后允许精确方法/服务，且数据层、云 API 与人类运维访问也要覆盖。

落地先观测实际流量和身份，修复无身份/直连路径，再对单一命名空间启用严格模式，逐步扩大。DNS、控制面、证书签发和 sidecar/代理成为新依赖，需 HA、容量和绕过检测。授权规则必须版本化、测试和关联 owner；紧急诊断采用短时、细粒度访问而非打开整个网段。

实践经验

某集群启用 permissive mTLS 后便宣称零信任，但被攻陷 Pod 仍可调用所有内部 API。流量与策略审计显示只有传输加密，没有授权。团队先限制高价值支付接口、轮换身份并监控拒绝，再按调用图推广默认拒绝。旧任务无 sidecar 导致失败，因此设迁移窗口和显式网关，不长期保留明文旁路。代理增加少量延迟和资源，容量模型同步调整。

面试回答要点

安全事件响应与普通可用性事故有何不同？¶

技术说明

安全事件除恢复服务，还要遏制攻击、保存证据、确定入侵范围、满足通知与法律要求。流程包括准备、检测分析、遏制、清除、恢复和事后改进；指挥链应尽早引入安全、法务、隐私和业务。证据采用统一时间、哈希和保管链，避免随意重启/删除破坏内存、日志或磁盘状态。沟通遵循最小知情和批准渠道，不能在公开频道暴露攻击细节。

遏制分短期与长期：隔离账号/主机、吊销令牌、阻断出口，同时评估会否提示攻击者或中断关键业务。恢复使用已知可信镜像和凭证，验证持久化机制已清除，并扩大搜寻相同 IOC。若身份根或构建链被攻陷，不能简单“重部署原镜像”。日志留存、时钟同步和预置取证权限决定响应上限。

实践经验

某云密钥出现异常跨地域调用。团队未立刻删除实例，而是先限制角色策略、保存审计/流量/磁盘证据并轮换相关秘密；分析显示密钥源自 CI 日志，无主机持久化。随后重建 runner、核查所有会话并从可信制品恢复。限制策略短时影响批处理，因此按业务优先级恢复。长期开展密钥 canary、出站检测和桌面演练，并记录监管通知判断依据。

面试回答要点

如何建设可用于审计和取证的日志体系？¶

技术说明

优先记录身份认证、权限/策略变更、密钥访问、控制面写操作、制品签名/部署、数据导出和 break-glass。事件包含可信时间、主体、会话、来源、目标、动作、结果、请求 ID 和变更前后摘要；不要记录 secret 或完整敏感载荷。日志从源账号实时写入隔离账号/存储，使用不可变保留、加密、细粒度读取和查询审计，生产管理员不能删除自己的轨迹。

完整性需监控“应有而未到”的日志：心跳、摄入延迟、序列缺口、解析失败和来源覆盖率。时间同步与统一字段便于跨系统关联，留存由威胁模型、法规和调查周期确定。取证查询有工单/审批和最小权限，导出证据做哈希；定期用已知操作验证从产生到检索，而不是只检查存储桶存在。

实践经验

一次权限滥用调查发现关键账号审计日志被写在同账号，管理员可停用采集且无告警。团队先导出剩余日志并结合 IdP、云账单和网络流量重建时间线；长期集中到安全账号、组织级禁止关闭并加入摄入心跳。不可变留存提高存储成本，因此按事件价值分层，但身份/权限和生产控制面保留满足调查窗口，普通调试日志不混用相同策略。

面试回答要点

如何制定漏洞修复 SLA 和风险例外机制？¶

技术说明

SLA 不应只按 CVSS 一刀切，而按严重度、已知利用、互联网暴露、资产关键性、数据权限、修复可用性和补偿控制分层。明确起算点、修复/缓解定义、环境范围与验证方式；例如“更新包”不算完成，必须确认运行 digest、版本和攻击路径。零日可采用更短遏制目标，低风险不可达组件则合理排期。

例外由业务与安全共同接受，记录精确资产/digest、漏洞、理由、补偿控制、owner、到期日和复审条件。到期自动升级或阻止发布，不能无限续签。看板跟踪逾期风险、平均修复时间、重开率、覆盖率和例外老化，但避免用“关闭工单数”驱动错误行为。修补后的兼容性与可用性同样要金丝雀验证。

实践经验

某旧数据库插件含高危漏洞但没有上游补丁，直接卸载会中断结算。团队验证攻击路径仅来自管理网，先收紧网络、禁用易受攻击功能并增强检测，签署 30 天例外；同时迁移替代组件。每周复核暴露面，最终用运行版本扫描和渗透用例验收。补偿控制增加运维复杂度，因此例外不是永久方案，期限与迁移里程碑绑定。

面试回答要点

Policy as Code 的价值与治理边界是什么？¶

技术说明

Policy as Code 把安全、合规和平台规则写成可版本控制、测试、评审和自动执行的策略，用于 IaC 计划、CI、制品和 Kubernetes 准入。策略输入必须稳定且可解释，输出包含规则 ID、证据和修复建议；将“生产存储必须加密”表达为机器可验证条件，比文档提醒更一致。不是所有判断都适合自动阻断，模糊业务风险应提示或进入人工评审。

策略像产品管理：owner、语义版本、单元/回归测试、样本资源、影响预览、灰度和撤回。集中规则提供最低基线，团队可在限定范围扩展；例外是同一系统中的有期限对象。监控执行延迟、失败、命中、误报、绕过和未覆盖资源。控制面不可用时根据规则风险选择 fail closed/open，并保留审计。

实践经验

某 IaC 规则禁止所有公网入口，却误伤受控 CDN 源站，团队开始在流水线普遍跳过扫描。通过命中样本和架构证据，规则改为要求指定前置防护、端口和 owner，而非简单禁止。先以告警回放历史计划，再强制新增资源。策略更精确后代码复杂度上升，因此建立测试夹具和规则评审，不允许项目自行复制修改中央策略。

面试回答要点

如何让 DevSecOps 成为团队能力而不是安全部门门禁？¶

技术说明

安全团队定义威胁模型、最低护栏和咨询路径，平台把常见控制做成默认模板、短期身份、受信构建与可解释门禁；应用团队仍拥有本服务风险与修复。每个产品设安全 champion，但不把其变成兼职审批员。通过设计阶段评审、轻量滥用案例、IDE/PR 快反馈和生产验证把反馈左移，同时保留运行时检测，因为左移不能覆盖配置漂移和新漏洞。

指标兼顾结果与体验：高风险暴露时间、例外老化、受信制品覆盖、secret 年龄、修复前置时间、误报和开发者任务成功率。避免按发现漏洞数惩罚团队，这会诱导少扫描/少报告。培训以实际架构和演练为主；复盘跨团队共享模式，平台优先修复重复问题，使安全默认路径比绕过更容易。

实践经验

某组织集中安全审批平均等待五天，开发团队转而共享管理员账号应急。数据表明大多数请求是重复的标准访问。团队把低风险路径产品化为短期 JIT 权限和自动证据，高风险仍人工审批；安全人员转向威胁建模和异常复核。自助提高请求量，故增加预算、速率限制和审计。最终以等待时间、过权率和事件数共同验证，而非只宣传“左移”。

面试回答要点