usn安全体系架构 安全系统架构

作者：随亦

前述

经过我和我的团队一年的不懈努力，基本完成了公司信息安全体系的初步建设，我设计的安全体系架构分为六大块：安全开发体系、安全防御体系、数据安全体系、隐私合规体系、资产管理体系、安全管理体系，六大体系共同构成了完整的信息安全体系。

完整的信息安全体系架构图：

我设计的企业安全体系架构

六大体系建设总结：

企业安全开发体系建设总结企业安全防御体系建设总结企业数据安全体系建设总结企业隐私合规体系建设总结企业资产管理体系建设总结企业安全管理体系建设总结

一、安全开发体系介绍

这里的安全开发体系即指安全开发生命周期（SDL）或通常意义上的应用安全，它是一个帮助开发人员构建更安全的软件、解决安全合规要求的同时降低开发成本的过程。 安全开发生命周期是侧重于软件开发过程的安全保证，旨在开发出安全的软件应用。

在实践中，我将安全开发体系分为安全评审和方案设计、安全编码、自动风险识别、人工渗透测试、工程化管理SDL等五个方面，出于可落地和可执行的考量，与网络中常见的微软标准安全开发生命周期流程略有区别，其中标准SDL中的安全培训我将其放在了安全管理体系中，作为安全技术培训的一部分，安全应急我其放在了安全防御体系中，作为基础安全防护能力的一部分，就不在这里单列了！

二、安全评审

常规情况下，一个成熟的互联网公司在产品设计人员提出产品设计需求后，肯定是要走需求文案先期同步、需求评审、技术评审……等等一系列评审过后才会正式进入开发阶段的，如果没有这样一个流程，产品线将会很乱，非常不利于公司产品快速迭代更新。

那么，安全所做的第一步，就是编写项目安全评审checklist，为什么要编写这玩楞呢？因为不同的安全人员的水平不同，同一个需求，小白觉得这个需求设计的没啥问题，但大神就能一眼看穿其中存在的缺陷。因此，需要一个统一的标准来进行需求安全评审就很有必要，那么这个checklist就有价值了。

安全所要做的第二步，就是对接产品部，详细了解公司的产品流程是怎样的。比如下面这些内容：

需求从何而来？是客服从用户反馈中收集的，还是公司内部反馈的，是看其他公司做了我们也想搞一个的，或者是各方都收集的。

需求文案写好后是如何同步的？是按流程同步给相关人员，还是没有流程直接私发给相关人员，还是拉群同步给群友，或者是有一个需求文案池自己阅读。

后续的流程是怎样的？是先进行需求评审，还是直接进行技术评审，或者是直接进行开发。

安全所做的第三步，就是安全接入这一流程，不管这个流程是什么样子，产品人员写完的需求文案最终是要流入开发人员手中的，安全只需要在产品需求文案流入开发人员手中之前，对此执行完安全审计就可以了。

在实践中，接入后流程后每一个产品需求文案都将同步给安全人员，接到产品需求文案后，安全人员应认真阅读产品需求文案，并判定是否需要参加现场需求评审。

对于没有安全评审价值的需求，直接放过就可以了，比如它只是改了一个页面的颜色，或删除了某些没有用户使用功能等。

对于逻辑模糊不清或从文案中看不出所以然的需求文案，安全人员应参加现场需求评审或与产品设计者详细了解其中逻辑，判断其中是否存在安全设计风险。

对于需求设计中存在安全缺陷的，应及时与产品人员沟通并修改产品需求文案或做特殊说明，避免产品开发带入因设计不规范造成的安全缺陷，在产品开发完成后再修改这些缺陷，成本就很高昂了。

安全所做的第四步，对产品设计人员所有提过的需求做评审记录，记录内容可以包括评审日期、需求评审点、评审结果、后续跟进等内容，也可以添加其他内容进去。做记录一方面是是为了存档，便于以后复盘、追责或审计的时候用到；另一方面，需求评审作为安全工作的一部分，汇报工作可以让领导看到你确实是在做了，不然空口无凭嘛。

三、安全方案设计

在实践中，方案设计这项工作并不是任何时候都有的一项内容，它一般出现在产品设计人员或开发人员对一个安全相关的需求不了解，需要安全人员来设计详细的实施方案时才存在。比如一个密钥要安全的存储在客户端中，产品设计人员可能对此技术并不了解，开发人员也对此技术不了解，那么这时候，就需要安全人员来撰写相关的需求文案了。

同样的，由于不同的安全人员的水平不同，同一个安全需求设计出来的安全方案的实现逻辑也不同，但我们至少要保证安全方案它自身是安全的，对一个安全设计需求，小白设计出来后可能其安全方案本身又存在安全缺陷，这就类似于安全产品存在安全漏洞一样，属于比较尴尬的事情。

那如何让一个安全方案它本身是安全的，这就需要一个统一的设计规范，按照这个统一设计规范，保证不同级别的安全人员设计出的安全方案它本身是安全的。因此，安全需要先撰写一个安全方案设计规范，而在此之后的安全方案设计，都应参考这个规范，以避免将安全缺陷设计进去。当然了，假如团队内有大神，直接让大神review一下也是可以的。

四、安全编码

这里安全编码旨在让开发写出更安全的代码，我们知道，开发人员编写代码这一步位于大多数技术漏洞的源头，安全意识薄弱的开发人员会让一个产品产生很多安全漏洞，比如不对参数做校验导致0元可买任何商品、分期付款可以无分期时间上限这种低级别缺陷。提高开发人员的安全编码意识，即可对技术漏洞的源头达到一定的治理效果，虽然实际中并不能完全根治。

在实践中，安全所做的第一步，就是撰写安全编码规范，常见的一般就三类：web安全编码规范、APP安全编码规范、密码学安全编码规范（太重要了，把编码当成加密的、使用弱加密算法的、不加盐的等等）。具体文案撰写时可以参考业内知名的安全编码规范，也可以自己撰写。如果参考业内其他安全编码规范，一定要做适配性修改，使得其内容符合公司的开发架构，不然开发人员阅读起来会被疯狂吐槽。

安全所做的第二步，就是推动开发人员阅读了，这一步实现起来比较困难，首先要得到技术总监的支持，一般领导们对与这种能降低产品风险的事情是不会排斥的，但是一线开发人员就比较排斥了。比较荣幸的是我司的安全部是独立出来的，拥有较高的话语权，所以相对比较容易。

安全要做的第三步，就是对开发人员进行安全编码意识考试，同样的，要落地这一步仍然需要先得到技术总监的支持。其次对于考试试题，建议以单选题为主，同时题量不能太多，不然大家都遭不住。对于考试的频率，可以全部开发人员一年考一次，每个季度单独再对新入职的开发人员进行考试就可以了。对于考试的方式，怎么实现都可以，例如我司有人力资源部的考试平台，可以开展任何考试。

以上均是我实践中的方式，仅作为参考。这样的考试虽然频率不算高，试题难度也不大，试题量也不多，遭受的阻力也小，但对开发人员的安全编码意识提升却有非常大的效果。在实践中，低级别弱智漏洞能几乎绝迹。

安全要做的第四步，为了帮助开发人员在编码过程中不靠主观意识就能发现和避免一些安全缺陷，我们让所有开发人员都安装了陌陌开源的IDE开发辅助插件（immomo），该插件可在开发过程中就能识别到一些代码中的安全漏洞，使得开发人员能在编码过程中就避免将漏洞写入产品中。

五、自动风险识别

出于工作效率的考虑，对于安全缺陷首先选择的就是自动化方式识别，先解决自动化识别出的安全缺陷。对于自动化风险识别的方式，我在实践中主要使用威胁建模、代码审计、安全漏洞扫描、其他安全扫描、IAST自动化安全测试等，接下来逐一进行阐述。

5.1、威胁建模

理想情况下，威胁建模是架构师的事情，在一个项目进展到架构师进行架构设计时，架构师通过威胁建模来分析当前设计中存在的潜在安全缺陷，之后通过修改架构或执行其他处理措施，从而降低架构设计层的安全隐患。

但在实践中，往往存在架构师没有精力执行威胁建模、或架构师不懂威胁建模、或公司没有架构师的情况。导致威胁建模这个行为并没有用在刀刃上，没有将其价值最大化。

即便如此，威胁建模对于安全人员来说仍然存在一些价值，威胁建模一般是使用STRIDE方法来进行，即（绘制数据流图----分析威胁----评估风险----制定补救措施----落实补救措施）。总的来说，进行威胁建模可以分为以下几步：

第一步，详细了解公司当前的设计架构，可以通过和开发负责人面谈，或阅读相关设计文档，或公司有架构师的话直接聊架构师，从而获得公司架构的详细架构图谱。获得到的架构图谱不一定是一张图，大概率是很多张图，因为很多模块其实是相对独立的。

第二步，将获得到的架构图谱绘制到威胁建模工具中，如微软的Microsoft-Threat-Modeling-Tool（使用教程参考：Microsoft-Threat-Modeling-Tool威胁建模工具介绍），它就可以自动帮我们分析出其中的潜在风险了。一般初次威胁建模范围很大，因为要覆盖到公司所有资产，耗时也比较久，但在此之后，只需要对新增的业务进行威胁建模就可以了。

第三步，对威胁建模工具自动分析出的潜在风险进行人工确认，这里的确认方式包括安全测试、逻辑推理等等。在实践中，这一步常常都能给我们带来惊喜，它可以cover一些我们平常不会注意到的风险点，在安全漏洞的产出上尽一点微薄之力。

第四步，对于第三步确认的风险，可以将其作为安全缺陷提出来，然后推动其修复就可以了。

实际上，我们这里只是将威胁建模用成一个漏洞发现的工具了，属于事后威胁建模，并不符合事前威胁建模的思想。这样做有两个问题，第一个是不能cover架构层的设计缺陷，同时产品一旦开发完成，架构层的安全问题基本就没法改了；第二个问题是隐蔽漏洞发现时间滞后，造成漏洞修复成本升高，即本来最初改改设计就能避免的问题，现在要大动干戈才能改掉。但即便如此，威胁建模对安全人员来说还是有一些价值的。

最后一步，即编写安全威胁建模规范，因为不同的人对同一个事情有不同的做法，不同的做法就会产生不同的结果，这将会导致同一个事情结果出现参差不齐的情况。因此，如果大家都按照安全威胁建模规范来做，就能很好的解决结果参差不齐的问题了。

5.2、代码审计

代码审计是一种重要的漏洞发现方式，同时这在任何公司都属于必不可少的工作，因为它能发现黑盒测试发现不了的漏洞，从而更全面的来把控应用安全。

黑盒测试不管是扫描器还是人工，都会因为种种原因遗漏掉各种各样的点，比如if-else多层嵌套，你可能只测试了if发现没问题，但在其中的某个else里面就能触发漏洞，因为你看不到背后的全量逻辑，所以也会测试不全。而白盒测试则能直接看到其中的逻辑，从而发现更深层次的问题。

在实践中，甲方公司几乎不存在纯人工审计一个项目代码的情况，纯人工审计一个项目代码太耗时了。自动化代码审计的核心是代码审计引擎，而它是一个比较考验安全人员开发能力的事情，因为不管是自研还是开源项目二次开发，都需要写代码。代码审计工具具体原理或细节我们就不再说了。

拥有代码审计引擎后，将其接入项目发布系统，在项目代码发布时执行白盒扫描。如果公司没有项目发布系统，可以接入代码仓库平台，监测代码提交行为，在接到代码提交时进行白盒扫描。白盒扫描完成后，人工对扫描结果进行二次确认，对于确实存在的安全缺陷再推动修复即可。

这里有一个问题，理想情况下代码审计是项目发布到测试环境时执行的，发现漏洞后及时修复，保证项目正式上线时不带着已知漏洞上线。但在实践中，即便是目前的商业代码审计产品误报率也高的惊人，更别说开源的或自己搞的那些了，再加上测试环境其实是随时都有可能发布的，一个项目不知道要在测试环境发布几十遍，因此人工复审确认这一环节就没法开展了。

因此在实践中，只能将其挂在预发布系统或线上系统，这样发布次数少，白盒扫描次数就少，人工复审确认能忙得过来，对于代码审计中发现的漏洞，只能之后再排期修复，一般能在下次发布时修复掉就很不错了。

5.3、安全漏洞扫描

安全黑盒扫描也是一种重要的漏洞发现方式，安全漏洞扫描一般能起到两个作用，第一是它可以发现一些人发现不到的问题；第二是用于模拟外部攻击，因为在实际中外部攻击除了定向攻击外，大多攻击者其实都是没有目标的拿扫描器一把梭，在扫描到某公司的系统有安全漏洞的时候，再对该系统进行人工渗透。因此，模拟外部攻击者用扫描器扫描系统来发现漏洞，是一件很有必要的工作。

安全漏洞扫描可以分为web安全漏洞扫描、主机安全漏洞扫描、APP安全漏洞扫描、Docker安全漏洞扫描、公网开放端口扫描、组件漏洞扫描。其中常见的扫描器如下：

web漏洞扫描器：AWVS、Appscan、Arachni
主机漏洞扫描：Nessus
APP安全漏洞扫描：MobSF
Docker漏洞扫描：Anchore
公网开放端口扫描：Nmap
组件漏洞扫描：BlackDuck

扫描的频率可以根据实际情况自定义，扫描完成后，进行人工确认，将确认的漏洞推动修复就可以了。同时，还应当对每一次扫描做记录，以保留工作成果。

5.4、其他安全扫描

在实践中，我将这里分为弱口令扫描和敏感信息泄露扫描。

弱口令扫描主要是使用弱口令字典，扫描公司的一些信息资产口令情况，比如内网各种系统、公司邮箱等等，对于使用弱口令的员工督促改正。弱口令字典除了常见弱口令外，还应包含系统默认密码，需要注意的是这里的默认密码在密码复杂度规则上可能不一定是弱口令，但只要是大家都统一的默认密码，就按弱口令处理。

敏感信息泄露扫描主要是扫描后端接口返回的用户敏感信息，包括手机号、身份证号、银行卡号、订单号等，这些信息一旦被外部黑客遍历获取，用户就会身处风险之中，非常容易遭受电信诈骗。

敏感信息泄露扫描一般分四步。第一步通过正则匹配的方式扫描后端接口返回的敏感信息，第二步确认返回的敏感信息是否是真实的敏感信息，比如有些匹配到的可能仅仅是11位的字符串并不是手机号。第三步，若接口返回的是真实的敏感信息，测试该接口是否存在遍历漏洞，存在漏洞的要及时修复。第四步，判断返回的敏感信息是否需要脱敏，若非业务必须明文展示则一律执行脱敏。

在实践中，敏感信息泄露扫描可以使用RASP来实现，开源的工具如百度的OpenRASP，将其部署到测试环境后，它就能监控测试人员在项目功能测试中所产生的流量，然后就能监测到哪些接口返回了敏感信息，之后对这些监测到的敏感信息进行处理即可。

5.5、IAST自动化安全测试

IAST自动化安全测试不同于黑盒漏洞扫描，它的功能非常强大，能够结合应用内部hook点信息精确的检测漏洞，几乎没有误报。传统黑盒扫描器依赖于页面响应检测漏洞，不但需要发送大量的请求，还有误报的可能。对于SSRF、文件上传等漏洞，在页面没有回显、主机没有外网权限的情况下，还可能会漏报。IAST自动化安全测试就能很好的解决上述问题。

在实践中，推荐的开源工具还是百度的OpenRASP-IAST，将其部署到测试环境后，它就能监控测试人员在项目功能测试中所产生的流量，并对产生的请求流量插入预定的Payload后发送，经过一系列逻辑验证，就能准确无误的判断漏洞了。

最后，由于开源的OpenRASP-IAST支持的插件很少，为了发现更多的安全漏洞，我们可以对其进行二次开发，二次开发主要是开发对应的漏洞扫描插件，而对于漏洞扫描插件以外的其他平台级逻辑，开源代码已经写的很好了，一般情况下没必要去动，除非自己有特殊需求。

结合上一步所论述的RASP扫描敏感信息泄露，它的部署可以参考：基于Springboot的Docker部署OpenRASP-IAST，它的二次开发可以参考：OpenRasp-IAST二次开发说明。

六、人工渗透测试

在处理完自动化发现的安全缺陷之后，剩下的就是无法靠自动化方式发现的安全漏洞了，这种漏洞需要安全人员手动去发现，即人工渗透测试。

渗透测试是整个信息安全的重要分支之一，不管是市场需求量还是从业人数都位居信息安全分支第一，因此有很多安全从业者专职从事渗透测试工作，渗透测试也是安全人员所具备的基本技能，但要做到大神级别难度比较大。

对于人工渗透测试，我在实践中主要分为测试准备、安全测试规范、漏洞定级、发布实时安全/合规测试、季度全网渗透测试、第三方渗透测试等几块，接下来逐一进行阐述。

6.1、测试准备

在进行安全测试前，我们需要进行一系列的准备工作，只有做好准备工作，安全渗透测试才能按期望开展，在实践中，我将准备工作分为了两块：公司所有项目梳理和测试账号收集规整。

公司所有项目梳理这个我会在资产管理体系一文中详细论述，此处就不再赘述了。梳理完信息资产后，我们就知道了我们有哪些域名、有哪些URL、有哪些IP、开放了哪些端口等等，在接下来的安全渗透过程中，这些资产就是我们要测试的目标，同时，完整的资产数据能让我们在安全渗透测试中有更高的效率，从而达到更好的效果。

当我们梳理完公司的资产后，会发现很多资产的访问有权限验证的，很多站点也需要账号口令登录……，并且很多站点没有注册窗口，这时如果有一个或多个账号是不是就很方便了呢？所以对所有资产的测试账号梳理规整就是一个很有必要的工作，梳理规整好资产的测试账号后，不论是自己实施安全渗透测试，抑或是新来的同学实施安全渗透测试，都是非常方便的。在实践中，梳理测试账号可以通过测试部门来进行，测试部门一定是有所有资产的测试账号的，否则他们无法实施测试，我们只需要将这些测试账号要过来就可以了。

6.2、安全测试规范

由于不同的安全人员水平不同，如果给到一个站点不做任何要求进行安全测试，水平高的安全人员会测试的更全面，发现更多的问题，水平低的安全人员就相反了，可能只是看到一个id想着遍历一下，看到一个查询想着注入一下，不会想到更多的安全关注点。

解决这个问题的办法是编写安全测试规范，形成一个安全测试checklist，所有拿到一个资产进行安全测试的人员，都按照这个checklist来逐项进行安全测试，就能基本上统一测试质量了。安全测试规范包括web安全测试规范、Android应用安全测试规范、iOS应用安全测试规范、技术合规测试规范。其中前三个大家很好理解，这里就不多说了，技术合规测试规范我单独阐述一下。

技术合规测试主要的测试内容是产品的合规性，即我们的产品是否符合法律法规规范。我们知道，合规的很多内容其实是技术来支撑的，比如收集哪些用户数据、这些数据是怎么传输的、是怎么加密的、权限索取是怎样的……等等，因此，它并不是一个单纯的非技术方向。编写完技术合规测试规范后，所有拿到一个资产进行安全测试的人员，都按照这个checklist来逐项进行技术合规测试，就能基本上统一测试质量了。

6.3、漏洞定级

在我们测试出一个漏洞后，这个漏洞是算高危呢还是算低危呢？这个问题在不同人看来有不同的答案，举个例子，安全圈最经典的XSS漏洞，安全人员觉得它是高危，开发人员说这不就弹了个窗吗？

因此，一个漏洞定级标准很重要，对于公司内部来说，你把低危漏洞主观定级成高危漏洞，开发人员不干了要和你扯皮，因为这影响他的绩效了。对于公司外部来说，你把高危漏洞主观定级成低危漏洞，SRC的大佬们不干了后果很严重。所以说漏洞定级一定不能主观随意定级。而撰写一个漏洞定级标准并将它公开，以后每个漏洞定级时都按这个标准进行，漏洞定级就有了信服力。

当然，一个漏洞不光是提出来就完事了，它还需要修复。不同的漏洞修复的时效也是不一样的，紧急漏洞需要马上修复，而低危漏洞可以拖延很久甚至不修复。建议将不同漏洞的修复时效也列入漏洞定级标准，从而在发现一个漏洞后，按照漏洞定级标准现进行定级，再按照漏洞修复时效标准进行修复排期。

在实践中，如果一开始就落地这一制度会非常困难。通常情况下，制度推行需要有一定的文化基础，当安全文化逐渐深入员工心时，不光是这个制度落地起来很容易，其他安全制度落地起来也很容易。因此，对安全管理者来说，培养公司的安全文化是一个长期且艰难的事情。在过去一年的时间里，我们也只完成了对公司部分部门的安全文化培养，如技术、法务、行政、人事、宣传、财务等几个安全常合作部门，这些部门的员工现在非常重视安全，在遇到风吹草动时都会第一时间寻找安全支持。而其他一些和安全不常合作的部门，就没有见过他们的身影。感觉这里扯跑题了……

6.4、发布实时安全/合规测试

在规范化的安全生命周期中，一个产品在初步完成编码后，是需要经过测试人员测试并测试通过之后才能正式上线的，此处的测试人员即包括安全测试人员。那么，每一个需求在提测的时候，安全都应该介入。

在实践中，一般情况下，一个需求从开发流向测试，一定是有一个规范化的流程的，可能是钉钉或企业微信的一个流程审批，也可能是一个工单系统的工单，但不管怎样，这个流程是存在的。安全的工作就是先找到这个流程，并让管理员将安全人员添加到这个流程中，安全就算接入了。在此之后的每一个需求提测都会自动同步给安全人员，安全人员与测试人员一道，共同对这个需求执行测试。在测试中，安全人员重点关注的就是安全漏洞与技术合规问题。

最后，在测试完成后，要撰写测试报告或测试记录，主要是为了留档，一来这是工作成果，证明这个需求自己测试过了，有产出。二来在日后出现问题追责的时候，是谁测试的需求谁就背锅，这样对背锅人或对大家都是公平的。

6.5、季度全网渗透测试

虽然上面的发布实时安全测试能让我们知道每一个发上线的需求都是经过安全评估的，但是那个只是对一个个的小需求点进行的，在一个个小需求点的之间关联处，我们可能会有遗漏。那么定期做一个全局的安全渗透测试就很有必要了。

在实践中，我们是一个季度执行一次全网资产的渗透测试，测试的目标就是梳理出来的所有信息资产，在每次渗透测试中，我们都能发现一些重要的安全漏洞，证明定期执行全网的安全渗透测试是正确的。

6.6、第三方渗透测试

一般情况下，如果公司自己有安全人员，是不需要第三方来进行渗透测试的，因为第三方安全人员的水平不一定比自己安全人员的水平高，尤其是国内，第三方派驻的安全人员很多都是初出茅庐的应届生。

那么，什么情况下需要第三方来进行渗透测试呢？主要有两个情景，第一个是公司自己没有安全人员，这种情况就不说了。另一个情景是公司需要拉客户、需要投标等等，而客户会进行信息安全审核，一般客户审核的主要方式就是要求提供第三方安全机构出具的渗透测试报告，因为你自己不能证明你自己安全，不管你多牛逼，就类似于让你证明你是你这样，存在逻辑悖论。在此种情况下，即使我们有安全人员，我们仍然需要第三方来进行渗透测试，甚至说第三方派驻的渗透人员水平越低越好。

七、工程化管理SDL

为什么要工程化？首先你经过日积月累的漏洞发现与挖掘，搞出了无数漏洞，那这些漏洞你怎么记录保存？哪些修复了？哪些开发说要修复但还没修复完？哪些开发拒绝修复了？……等等，如果这些工作单纯靠Excel来搞，在数据量稍微变大的时候，就会出现无法处理的问题。

这就是为什么要搞工程化管理SDL，搭建一个安全平台，这个安全平台可以有很多功能，可以把各种扫描器配置集成进去，我们例行扫描的时候打开这个平台就可以部署扫描了，也可以把代码审计结果展示集成进去，代码扫描引擎扫描完成后，我们人工确认审计时打开这个平台就可以了，也可以把防火墙配置集成进去、把知识库集成进去、把病毒扫描集成进去……。

当然，这些功能它都可以没有，我们可以使用各个独立系统平台，但它一定要有漏洞管理职能。拥有漏洞管理职能后，我们所有发现的安全漏洞都可以在平台上录入，然后每个漏洞标注对应的开发人员，每个漏洞都拥有不同的状态，如已接受、已修复、已拒绝、已验证、已关闭……等。在开发人员收到提醒后，就会去关注这个漏洞，并点击跟进漏洞状态。我们工程化SDL就实施起来了。这样就比使用Excel记录漏洞强十万八千倍了。

目前较好的开源的安全平台是宜信安全部出品的「洞察」：https://cesrc-creditease.github.io/。如果安全团队没有能力自己开发可以直接使用，如果有能力自己开发建议自己从头开发或二次开发！

八、总结

我以上所论述的安全开发体系（安全开发生命周期）其实和理论上的安全开发生命周期是略有出入的，整体上和理论方案也存在一些差距，但从论述中大家也会发现，只有基于实际的、适合自己的、能落地的方案，才是最好的方案。