现状评估与路线图
先看代码仓库、分支策略、CI/CD、镜像仓库、Kubernetes 和发布流程,把问题分成「已经在做 / 缺失 / 只有形式」三类,再给一份按风险排序、可分阶段落地的路线图。不先采购工具。
服务 01 · DevSecOps
安全不是上线前的一次检查,而是提交、构建、部署、运行这条链上的默认动作。目标是一套团队自己能维护的流程,而不是一套只有顾问会用的工具。
先看代码仓库、分支策略、CI/CD、镜像仓库、Kubernetes 和发布流程,把问题分成「已经在做 / 缺失 / 只有形式」三类,再给一份按风险排序、可分阶段落地的路线图。不先采购工具。
在现有 CI(GitLab CI、GitHub Actions 或 Jenkins)里接入 SAST、SCA、Secret 扫描和镜像漏洞扫描。门禁区分阻断与告警:新问题阻断,存量问题限期清理,避免一上线就满屏红灯。
生成并归档 SBOM,锁定依赖与基础镜像版本,用 cosign 做镜像签名与验签,隔离构建环境与制品仓库。让「这个镜像从哪来、由什么构建」随时可以被回答。
用 Terraform、Helm、Kustomize 管理环境;用 Checkov / tfsec 扫描 IaC,用 OPA / Gatekeeper / Kyverno 做策略即代码。环境差异写在代码里,而不是留在某个人记得的步骤里。
RBAC 最小权限、NetworkPolicy 分区、Pod Security Standards、Secrets 外置(External Secrets / Vault)、镜像准入控制与 Falco 运行时检测。集群从「能跑」到「知道谁在跑什么」。
为漏洞修复定 SLA,给门禁通过率、平均修复时间建指标与告警;写值班手册,做一次故障与回滚演练。最后把仓库、文档和权限一起交接,团队能自己往下走。
按周推进,每一步都能停下来。不会一次性推翻现有流程,也不会把风险留到最后一天。
访谈加现场查看:仓库、流水线、镜像、集群、发布流程。输出现状与风险清单,确认范围和优先级。
流水线、扫描、门禁、IaC 与集群基线逐项落地。每项改动都可回滚,先小范围生效再推广。
选一个真实服务,从提交到上线完整走一遍,修掉阻断级问题,验证门禁不会把正常交付卡死。
交付文档、权限和演练记录,留 30 天答疑窗口。之后按需支持,不做长期驻场。
需要你提供三样东西:仓库与 CI 的只读权限、一个非生产集群或命名空间、一位能拍板的负责人。时间窗口越明确,方案越具体。
如果还没有 Kubernetes,可以先从 CI 与镜像供应链做起;如果连自动化构建都还没有,先补这一步——DevSecOps 的门禁需要有地方可挂。
不卖工具许可证,也不绑定供应商。优先用你已有的 CI、云服务和开源组件,缺什么补什么;确实需要商业产品时,会给出选型理由和退出方案。
服务 02 · Security
三类问题经常同时出现:应用里的权限与数据、云上的身份与网络、AI 功能带来的新边界。可以只做其中一类,也可以放在一次评审里一起看。
从设计到代码,找出真正能被利用的问题,并给出可落地的修法。
把云上的默认配置收紧到与业务风险匹配的程度,而不是把开关全部关死。
在 LLM 功能上线前,先把提示词、数据边界和工具权限这三件事说清楚。
合作方式
可以是一次性的评审,也可以是围绕一次上线或一个季度的专项。范围先写清楚,再开始。
针对一个系统或一次上线:架构、代码、配置和云环境一起看。产出按风险排序的问题清单、复现步骤与修复建议,并开一次评审会讲清楚。
围绕一个明确目标推进,例如「通过客户安全问卷」「上线前完成 K8s 加固」「LLM 功能安全上线」。包含设计、实施与复测,不只给建议。
每月固定时间做设计评审、上线前把关和答疑。不占全职编制,但能保持连续性——安全最容易失效的地方,是没人持续看。
工作方式
安全方案没有通用模板。同样的门禁,在一个十人团队和一家受监管企业里,成本和收益完全不同。
所以每次都从现状出发:先确认要保护什么、能接受多少摩擦,再决定加哪几道闸。宁可少加一层,也不做一套没人维护的控制。
先看日志、权限和真实交付路径,不拿一套清单套所有团队。
优先集成现有 CI、云和开源组件,不绑定供应商,不卖许可证。
交付文档、演练和权限交接;顾问离开后流程仍然有效,才算完成。