文章总结： 本文介绍了信息安全体系中的安全交付流程，重点阐述应用上线前的安全实践活动。核心内容包括安全开场会议、安全需求确认、威胁建模、架构安全设计、静态代码扫描(SAST)、软件成分分析(SCA)、容器安全测试、动态应用安全测试(DAST)、隐私合规测试、安全功能测试、入侵测试及安全卡点等环节，旨在通过体系化风险甄别实现安全左移与持续监控，确保业务安全。 综合评分： 85 文章分类： 安全建设,应用安全

信息安全体系之安全交付流程

原创

我是刘庆华 我是刘庆华

安全道

2026年2月5日 21:34 上海

在小说阅读器读本章

去阅读

自从上一篇文章的发布已经过了一年多的时间，我确实不是一个高产的作者。这次想开篇正式开始写信息安全体系，写体系也不是贴ISO27系列或者NIST的内容，而是结合过往的工作经历给大家分享一下比较有效的落地实践。

进入正题，对于有着比较重的线上业务的公司，确保线上业务的安全性是一件极其重要的事情，不管ToC还是ToB的业务。那么如何能做到呢？这就要提到一个老生常谈的原则，那就是将安全风险尽早尽多尽全地发现并修复。

尽早：落地解读为安全左移和持续监控

尽多尽全：落地解读为体系性甄别各种类型的安全风险

用一张图来说明一下如何实现这三尽。

安全交付流程

2018-2019年我开始尝试画上面这张图，画过不同版本，这应该是第四次了。每次都有变化，融入了一些新的理解。

先快速解释一下这张图。

• 用交付流程中不同类型的安全实践在不同阶段甄别安全风险，做到应用上线发布前风险检测的三尽。
• 用线上环境里不同安全实践做到应用上线后风险检测的三尽。
• 图中内容并不求大求全，而是重点列出一些有代表性的安全实践活动并体现流程。
• 图中的安全实践在落地时会因为公司不同而表现为不同工具或者子流程的采用。
• 一些技术细节不在图上展开，未来在其它文章中再详细说，例如线上环境如何安全地和第三方或监管机构互联互通，云安全的配置等。

下面就按照从左到右，从上到下的顺序解释一下图中的每个元素。

本篇文章先讲图中大约三分之一的内容，以避免文章过长，本来大家的时间就比较碎片化，再加上文章内容对相当一部分人来说会有些枯燥，所以就放弃了这次写个长篇的想法。

1.安全开场会议

安全开场会议是一个重要的基础会议，通过这个会议，能让安全团队和项目团队快速同步以下信息：

• 应用的业务功能

  了解清楚了是什么业务才能知道如何更更好地保护业务，我自己也一直秉持安全团队需要深入了解业务的理念。

• 应用会处理哪些数据，数据的分类和最高分级。

  应用所处理数据的类型和级别也相当程度上决定了该应用的重要性，并决定了后续一些具体的安全管控要求。

• 应用的分级

  应用需要依据公司的标准进行定级，不同的级别所对应的安全防护要求 也会不同，很多公司会把应用分成四个级别，或者用颜色区分，或者用 字母数字区分。一旦级别定下来，所有团队需遵照统一规定进行防护。

• 需要完成哪些安全任务项

  基本了解项目信息后，安全团队就能明确下来有哪些任务项需要做，哪些不需要做。

  例如一个应用如果不处理外部个人顾客信息，也不大批量处理内部员工信息，那ToC的合规任务就不需要太多考虑了。反过来如果应用有大量ToC的外部用户，那么入侵测试就是必需的了。

• 应用上线前的安全要求

  安全团队需要清晰告知项目组团队哪些安全任务是必须完成的，以及发现的安全风险需要依据具体安全制度的要求全部处置后，应用才能上线发布。

2.安全需求确认

安全需求确认这个活动里，需要安全团队和相关方把需要实现的安全需求充分沟通，确保业务团队、开发团队、基础设施团队知道要做的安全工作和需要花费的时间，提前做到工作计划里，真正实现安全左移。

安全需求是个比较特殊的话题，简单地讲包含业务可见(例如应用要有认证、鉴权和权限角色管理功能，合规需求等)和业务不可见的(例如基础架构层通信传输的加密、数据静态存储加密)。

这些年信息安全除去喊了很多年的左移，还有个比较重要的原则就是透明化，也就是尽量做到对业务透明，对开发透明，对运维透明，这样才能做到各个职能团队能集中更多精力在安全之外的事情上。这就需要企业能清晰地将透明化和Security by Default列到安全策略里，能理解和做到不是件容易的事情。

3.威胁建模

威胁建模是一种方法学，从攻击者视角审视应用在实现业务逻辑时设计上的疏漏之处并穷举出来，以便能针对性地采取合适的解决方案。依据多年的观察，应用上线前最后的入侵测试发现的很多问题，都是可以在威胁建模中被发现的。

2014年开始接触威胁建模，到现在的2026年有12年了，这期间换过几次工作，发现能真正把威胁建模做到位的，根本没有，不管公司大还是小，有钱还是没钱。有些公司就没有这个安全实践，有些公司是简单走个形式。

很难落地这个安全活动的重要原因是对做威胁建模的人员要求太高，这不是简单能画图表现出数据流和边界等元素就够了，更重要的是需要既有攻击者视角又懂系统实现。

4.架构安全设计(部署架构）

架构安全设计，偏重于业务系统在部署时的网络架构设计，但不需要体现最详细的部署信息，例如不标出是几台虚拟机，也不需要给出IP地址等。

这个安全活动的目标是从安全视角检查网络层的安全控制是否能满足要求，很多时候威胁建模的理念在这个活动里也是适用的。架构安全设计常见的安全问题例如：通信不加密或者是使用弱加密协议/算法、ToB业务允许公网任意访问等等。

5.静态代码扫描(SAST)

这是个凡是做过应用安全的人都知道的安全活动，用扫描器检测静态代码里的安全问题。通常都是一些比较底层的安全问题，比如使用不安全API、硬编码、各种注入等。

6.软件成分分析(SCA)

SCA主要是对应用所依赖的第三方库或框架做安全检查，包括是否有已知的安全漏洞、是否有“有毒的”授权协议。这里的“有毒”主要是法律上的对公司不利，例如应用所用的依赖库有使用GPL v3授权协议的，那么如果你的软件会向你的客户分发，那么你有可能需要开源一些你的代码，感兴趣的可以仔细读一下。

7.容器安全测试

现今的技术栈，很多应用都是以镜像的形式部署在容器里来运行的，也就是CI/CD的流水线输出物是个容器镜像，把操作系统和应用打成了一个包。那么需要对流水线输出的镜像进行扫描，检查是否有安全风险。通常发现的安全风险会包含镜像操作系统的、软件依赖和一些配置问题。

8.动态应用安全测试(DAST)

这个测试是指应用在动态运行期间，通过扫描其http通信来发现安全风险。一般是嵌在人工或自动化的功能测试里来执行。通常可以发现注入、cookie的不安全使用、前端JS依赖风险等安全问题。还有更高级的安全测试–交互式应用安全测试(IAST),这里就不详细介绍了。

9.隐私合规测试

如果你的应用是ToC的，也就是给一般个人用户使用，尤其是移动应用，那么就需要满足合规的各项规定。

这个测试通常是混合型测试，人工+自动化。测试内容会包括隐私政策内容、数据收集最小化及必要性、数据传输及存储、用户授权、三方SDK和数据主体权利响应等。以上内容主要针对中国地区，其它国家地区会有各自地区性的合规要求，比如欧洲的GDPR。

10.安全功能测试

安全功能测试，偏重业务可见的安全功能，例如注册、登录、修改密码、权限管理等，可以是人工也可以是自动化测试。这个测试的过程中DAST也会并行进行，因为安全功能测试一样也会触发http通信。

11.入侵测试

这个测试相信大家都比较熟悉，入侵测试是从攻击者视角，借助一些工具(Nmap、Burp Suite、sqlmap等)发现应用在业务逻辑设计和实现上的安全疏漏。这个测试是应用上线发布前最后的安全活动。

很多公司会用这个测试作为保底的安全措施，前面的安全活动可能做得不多，但这个测试会明确要求。应用的安全主要依赖入侵测试的坏处也很明显：

(1).时间晚

已经临近上线了，发现问题的修复方案万一需要动设计架构就麻烦了，导致很多时候修复测试发现的问题会妥协而采用将就的办法来处理。

(2).入侵测试的供应商水平参差不齐

应用对外发布前安全风险未被发现或者是定级偏低而被忽略，我曾经遇到过案例，明明是高风险或者中风险问题，被外包的测试团队定级为低风险，开发团队看到都是低风险就没理会。也有公司自己组建入侵测试团队对公司的应用进行测试，确实能一定程度上提升测试质量，但说实话，基本都是要不到足够人手，测试请求排长队，无法及时覆盖全部应用。

12.安全卡点

安全卡点和安全开场会议对应，在应用上线发布前，确保所有必须做的安全活动都完成了，发现的安全风险需要依据具体安全制度的要求全部处置。

卡点的实现很多时候是个痛点，在大多数企业里都很难全部自动化实现，就会出现应用被故意或者非故意地绕开了安全确认而上线。比较实际的落地方式是自动化+流程，也就是一部分依赖程序和系统来卡，真正上线前还需要在人工流程里(比如上线前的最终评审会议)加入对安全工作的最终确认。

上面讲的这些内容其实并不是什么深奥的内容，但如果想从公司角度能形成群体的共同认可并遵照统一的规章制度执行，一定是一件很难的事情，不仅仅是技术和流程的问题，背后还有企业文化的问题，关于信息安全理念和企业文化的关(冲)系(突)是可以但开话题聊的。

这篇文章就先简单介绍一下上线前的安全内容，对于上线后以及总体的信息安全工作管理，会有后续文章来继续讲述。

2026年2月1日

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全道 我是刘庆华 我是刘庆华《信息安全体系之安全交付流程》