众所周知，系统安全并不只是一本写满了要求开发人员和运营人员需要遵循的各种规则与策略的小册子。系统安全也并不只是在项目进展到失去了方向时，网络安全小组用来确保开发和运营安全的工具。

通常情况下，公司的安全团队会通过各种会议来贯彻不同的规则和策略;并在发生安全泄漏事件之后，通过查询电子邮件或聊天记录，来获知企业当前安全态势，以追踪罪犯。这些都是典型的安全攻防方式。

可以说系统网络安全在我们的企业中无时不刻、无处不在地影响着每位员工。

让我们更有效

将公司的安全重任集中归责于某个单一团队是一种普遍的错误。其实每一个直接接触、或间接参与公司数据与系统的人员都承载着安全的责任。

在DevSecOps的落地过程中，我自己曾有过一些误解，也走过不少弯路。在此，我将通过本文和您分享：如何在避免出现错误方法的前提下，实现有效的DevSecOps。

执行规则和策略

虽然我们的确需要各种章程来指导自己的行动，但这绝非是靠单向地从作战室(war room)或咖啡间里发出指令来完成的。正如我们不应将整体安全重任归责于某个单一团队那样，我们需要通过软件定义和嵌入到DevOps管道(pipeline)中的模式来贯彻执行。

在执行规则和政策的过程中，我们有着许多可选的工具和方法。下面，我将向您展示如何通过有效地激发DevSecOps的能动性，来使企业收获实施的效果。

为了达到该目标，我们应采用以下的行动步骤:

• 定义目标
• 创建蓝图
• 开展宣传
• 具体执行
• 考量效果

在此，我假设您的公司已经达到了成熟的DevOps水平。

定义目标

为了知道自己将要达到什么样的效果，我们必须首先制定好目标和努力的方向，以避免出现“脚踩西瓜皮,滑到哪里算哪里”的情况。我们可以采用小组讨论、集思广益的形式，罗列出一个个“小目标”，以方便深入讨论。例如包括：

• 不暴露密码：保证不会泄漏任何密码、口令、证书链或私钥等。
• 无过期的证书：特别是要避免TLS证书的过期。
• 无过时或无效库：扫描各种项目依赖项、操作系统库、系统服务和实用程序。
• 无代码漏洞：静态扫描各种源代码，以发现其中的漏洞和bug。
• 遵守OWASP Top 10(开放式Web应用程序安全项目)：动态扫描各种运行中的应用，以查找潜在漏洞。

除了上述安全目标，我们还能以头脑风暴的形式快速列出更多的方便：消除未授权的进程、未授权的端口、未授权的存储库、未授权的帐户、有bug的软件库，实现生命周期管理、漏洞管理，遵守公共漏洞和暴露(Common Vulnerabilities and Exposures，CVE)规范，实现TLS全覆盖等。

创建蓝图

蓝图是我们定义如何让开发(development)与运营(Operations)在安全(security)的基础上协同工作的关键步骤。因为我们将定义一些开发和运营人员都值得关注的安全问题。在蓝图中，我们需要为整个公司定义各种规则，并准备好下一步执行的步骤。

下面的图表，是基于上面的目标定义所绘制出的一个蓝图范例：

如表所示，我用四个深色模块：密码管理、代码质量的静态应用程序安全测试(SAST)、安全加固、和运行质量的动态应用程序安全测试(DAST)，来对应我们的上述目标。与此同时，针对DevSecOps的实施计划，我们还需要将它们下方的各个具体要点，按照规则、执行、工具集的分类逐一映射到相应的目标之中。

至此，您可以在公司的内网开始创建一个共享空间，写上简明清晰的标题，注明在蓝图中所表述的每一个细节，并重点做到如下方面：

• 将蓝图与各个目标相连接
• 详细说明深色模块里的内容
• 如何对它们予以实施
• 会用到哪些工具集
• 强调安全的第一性
• 建立安全体系
• 列出例外之处
• 如何遵守相关法规
• 画出路线图

如上述流程图所示，我们必须尝试着将蓝图中的深色模块映射到自己的DevOps管道之中，以辅助我们去收集和考量在执行过程中的参数指标，并将它们作用到日常项目之中。

开展宣传

现在，我们需要设法在公司内部“营销”这些新的安全举措了。毕竟再好的蓝图，如果没人采纳的话，也将丝毫不会让企业受益。

由于公司中的每个人都会在DevSecOps中扮演着相应的角色，因此大家首先需要理解蓝图的重要性。我们不应当以一种“大爆炸”式的节奏去迅速推进，而应该让每一个人都参与进来，促进蓝图的逐步完成。因此，我们在宣传方面需要做到如下方面：

• 广开传播渠道，可以拉横幅、发布到内部网络、分发视频、以及用电子看板等方式展示路线图。
• 制作T恤、水瓶、粘纸、帽子等衍生小礼物。
• 招募愿意提前试用的“早鸟”。
• 举办研讨会，造势预热。
• 举行内部主题活动。
• 推送列举了诸多优点与好处的邮件。
• 提供与安全相关的场景演练。

可见，良好的方案往往源自良好的沟通和营销方式。如果没人真正参加进来，那么再好的蓝图也只能停留在纸面上。我们要确保每一个IT人员在开发软件、或提供和配置基础结构的时候，能够清楚地知晓何为正确、何为错误的。

具体执行

至此，企业中的每个人都应该知道自己在DevSecOps中所处的角色和作用了，那么我们来看看如何具体遵守规则，并执行各种策略。

如果在管道中，人工操作无法满足各种有关软件和基础设施的执行，那么我们就需要使用工具来自动化地实现上述定义好的各项目标与任务。下面我将为您列举与之相关的一套工具集。

注意：我在此不会去罗列那些专有的工具，因此您可以通过访问诸如

stackshare.io(http://stackshare.io/)的网站，来寻找它们的付费版本。

不暴露密码

此处所涉及到的密码包括：密码串、私钥、数据库帐户、或令牌。

为了不暴露密码，首先我们不能将密码简单地保存在未加密、或使用硬编码的文件，以及Git存储库中，当然也应该定期更换密码。因此我们自然而然地会想到必须使用一个中央存储工具来管理各种密码。

该存储工具必须能够管理密码的整个生命周期，并能在泄漏发生时减少自身漏洞的暴露。通过使用成熟的此类工具，我们还可以管理许多不同类型的信任凭据，如数据库、操作系统、云服务提供商等。同时，这些工具也能够让用户通过API，以编程方式来获取不同的密码。例如：

• 用HashiCorp Vault来管理密钥 - https://www.vaultproject.io/
• 用Gitrob扫描Git存储库以发现漏洞 - http://michenriksen.com/blog/gitrob-now-in-go/

如果您在管道中使用了SSH密钥，那么就可以直接从自动化运行程序(例如Jenkins)中调用它。

无过期的证书

如今在各种Web应用中TLS已成为了标配，那么我们就必须管理好证书的过期问题，以防止出现SSL的握手错误。

因此我们可以使用如下工具，来监控公司内部(私有域)和外部(公有域)中的每一种证书：

• 用Sensu来检查TTL证书 - https://sensu.io/
• 用HashiCorp Vault来管理私有域中的证书 - https://www.vaultproject.io/

注意：Sensu虽然没有开箱即用(out-of-the-box)的功能，但它有个很好的插件 - https://github.com/sensu-plugins/sensu-plugins-ssl。通过它，我们可以监控许多相关的方面。您可以通过https://sensu.io/features/core来了解更多信息。

无过时或无效库

大公司一般会并行开展数千的项目，那么当您的团队开始研发新的微服务时，他们很容易会使用到一些过时或无效的库。因此，我们需要尽量避免这种情况的发生。

注意：上述提到的是“开始研发新的......”，也就是说：我们对于生产环境中现有系统的执行应非常小心，不要仅仅为了跟风，而在现有环境中强制推行实施。我们需要在了解新策略可能带来的影响，然后通过团队合作，来避免产生混乱的局面。

可见，我们要选取适合手头项目平台和语言的特定工具。通过运用如下“必要”的工具，我们将能够及时地识别出，那些依赖项中存在的各种过时的、且带有bug的库：

• OWASP依赖项检查：适用于Java和.NET项目。 - https://www.owasp.org/index.php/OWASP_Dependency_Check
• RetireJS：适用于JavaScript项目。 - https://retirejs.github.io/retire.js/

我们必须在自己的管道中创建相应的步骤，以实现在每一次编译中都能被执行到的既定目标。同时，这也保证了我们不会轻易地放过任何一个未经授权的、过时的或带有bug的依赖项。

另外，如果面对的是服务器的集群，我们还可以使用Chef和Inspect之类的工具，来管理配置并维护系统的稳定性。这些工具能够在操作系统级别执行维护，当然它们也需要在各个主机上安装好代理程序。

无代码漏洞

SAST(静态应用程序安全测试)的目标是查出各种bug、错误的实践、潜在的内存泄漏、无限循环、以及任何程序上的漏洞。SonarQube(https://www.sonarqube.org/)是该领域的一个知名工具，它提供了多种方法来扫描各个源文件、查找bug和错误的实践方法，而且它能够被用在许多种编程语言的场景中。

• Infer by Facebook：这是Facebook提供的一种工具，我们可以用来扫描Java、C/C++和Object-C。 - http://fbinfer.com/

遵守 OWASP Top 10

OWASP Top 10是业界常用的十大安全风险的集合，它的最新版本已于2017年被更新(您可以通过该链接查看到全部：https://www.owasp.org/index.php/Top_10-2017_Top_10)。我们可通过遵循该准则，来提供更好的Web安全应用。如今网上已有许多工具能在遵循该准则的基础上，实施自己的检查策略。在此，我仅列出如下两种常用工具供您参考：

• OWASP ZAP：源自OWASP的渗透测试和漏洞挖掘工具。 - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
• IronWASP：一款开源的Web应用渗透测试与漏洞扫描工具。 - https://ironwasp.org/

考量效果

通过考量效果，我们能够获知上述各项DevSecOps策略的执行情况，从而避免整个公司长期处于“黑暗球场”的状态。

同样，网上也有许多十分优秀的开源工具，可被用来考量各项指标，并通过界面予以显示。我个人非常喜欢使用Grafana(https://grafana.com/)，它既能清晰地呈现各种监测到的指标，又能将它们进行存储。另外，我也建议您使用

InfluxDB(https://www.influxdata.com/)。它可以被集成到我们的管道中，从而获取精确的考量参数值。当然Grafana与InfluxDB之间也有着很好地相互集成。

那么我们具体能够考量哪些指标呢?一般包括如下：

• 在Git存储库中发现的密码值
• 各种过期的证书
• 续订过期证书的平均时间
• 过时无效的依赖项
• 过时无效的操作系统库
• 在源代码中所找到的各种严重漏洞
• 在应用程序中发现的前十大漏洞

上述便是我对于实现有效DevSecOps的一些可行性的建议。现如今DevSecOps的概念已经被炒作得有些过热了，因此，我强烈建议大家：与其坐而言，不如起而行。

原文标题：Effective DevSecOps，作者：Fabio Jose Moraes