是时候构建安全服务平台了

安全开发生命周期能够确保应用程序具备充足的安全性，而自动化是推行它的一个重要手段。不少企业的安全团队已经在这方面进行了很多努力，但也面临着新的挑战。比如重复建设、实施质量良莠不齐、信息分散、没有形成闭环等等。安全服务平台是这个困境的破局者。

1. 自动化是解决S-SDLC落地难的重要途径之一，但这件事本身也存在挑战

为提高软件的安全性，在企业中实施安全软件开发生命周期（下文简称S-SDLC)是必然的选择。自动化为企业推动S-SDLC提供了有力支持，可以很大程度上降低S-SDLC中各项安全活动的实施难度，从而使得开发团队愿意主动的落地执行这些安全活动。典型的例子就是自动化源码安全扫描。

不少企业已经在自动化这条路上做出了很多努力，效果当然是有的，但是自动化仅仅只是起步，还有更多挑战等着企业来解决，比如下面这些：

• 各个团队使用的安全工具的版本、扫描规则不一致，以至于同一种安全活动的产出物质量参差不齐。
• 运行频率没保障。有可能是临到审计前赶紧运行一下。
• 覆盖面不全。有些团队用的自动化安全工具多，有些团队可能一个都没用。
• 升级维护难。由于是开发团队自行使用自动化安全工具，因此要对其进行升级、维护，也只能由开发团队来实施，如此一来，什么时候能完成升级、维护，在很大程度上就取决于开发团队的配合程度了。
• 重复建设，用完就扔。每当启动一个项目，或者开始构建一个新应用，就得把那些安全工具重新配置一遍。项目结束开发后，这些工具也就被废弃了。虽说是一次配置多次使用，而且一个团队每次花在配置上的时间也不算多，但站在公司的角度来看，可能每天都有不同的开发团队在做着差不多相同的事情，重复建设的问题会更加明显。
• 信息分散。开发团队通常会使用好几个不同的工具，而这些工具所产出的结果就会比较分散，不利于开发团队、安全团队整体把握应用的安全现状。
• 安全活动没有形成闭环。自动化的工具倒是有了，但工具所产出的结果往往就那么静悄悄的躺在某个角落里，少有人问津，只有在面临安全审计、安全检查的时候才会被翻出来交差。

久而久之，自动化所带来的红利也逐渐被这些挑战所吞噬，甚至对于使用自动化来解决S-SDLC落地难的信心也开始了动摇。

2. 破局者：安全服务平台

什么是安全服务平台？我们先不急着看它的定义，我们先来看看下面几个场景，感性的认识一下安全服务平台。

场景1

开发团队在公司统一搭建的持续交付流水线里新建了一个项目，随后惊喜的发现流水线里默认已经有了好几个安全环节，无需开发团队再做任何额外的搭建和集成工作：

• 自动化源码安全扫描会在每次检测到有新代码提交时自动触发，更关键的是，扫描结果能在持续交付流水线里直接看到，并且可以对报告的问题直接进行标注处理
• 第三方组件安全扫描，和源码安全扫描类似，只是运行频率是每天晚上定时执行，并且在发现问题时提示开发团队
• 持续交付流水线中，部署应用程序到测试环境这个步骤中，默认加入了黑盒安全扫描。每当部署一个新版本到测试环境，扫描就会进行一次，发现的问题不仅能在持续交付流水线里看到，还能一键创建工单，方便的对问题进行追踪

场景2

分析业务需求中有哪些安全风险，这项活动对业务分析师而言挑战太大，但他/她发现用JIRA管理起来的用户故事卡里，有一部分故事卡中自动出现了一些安全风险提示。这是安全服务平台基于用户故事卡中的业务和技术上下文自动推断出来的，提醒开发团队对安全进行必要的考虑。

场景3

某天，开发团队的项目经理和安全团队同时收到了一条短信，提示说检测到了源码及密钥泄露。这是安全服务平台自动发送的报警提醒，原因是安全服务平台检测到了开发团队中的某位同事的个人Github账号下的公开代码仓库里，发现了公司的源代码，还有一些内部服务器的账号和密码。

场景4

有一个类似于数据驾驶舱的Web页面近实时的呈现了当前整个企业中所有开发团队已经开展了的安全活动。查看这个页面的是安全团队，他们能从这些可视化后的数字表盘里，轻松的掌控各个开发团队S-SDLC的实施情况。

与此同时，当前整个企业范围内有哪些开发团队“编码出来的”安全漏洞、危害级别如何、是否得到修复等等信息也是一目了然。应用安全风险是在趋于收敛还是滑向失控的边缘，安全团队也能得到更好的了解。

安全服务平台的定义

虽然还有更多安全服务平台的使用场景，但这不妨碍我们给出关于安全服务平台的定义了。安全服务平台，核心是对多种安全工具、服务进行统一封装，并通过API或UI交互，以及融入交付基础设施等途径，向开发团队提供便捷易用的安全服务集合。这些通过安全服务平台而提供出来的安全服务集合，贯穿了软件开发的完整生命周期，从需求分析和技术设计，一直到上线运营及运维。与此同时，安全服务平台也服务于安全团队，向其提供一系列安全管理服务。

3. 为什么需要安全服务平台

之所以说安全服务平台是目前推行S-SDLC的困境的破局者，是因为它所创造出来的独特的价值：

（1）提供开箱即用的安全服务，在把使用门槛降至最低。

经常听到有安全团队抱怨说，开发团队并不是真正的重视安全，不然为何那些明明对开发团队有好处的安全活动，到最后他们都不做呢？还有的安全团队使劲猛推S-SDLC，结果推得开发团队绕着安全团队走，唯避之而不急。

其实并不是开发团队对安全漠不关心，也不是他们有意躲着安全团队，他们的内心其实也是希望看到自己开发出来的应用程序的安全性足够高，只是开发团队有一个隐藏的要求：不管做什么安全活动，以及怎么做这些安全活动，实施成本必须足够低，低到开发团队认为这不会影响交付速度，不会导致lead time的增加。

把安全活动自动化是一个很好的开始，但这不是终点，开发团队的需求并没有得到很好的满足。尽管一些安全活动（例如自动化源码安全扫描）已经高度自动化了，但是在开发团队还是免不了要做一些搭建或者配置工作。这一点点看似微不足道的时间消耗或者精力投入，就犹如软件发布最后1公里这个问题一样，阻碍了安全活动最终的落地实施。

安全服务平台秉承了自动化的理念，并且把其发挥到了极致，通过技术手段直接帮开发团队搭建、配置好安全工具，如此一来造就了开箱即用的服务，对开发团队而言使用成本直接降到了0，使用这个安全服务的意愿和动力一下就充足了起来。还是以自动化源码安全扫描为例，当开发团队新建一条流水线的时候，默认直接就有安全源码扫描环节，无需配置，直接运行查看结果即可。

（2）减少甚至避免了重复建设

一个开发团队搭建一套安全扫描系统，N个开发团队就会搭建N套安全扫描系统，尽管可以通过自动化脚本来加速这个过程，但从资源的使用角度来看，始终存在重复建设的问题。

安全服务平台对安全工具进行了封装，统一对开发团队提供服务，这使得开发团队无需再自己搭建一套安全扫描系统，避免了系统的重复建设。

（3）是安全信息集散中心，且形成信息闭环

安全服务平台提供了多种安全服务，并且把这些服务的运行结果统一汇集起来，让开发团队能够更加方便的在一个地方查阅到自己所构建的应用程序的安全性。

更进一步，安全服务平台还能把各项安全服务的运行结果反馈回持续交付流水线，这使得开发团队能够在第一时间知晓安全活动的结果，并及时的做出处理。这样的做法能够帮助开发团队形成安全信息闭环，构建出一个正向良性的反馈环路。
####（4）提供多维度的信息可视化，便于安全团队追踪管理、推动S-SDLC中各项活动的开展

尽管S-SDLC提倡赋能开发团队，让开发团队以自驱动的方式去开展各项安全活动，但这些安全活动到底有没有开展？开展的效果怎么样？有没有遇到什么困难或者异常情况？这些信息在以前只能靠安全审计，或者安全团队主动去追问才能得知，而且得到的答案可能也比较模糊。

而安全服务平台由于记录下了各个开发团队、各项安全活动的详细运行数据，通过可视化等手段能够向安全团队提供更加精准的数据反馈，使得安全团队能够获得数据支撑，以便于持续改进优化S-SDLC的推行计划。

（5） 集中管理，易于维护

安全服务平台统一封装了各种安全工具或者第三方安全服务，因此对这些工具或服务做维护也变得更加容易操作。比如，某个安全工具需要进行版本升级，原先只能以发送通知的方式告诉开发团队尽快完成升级，但开发团队是否及时响应就不能很好的控制了，而且如果某些开发团队并没有使用这款安全工具，那么这样的通知对他们而言也是信息噪音。现如今，只需安全团队将安全服务平台所封装的这个工具进行升级，那么所有通过平台使用这款工具的开发团队无需做任何操作，便能直接享受升级后的功能。同理，对于安全扫描规则的更新也是类似的过程，将变得更加易于维护。

当我们了解了安全服务平台的这些独特价值之后，让我们再回过头来看看之前提到的那些新冒出来的挑战，你会发现通过安全服务平台都能得到比较好的解决：

• 安全服务平台提供统一的工具版本和扫描规则，安全活动的质量更有保障，同时也使得对工具和规则的升级维护变得更加容易
• 类似于自动化源码安全扫描的安全活动的运行频率，尽管可以由开发团队进行自定义，但也可以由安全服务平台设置最低可接受频率，因此相关安全活动的执行频率也能得到保障
• 安全服务平台所提供的部分安全服务直接集成到了持续交付流水线，变成了默认就有的环节，这使得更多的开发团队能够轻松便捷的把S-SDLC中的安全实践做起来
• 安全服务平台提供开箱即可用的安全服务，此举将开发团队所需要做的工具类建设活动的成本降至最低。与此同时，对于不同的开发团队而言，他们是对安全服务平台所提供的安全服务进行分时复用，因此重复建设的问题也不复存在
• 安全服务平台将众多安全工具和服务汇集在一起，同时也就把各项安全活动的产出物也都集中到了一起。这既有助于开发团队更全面的了解自己正在构建的应用程序的安全状况，又便于安全团队把握整个企业范围内的众多应用程序的安全状况
• 通过安全服务平台提供了两个信息闭环：（1）通过平台开展的安全活动，相关产出物（典型的如发现的安全漏洞）会通过持续交付流水线、邮件短信等方式及时反馈回开发团队，促进安全问题的修复；（2）安全团队推荐或要求开发团队执行的安全活动，到底有没有被执行，执行的情况怎么样，在没有安全服务平台时，只能通过内部安全审计、安全检查，甚至动用安全团队成员的私人关系来了解。而一旦安全活动通过平台开展，必然会在平台上留下各种数据，那么借助数据可视化等手段，安全团队就可以方便的获取到以及追踪安全活动的开展情况，并基于此不断推动安全活动落地执行，提高活动实施效果。

4. 小结

S-SDLC，也即安全开发生命周期能够确保应用程序具备充足的安全性，而自动化是推行S-SDLC的一个重要手段。不少企业的安全团队已经在这方面进行了很多努力，但也面临着新的挑战。比如重复建设、实施质量良莠不齐、信息分散、没有形成闭环等等。

安全服务平台是这个困境的破局者，它封装了一系列安全工具和第三方安全服务，并通过多种方式统一的向开发团队提供便捷的安全服务，使得开发团队更有意愿落地实施S-SDLC中的安全活动。并且安全服务平台还为安全团队的管理提供了支持。

既然安全服务平台如此优秀，那么该如何构建这样的平台呢？有没有什么核心原则需要考虑？有没有什么前提条件？它似乎有多种服务提供形式，那到底有哪几种呢？除了S-SDLC相关的安全服务外，平台还可融入其他安全功能吗？这些问题我们留着下篇文章为大家详细解答。

文/ThoughtWorks马伟