服务 · DevSecOps & Security

把安全,
装进交付流程。

除了做产品,也为团队搭建 DevSecOps 环境、处理应用、云和 AI 的安全问题。方式不是丢下一份报告,而是和你的团队一起,把流水线、集群和权限改成能长期跑的样子。

一条从代码提交到上线运行的交付流水线,每个环节之间设有安全检查点

从提交到上线 · 每个环节都有门禁

服务 01 · DevSecOps

企业级 DevSecOps
环境搭建

安全不是上线前的一次检查,而是提交、构建、部署、运行这条链上的默认动作。目标是一套团队自己能维护的流程,而不是一套只有顾问会用的工具。

01

现状评估与路线图

先看代码仓库、分支策略、CI/CD、镜像仓库、Kubernetes 和发布流程,把问题分成「已经在做 / 缺失 / 只有形式」三类,再给一份按风险排序、可分阶段落地的路线图。不先采购工具。

02

流水线与安全门禁

在现有 CI(GitLab CI、GitHub Actions 或 Jenkins)里接入 SAST、SCA、Secret 扫描和镜像漏洞扫描。门禁区分阻断与告警:新问题阻断,存量问题限期清理,避免一上线就满屏红灯。

03

软件供应链

生成并归档 SBOM,锁定依赖与基础镜像版本,用 cosign 做镜像签名与验签,隔离构建环境与制品仓库。让「这个镜像从哪来、由什么构建」随时可以被回答。

04

基础设施即代码

用 Terraform、Helm、Kustomize 管理环境;用 Checkov / tfsec 扫描 IaC,用 OPA / Gatekeeper / Kyverno 做策略即代码。环境差异写在代码里,而不是留在某个人记得的步骤里。

05

Kubernetes 运行时

RBAC 最小权限、NetworkPolicy 分区、Pod Security Standards、Secrets 外置(External Secrets / Vault)、镜像准入控制与 Falco 运行时检测。集群从「能跑」到「知道谁在跑什么」。

06

运营与交接

为漏洞修复定 SLA,给门禁通过率、平均修复时间建指标与告警;写值班手册,做一次故障与回滚演练。最后把仓库、文档和权限一起交接,团队能自己往下走。

交付节奏

按周推进,每一步都能停下来。不会一次性推翻现有流程,也不会把风险留到最后一天。

  • 01

    第 1 周 · 评估

    访谈加现场查看:仓库、流水线、镜像、集群、发布流程。输出现状与风险清单,确认范围和优先级。

  • 02

    第 2–4 周 · 搭骨架

    流水线、扫描、门禁、IaC 与集群基线逐项落地。每项改动都可回滚,先小范围生效再推广。

  • 03

    第 5–6 周 · 跑通一条真实链路

    选一个真实服务,从提交到上线完整走一遍,修掉阻断级问题,验证门禁不会把正常交付卡死。

  • 04

    交接与陪跑

    交付文档、权限和演练记录,留 30 天答疑窗口。之后按需支持,不做长期驻场。

开始之前

需要你提供三样东西:仓库与 CI 的只读权限、一个非生产集群或命名空间、一位能拍板的负责人。时间窗口越明确,方案越具体。

如果还没有 Kubernetes,可以先从 CI 与镜像供应链做起;如果连自动化构建都还没有,先补这一步——DevSecOps 的门禁需要有地方可挂。

不卖工具许可证,也不绑定供应商。优先用你已有的 CI、云服务和开源组件,缺什么补什么;确实需要商业产品时,会给出选型理由和退出方案。

服务 02 · Security

安全服务:
应用、云、AI

三类问题经常同时出现:应用里的权限与数据、云上的身份与网络、AI 功能带来的新边界。可以只做其中一类,也可以放在一次评审里一起看。

01

App Security

从设计到代码,找出真正能被利用的问题,并给出可落地的修法。

  • 威胁建模与架构评审
  • 认证、授权与会话(OIDC / JWT / RBAC)
  • API 越权、注入与速率限制
  • 依赖与软件供应链风险
  • 移动端存储与传输安全
  • 漏洞修复方案与复测建议
02

Cloud Security

把云上的默认配置收紧到与业务风险匹配的程度,而不是把开关全部关死。

  • 云账号与 IAM 最小权限
  • VPC、安全组与出口控制
  • Kubernetes 与容器加固
  • 密钥与配置管理
  • 审计日志与告警接入
  • 备份、恢复与演练
03

AI Security

在 LLM 功能上线前,先把提示词、数据边界和工具权限这三件事说清楚。

  • LLM 应用威胁建模
  • Prompt injection 与工具调用越权
  • RAG 数据边界与租户隔离
  • Agent 权限与人工确认点
  • 模型与依赖供应链、版本锁定
  • 输出过滤、审计日志与数据留存

合作方式

三种合作方式

可以是一次性的评审,也可以是围绕一次上线或一个季度的专项。范围先写清楚,再开始。

1–2 周

安全评审

针对一个系统或一次上线:架构、代码、配置和云环境一起看。产出按风险排序的问题清单、复现步骤与修复建议,并开一次评审会讲清楚。

2–6 周

专项加固

围绕一个明确目标推进,例如「通过客户安全问卷」「上线前完成 K8s 加固」「LLM 功能安全上线」。包含设计、实施与复测,不只给建议。

按月

长期顾问

每月固定时间做设计评审、上线前把关和答疑。不占全职编制,但能保持连续性——安全最容易失效的地方,是没人持续看。

工作方式

先测量,再动手。

安全方案没有通用模板。同样的门禁,在一个十人团队和一家受监管企业里,成本和收益完全不同。

所以每次都从现状出发:先确认要保护什么、能接受多少摩擦,再决定加哪几道闸。宁可少加一层,也不做一套没人维护的控制。

  • 01

    用数据和流程定位问题

    先看日志、权限和真实交付路径,不拿一套清单套所有团队。

  • 02

    用你已有的技术栈

    优先集成现有 CI、云和开源组件,不绑定供应商,不卖许可证。

  • 03

    目标是你能自己跑

    交付文档、演练和权限交接;顾问离开后流程仍然有效,才算完成。

下一步

想先聊聊你的环境?