安全开发流程SOP-从需求到上线的安全检查点

安全开发流程SOP——从需求到上线的安全检查点

标签：安全开发|SDL|安全检查点|DevSecOps|安全左移|流程规范

日期：2026年9月20日

一句话简介：面向研发团队、安全团队与项目管理者的安全开发流程标准作业程序，覆盖需求、设计、开发、测试、

发布、上线、运维七个阶段的安全检查点，提供可复制的检查清单、评审模板、门禁规则与完整案例。

关键词：安全开发生命周期、安全需求、威胁建模、安全编码、代码审计、安全测试、上线检查、安全门禁、漏洞管

理、应急响应

适用人群：研发工程师、测试工程师、安全工程师、DevOps工程师、技术管理者、项目经理、产品经理

文档类型：教程攻略类

目录

1.流程总览

2.阶段一：需求阶段安全检查点

3.阶段二：设计阶段安全检查点

4.阶段三：开发阶段安全检查点

5.阶段四：测试阶段安全检查点

6.阶段五：发布阶段安全检查点

7.阶段六：上线阶段安全检查点

8.阶段七：运维阶段安全检查点

9.完整案例：示例公司安全开发流程落地

10.工具与材料清单

11.避坑指南

12.常见问题解答

13.附录：模板、清单、与速查表

1.流程总览

1.1流程目标

安全开发流程SOP的目标是将安全活动嵌入软件开发生命周期的每个阶段，实现安全左移，降低修复成本，减少上线

后漏洞，满足合规要求。核心原则：安全不是上线前的一次性检查，而是贯穿需求到运维的持续活动。

1.2七阶段模型

阶

核心安全活动主要输出责任角色

段

需

安全需求识别、合规需求梳理安全需求清单产品经理、安全工程师

求

设

威胁建模、架构评审威胁模型、安全设计文档架构师、安全工程师

计

开安全编码、代码审计、依赖检查、密钥扫代码审计报告、依赖检查报开发工程师、安全工程

发描告师

测测试工程师、安全工程

安全测试、漏洞扫描、渗透测试安全测试报告

试师

发

发布评审、门禁检查发布检查清单项目经理、安全工程师

布

上运维工程师、安全工程

上线验证、配置核查上线检查报告

线师

运运维工程师、安全工程

监控告警、漏洞管理、应急响应运维安全报告

维师

1.3安全门禁

安全门禁是在关键节点设置的强制检查，未通过则阻断流程。

门禁编

门禁位置检查内容阻断条件放行条件

号

需求评审通

G1安全需求是否识别未识别安全需求安全需求清单完整

过后

设计评审通威胁模型与缓解措施完

G2威胁建模是否完成未完成威胁建模

过后整

代码审计、依赖检查、密存在高危缺陷或硬编高危清零，中危有修复

G3代码合并前

钥扫描码密钥计划

G4测试完成安全测试是否通过存在高危漏洞高危修复并复测通过

G5发布评审发布检查清单是否完成检查项未完成全部检查项通过

G6上线前配置核查是否通过配置不合规配置核查通过

G7上线后监控告警是否就绪监控未就绪监控告警生效

1.4角色与职责

角色安全职责参与阶段

产品经理识别安全需求、合规需求需求、设计、发布

架构师安全架构设计、威胁建模设计

开发工程师安全编码、修复漏洞开发、测试

测试工程师安全测试、漏洞验证测试

安全工程师安全评审、代码审计、渗透测试全阶段

运维工程师安全配置、监控告警上线、运维

项目经理协调安全活动、跟踪整改全阶段

合规专员合规需求梳理、合规检查需求、发布

1.5流程与CI/CD集成

CI/CD阶段集成安全活动工具类别阻断策略

代码提交密钥扫描、预提交钩子密钥扫描工具检测到密钥阻断提交

合并请求静态扫描、依赖检查SAST、SCA高危阻断合并

构建依赖检查、镜像扫描SCA、镜像扫描高危阻断构建

测试动态扫描、安全测试DAST、自动化测试高危阻断发布

部署配置检查、基线检查配置检查工具不合规阻断部署

运行监控告警、异常检测监控平台告警通知

1.6零基础操作引导：查看当前流程阶段

在哪里查看：在项目管理系统中打开项目看板。

怎么查看：找到当前迭代或版本，查看看板列，确认当前处于哪个阶段。

结果长什么样：看板显示“需求”“设计”“开发”“测试”“发布”“上线”“运维”列，卡片位于对应列。

报错了怎么办：看不到看板时，检查是否有项目访问权限；卡片缺失时，检查是否被过滤条件隐藏。

2.阶段一：需求阶段安全检查点

2.1阶段目标

在需求阶段识别安全需求与合规需求，避免后期返工。安全需求应写入需求文档，作为验收标准之一。

2.2检查点清单

检查点编

检查项检查内容责任角色输出

号

R-01数据分类分级识别需求涉及的个人信息与敏感数据产品经理数据分类清单

R-02合规需求识别适用法律法规与标准合规专员合规需求清单

R-03安全功能需求识别认证、授权、加密、审计需求产品经理安全需求清单

安全非功能需非功能需求清

R-04识别性能、可用性、可审计性需求产品经理

求单

识别告知同意、最小收集、用户权利需

R-05隐私需求合规专员隐私需求清单

求

第三方组件需开发工程

R-06识别拟引入的第三方组件与许可证组件清单

求师

数据留存与销

R-07识别数据留存期限与销毁方式合规专员留存销毁清单

毁

R-08安全验收标准将安全需求转化为可验证的验收标准产品经理验收标准

2.3安全需求识别方法

方法说明适用场景

需求访谈与业务方、合规方访谈新业务、新功能

清单对照对照安全需求清单逐项确认常规迭代

法规对照对照法规条款识别需求合规相关

历史漏洞对照对照历史漏洞识别同类需求已有系统迭代

威胁建模反推从威胁反推安全需求高风险功能

2.4安全需求模板

安全需求清单

项目名称：【项目名称】

需求编号：【需求编号】

编制日期：【日期】

编制人：【姓名】

一、数据分类分级

1.涉及个人信息字段：【字段列表】

2.数据级别：【L1/L2/L3/L4】

3.处理目的：【目的说明】

4.处理范围：【范围说明】

二、合规需求

1.适用法规：【法规名称】

2.合规要求：【要求列表】

3.合规责任人：【姓名】

三、安全功能需求

1.认证要求：【要求说明】

2.授权要求：【要求说明】

3.加密要求：【要求说明】

4.审计要求：【要求说明】

5.脱敏要求：【要求说明】

四、安全非功能需求

1.性能要求：【要求说明】

2.可用性要求：【要求说明】

3.可审计性要求：【要求说明】

五、隐私需求

1.告知同意方式：【方式说明】

2.最小收集范围：【范围说明】

3.用户权利支持：【权利列表】

六、第三方组件需求

1.拟引入组件：【组件列表】

2.许可证要求：【要求说明】

七、数据留存与销毁

1.留存期限：【期限说明】

2.销毁方式：【方式说明】

八、安全验收标准

1.【验收标准一】

2.【验收标准二】

3.【验收标准三】

2.5需求阶段安全检查清单

检查项检查内容标准结果

数据分类是否识别个人信息字段全部识别通过/不通过

合规需求是否识别适用法规全部识别通过/不通过

安全功能是否识别认证授权加密审计全部识别通过/不通过

检查项检查内容标准结果

隐私需求是否识别告知同意与用户权利全部识别通过/不通过

第三方组件是否识别组件与许可证全部识别通过/不通过

留存销毁是否识别留存期限与销毁方式全部识别通过/不通过

验收标准是否转化为可验证标准全部转化通过/不通过

2.6需求阶段完整案例

背景：示例公司计划开发一个用户管理功能，支持用户注册、登录、资料修改、注销。产品经理在需求阶段邀请安全

工程师与合规专员参与评审。

操作步骤：

1.产品经理梳理功能需求，识别涉及的个人信息：手机号、邮箱、姓名、身份证号。

2.安全工程师识别数据级别：手机号、邮箱、姓名为L3，身份证号为L4。

3.合规专员识别适用法规：个人信息保护法、数据安全法、网络安全法。

4.安全工程师识别安全功能需求：登录需多因素认证，密码需强哈希存储，敏感字段需加密存储，操作需审计日

志。

5.合规专员识别隐私需求：注册时需告知同意，支持用户查询、更正、删除个人信息，支持注销账号。

6.开发工程师识别第三方组件需求：拟引入密码哈希库、加密库、日志库，需确认许可证。

7.合规专员识别数据留存期限：账号注销后30天内删除个人信息，留存期限届满自动销毁。

8.产品经理将安全需求转化为验收标准：敏感字段密文存储、登录失败锁定、操作日志完整、用户可注销。

9.安全工程师与合规专员确认需求清单完整，签字确认。

10.需求清单进入设计阶段，作为设计输入。

结果：安全需求在需求阶段识别完整，避免后期返工，合规要求明确，验收标准可验证。

2.7需求阶段避坑指南

1.不要等到开发阶段才考虑安全需求。

2.不要忽略隐私需求，如告知同意、用户权利。

3.不要忽略数据留存与销毁要求。

4.不要忽略第三方组件许可证。

5.不要将安全需求写成无法验证的模糊表述。

6.不要忽略合规要求的更新。

7.不要让安全工程师独自承担需求识别，产品经理是第一责任人。

3.阶段二：设计阶段安全检查点

3.1阶段目标

在设计阶段完成威胁建模与安全架构评审，识别架构级风险，确定缓解措施，避免架构缺陷导致后期难以修复。

3.2检查点清单

检查点编号检查项检查内容责任角色输出

D-01威胁建模识别威胁、评估风险、确定缓解措施安全工程师威胁模型

D-02架构评审评审认证、授权、加密、审计架构架构师架构评审记录

D-03数据流分析分析数据流转路径与信任边界安全工程师数据流图

D-04密钥管理设计设计密钥生成、存储、使用、轮换安全工程师密钥管理方案

D-05权限模型设计设计角色、权限、数据范围架构师权限模型

D-06脱敏方案设计设计脱敏场景、规则、算法安全工程师脱敏方案

D-07审计日志设计设计日志内容、存储、访问控制安全工程师审计方案

D-08接口安全设计设计鉴权、限流、防重放架构师接口安全方案

D-09错误处理设计设计错误信息、日志记录、异常处理架构师错误处理方案

D-10安全配置设计设计安全配置项与默认值安全工程师配置清单

3.3威胁建模方法

方法说明适用场景

STRIDE欺骗、篡改、否认、信息泄露、拒绝服务、权限提升通用

DREAD危害程度、可复现性、可利用性、影响用户、可发现性风险评估

攻击树从攻击目标反推攻击路径高风险功能

数据流图分析数据流转与信任边界架构设计

滥用案例从滥用角度识别威胁业务逻辑

3.4STRIDE威胁模型

威胁类型说明示例缓解措施

欺骗冒充他人身份伪造令牌强认证、多因素认证

篡改修改数据或代码修改请求参数完整性校验、签名

否认否认操作行为否认转账操作审计日志、数字签名

威胁类型说明示例缓解措施

信息泄露泄露敏感信息数据库泄露加密、脱敏、最小权限

拒绝服务服务不可用大量请求限流、熔断、扩容

权限提升获取更高权限越权访问最小权限、权限校验

3.5威胁模型模板

威胁模型

项目名称：【项目名称】

版本：【版本号】

编制日期：【日期】

编制人：【姓名】

一、系统描述

1.系统功能：【功能说明】

2.用户角色：【角色列表】

3.数据资产：【资产列表】

4.信任边界：【边界说明】

二、数据流

1.数据入口：【入口说明】

2.数据处理：【处理说明】

3.数据存储：【存储说明】

4.数据出口：【出口说明】

三、威胁识别

|威胁编号|威胁类型|威胁描述|受影响资产|风险级别|

|---|---|---|---|---|

|T-01|信息泄露|数据库泄露导致个人信息泄露|用户表|高|

|T-02|权限提升|越权访问他人数据|用户表|高|

|T-03|欺骗|伪造登录令牌|认证系统|高|

四、缓解措施

|威胁编号|缓解措施|责任人|验证方式|

|---|---|---|---|

|T-01|敏感字段加密存储|开发工程师|数据库检查|

|T-02|权限校验+最小权限|开发工程师|权限测试|

|T-03|令牌签名+过期时间|开发工程师|安全测试|

五、残余风险

1.【残余风险一】

2.【残余风险二】

3.6设计阶段安全检查清单

检查项检查内容标准结果

威胁建模是否完成覆盖全部资产通过/不通过

架构评审是否完成覆盖认证授权加密审计通过/不通过

数据流分析是否完成覆盖全部信任边界通过/不通过

密钥管理是否设计覆盖生成存储使用轮换通过/不通过

权限模型是否设计最小权限、职责分离通过/不通过

脱敏方案是否设计覆盖全部敏感字段通过/不通过

审计日志是否设计覆盖全部敏感操作通过/不通过

接口安全是否设计鉴权、限流、防重放通过/不通过

错误处理是否设计不泄露敏感信息通过/不通过

安全配置是否设计默认安全通过/不通过

3.7设计阶段完整案例

背景：示例公司用户管理功能进入设计阶段，安全工程师组织威胁建模会议，参与人员包括架构师、开发工程师、测

试工程师、产品经理。

操作步骤：

1.安全工程师描述系统：用户注册、登录、资料修改、注销，数据资产包括用户表、日志表。

2.绘制数据流图：用户通过前端提交数据，经网关、应用、数据库，数据出口包括接口返回、日志。

3.识别信任边界：前端到网关、网关到应用、应用到数据库、应用日志。

4.使用STRIDE识别威胁：欺骗（伪造令牌）、篡改（修改参数）、否认（否认操作）、信息泄露（数据库泄

露）、拒绝服务（大量请求）、权限提升（越权访问）。

5.评估风险：信息泄露与权限提升为高风险，欺骗为中高风险，拒绝服务为中风险。

6.确定缓解措施：敏感字段加密、权限校验、令牌签名、限流、审计日志。

7.评审架构：认证使用多因素认证，授权使用RBAC+ABAC，加密使用AES-256-GCM，审计日志独立存储。

8.设计密钥管理：主密钥存储于密钥管理服务，数据密钥随数据存储，每季度轮换。

9.设计脱敏方案：客服查看手机号掩码，主管查看完整，身份证号需审批。

10.输出威胁模型与安全设计文档，进入开发阶段。

结果：架构级风险在设计阶段识别并缓解，开发阶段有明确的安全设计输入，避免后期返工。

3.8设计阶段避坑指南

1.不要跳过威胁建模，尤其是高风险功能。

2.不要只关注技术威胁，忽略业务逻辑威胁。

3.不要忽略信任边界，内部网络同样需要防护。

4.不要将缓解措施写成无法验证的模糊表述。

5.不要忽略残余风险，需记录并接受。

6.不要让安全工程师独自完成威胁建模，需多方参与。

7.不要忽略安全设计的可实施性，需与开发工程师确认。

4.阶段三：开发阶段安全检查点

4.1阶段目标

在开发阶段通过安全编码、代码审计、依赖检查、密钥扫描，发现并修复代码层缺陷，防止漏洞进入测试与生产环

境。

4.2检查点清单

检查点编号检查项检查内容责任角色输出

C-01安全编码规范开发人员遵循安全编码规范开发工程师代码

C-02代码审计静态扫描发现代码缺陷安全工程师代码审计报告

C-03依赖检查扫描第三方组件漏洞与许可证安全工程师依赖检查报告

C-04密钥扫描扫描硬编码密钥与敏感信息安全工程师密钥扫描报告

C-05代码评审人工评审安全相关代码开发工程师评审记录

C-06预提交检查提交前执行密钥扫描与格式检查开发工程师提交记录

C-07合并请求检查合并前执行静态扫描与依赖检查安全工程师合并请求记录

C-08安全缺陷修复修复审计发现的高危缺陷开发工程师修复记录

C-09安全组件使用使用安全库与安全API开发工程师代码

C-10安全注释对安全相关代码添加注释开发工程师代码

4.3安全编码规范要点

类别规范要点错误示例正确示例

输入校验所有外部输入必须校验直接使用请求参数白名单校验、类型校验

输出编码输出到页面必须转义直接输出用户输入HTML转义、上下文编码

类别规范要点错误示例正确示例

SQL操作使用参数化查询字符串拼接SQL预编译语句

文件操作路径白名单校验直接拼接路径规范化路径、白名单

命令执行避免执行系统命令拼接命令字符串使用安全API、白名单

密码存储使用强哈希加盐MD5、SHA-1Argon2、bcrypt

加密使用安全算法与模式ECB、弱密钥AES-256-GCM

随机数使用密码学安全随机数普通随机数密码学安全随机数

错误处理不泄露敏感信息返回堆栈信息返回通用错误

日志不记录敏感信息记录密码、密钥脱敏记录

会话会话安全会话不过期设置过期时间、安全标志

权限每次操作校验权限仅前端校验后端校验

依赖使用安全版本使用已知漏洞版本使用最新安全版本

配置默认安全配置默认密码、调试开启强制修改、关闭调试

4.4代码审计操作步骤

1.确定审计范围：业务代码、配置文件、构建脚本。

2.选择扫描规则：高危规则优先，按技术栈选择。

3.配置扫描：排除第三方库、生成代码、测试数据。

4.执行扫描：运行静态扫描工具，生成报告。

5.分析结果：按严重级别、文件、缺陷类型分组。

6.人工复核：确认可利用性，排除误报。

7.修复缺陷：开发人员修复确认的缺陷。

8.复扫验证：重新扫描，确认缺陷关闭。

9.记录归档：更新缺陷跟踪表，归档报告。

4.5依赖检查操作步骤

1.收集依赖清单：找到所有依赖声明文件与锁文件。

2.执行检查：运行依赖检查工具，生成报告。

3.分析漏洞：按严重级别、依赖路径、修复版本分组。

4.分析许可证：识别许可证冲突与合规风险。

5.修复漏洞：升级、替换、隔离或接受风险。

6.验证修复：重新构建，执行回归测试，复扫确认。

7.记录归档：更新依赖清单与修复记录。

4.6密钥扫描操作步骤

1.确定扫描范围：当前代码、历史记录、配置文件、构建脚本。

2.执行扫描：运行密钥扫描工具，生成报告。

3.分析结果：确认哪些是真实密钥，哪些是占位符。

4.处理密钥：轮换、吊销、清理历史、加强监控。

5.建立规范：禁止硬编码，使用密钥管理服务。

6.集成门禁：将密钥扫描集成到预提交与CI/CD。

7.验证监控：复扫确认无真实密钥，建立持续监控。

4.7开发阶段安全检查清单

检查项检查内容标准结果

安全编码是否遵循规范全部遵循通过/不通过

代码审计是否执行覆盖全部业务代码通过/不通过

依赖检查是否执行覆盖全部依赖通过/不通过

密钥扫描是否执行覆盖当前与历史通过/不通过

代码评审是否执行覆盖安全相关代码通过/不通过

预提交检查是否配置密钥扫描生效通过/不通过

合并请求检查是否配置静态扫描与依赖检查生效通过/不通过

高危修复是否修复高危清零通过/不通过

安全组件是否使用使用安全库与API通过/不通过

安全注释是否添加安全相关代码有注释通过/不通过

4.8开发阶段完整案例

背景：示例公司用户管理功能进入开发阶段，开发团队5人，使用Java与SpringBoot，代码仓库包含业务代码与配置

文件。

操作步骤：

1.开发团队学习安全编码规范，重点包括输入校验、SQL参数化、密码哈希、加密、日志脱敏。

2.配置预提交钩子，提交前执行密钥扫描，检测到疑似密钥阻断提交。

3.开发人员编写代码，使用参数化查询、AES-256-GCM加密、Argon2密码哈希。

4.合并请求触发静态扫描与依赖检查，发现高危缺陷2个：SQL注入、跨站脚本。

5.安全工程师复核确认，开发人员修复：SQL改为参数化查询，输出改为转义。

6.依赖检查发现间接依赖高危漏洞1个，升级直接依赖后解决。

7.密钥扫描发现测试配置文件中有疑似密钥，确认为测试占位符，添加排除规则。

8.修复后复扫，高危清零，中危3个纳入修复计划。

9.代码评审通过，合并到主分支。

10.记录审计报告与修复记录，进入测试阶段。

结果：开发阶段发现并修复高危缺陷，避免漏洞进入测试与生产环境。

4.9开发阶段避坑指南

1.不要只依赖工具，人工复核同样重要。

2.不要忽略误报，误报会降低团队信任。

3.不要忽略间接依赖漏洞。

4.不要将密钥硬编码在代码或配置中。

5.不要忽略历史记录中的密钥。

6.不要修复后不验证。

7.不要一次性修复所有问题，按风险排序。

8.不要忽略安全编码培训。

9.不要忽略预提交检查。

10.不要忽略代码评审中的安全问题。

5.阶段四：测试阶段安全检查点

5.1阶段目标

在测试阶段通过安全测试、漏洞扫描、渗透测试，验证安全功能与安全设计，发现运行时漏洞，确保上线前高危漏洞

清零。

5.2检查点清单

检查点编号检查项检查内容责任角色输出

T-01安全功能测试验证认证、授权、加密、审计功能测试工程师功能测试报告

T-02漏洞扫描扫描运行时漏洞安全工程师漏洞扫描报告

T-03渗透测试模拟攻击验证安全性安全工程师渗透测试报告

T-04权限测试验证越权访问防护测试工程师权限测试报告

T-05输入校验测试验证注入、跨站脚本防护测试工程师输入测试报告

T-06加密验证验证敏感字段密文存储与传输加密安全工程师加密验证报告

T-07脱敏验证验证按角色脱敏测试工程师脱敏验证报告

T-08审计日志验证验证日志完整性与不可篡改安全工程师日志验证报告

T-09配置检查验证安全配置安全工程师配置检查报告

检查点编号检查项检查内容责任角色输出

T-10高危修复验证验证高危漏洞修复安全工程师修复验证报告

5.3安全测试类型

测试类型说明适用场景工具类别

安全功能测试验证安全功能是否按设计工作全部系统手工测试、自动化测试

漏洞扫描自动扫描运行时漏洞Web应用、接口DAST工具

渗透测试模拟攻击者验证安全性高风险系统手工测试

权限测试验证越权访问防护多角色系统手工测试、自动化

输入校验测试验证注入、跨站脚本防护有用户输入手工测试、扫描工具

加密验证验证加密是否生效敏感数据系统数据库检查、抓包

脱敏验证验证脱敏是否按规则展示敏感数据角色测试

审计日志验证验证日志完整性需审计系统日志检查

配置检查验证安全配置全部系统配置扫描工具

5.4安全测试用例模板

安全测试用例

用例编号：【编号】

测试类型：【类型】

测试目标：【目标】

前置条件：【条件】

测试步骤：

1.【步骤一】

2.【步骤二】

3.【步骤三】

预期结果：【结果】

实际结果：【结果】

测试结论：【通过/不通过】

测试人：【姓名】

测试日期：【日期】

5.5安全测试用例示例

用例编测试类

测试目标测试步骤预期结果

号型

SEC-权限测验证普通用户不能查看普通用户登录，尝试访问他人

返回无权限

001试他人信息资料接口

用例编测试类

测试目标测试步骤预期结果

号型

SEC-输入校返回正常结果，无数据

验证SQL注入防护在查询参数中输入注入语句

002验库错误

SEC-输入校

验证跨站脚本防护在昵称中输入脚本标签输出转义，脚本不执行

003验

SEC-加密验

验证敏感字段密文存储查询数据库用户表手机号字段显示密文

004证

SEC-脱敏验验证客服查看手机号脱

客服登录查看用户手机号显示前3后4

005证敏

SEC-审计日记录操作人、时间、内

验证操作日志记录执行敏感操作，查看审计日志

006志容

SEC-认证测

验证登录失败锁定连续输入错误密码账号锁定

007试

SEC-会话测

验证会话过期登录后等待超时会话失效，需重新登录

008试

5.6测试阶段安全检查清单

检查项检查内容标准结果

安全功能测试是否执行覆盖认证授权加密审计通过/不通过

漏洞扫描是否执行覆盖全部接口通过/不通过

渗透测试是否执行覆盖高风险功能通过/不通过

权限测试是否执行覆盖全部角色通过/不通过

输入校验测试是否执行覆盖全部输入点通过/不通过