将安全整合到DevOps中的10条建议

对DevOps的一种阐释是它源自提高开发人员生产力的需求，因为随着开发人员人数的增长，处理部署工作的运营人员出现人手不够的情况。

一般技术企业的开发、运维和信息安全工程师的比率是100:10:1。当信息安全人员跟其他工程师在数量上的悬殊如此大时，如果没有将自动化且没有将信息安全整合到开发和运营的日常工作中，那么信息安全人员只能做合规检测工作，但它跟安全工程的目标相反；另外，它还会招来人们的恨意。

开始行动

1. 将安全融入到开发迭代演示中

这里有一种简单方法能阻止信息安全人员成为项目行将结束时的拦路虎：在每个开发间隔结束时邀请信息安全人员参加产品演示活动。它有助于人人都理解跟组织机构目标有关联的团队目标、在构建过程中看到它们的实现、并且有机会提供所需输入以满足安全和合规目标，同时有足够的更正时间。

2. 确保安全工作包含于开发和运营的工作追踪系统中

信息安全工作应该跟其它工作一样可见于价值流。我们可在开发和运营人员日常使用的工作追踪系统中追踪信息安全工作，以此跟其它工作区分优先顺序。

3. 将信息安全整合到无可非议的事后剖析过程中

另外，在每次发生安全问题后做一个事后剖析以避免再次出错。在2012年举办的奥斯丁开发运维日(Austin DevOpsDays) 活动的演讲中，多年来在Etsy信息安全公司担任主管一职的NickGalbreth说明了他们对待安全问题的方式，“我们将所有的安全问题都放到所有工程师在日常工作中都会使用的JIRA工具中，这些问题要么是P1级别要么是P2级别，也就是说必须立即解决或者在本周末解决，即使只是个供内部使用的应用程序也不例外。”

4. 将预防性安全控制整合到共享源代码库和共享服务中

共享源代码库是激发人人发现并复用组织机构集体知识的良好途径，不仅对于代码而言是如此，对于工具链、部署流水线、标准以及安全来讲也是如此。安全信息应该包括保护应用程序和环境的任何机制或工具，如为实现具体目标而受安全保护的库。另外，将安全工具增加到开发和运营人员日常使用的版本控制系统中能让他们时时刻刻注意到安全需求。

5. 将安全整合到部署流水线中

为了让信息安全始终成为开发和运营头等考虑的事情，我们想继续快速反馈跟他们代码相关的潜在风险。将安全整合到流水线中涉及将尽可能多的安全测试自动化，这样它们就能跟其它自动测试一起运行。在理想情况下，开发或运营团队提交的每行代码都应该执行这些测试，即使在软件项目的最早阶段也是如此。

6. 保护部署流水线免受恶意代码影响

遗憾的是，恶意代码可被注入到支持CI/CD的基础设施中。隐藏恶意代码的一个好地方是单元测试，因为没有人会查看这些测试而且一旦有人将代码提交到库中，这些测试就会运行。我们能够（而且必须）通过以下步骤保护部署流水线，如：

• 强化持续构建和集成服务器，以便自动复现它们。  查看版本控制中引入的所有变化，阻止持续集成服务器运行不受控的代码。  测试库以检测测试代码何时包含可疑的API调用。

7. 保护应用程序的安全

开发测试通常关注的是功能的改正。然而，信息安全关注的通常是测试可能出错的地方。信息安全并不是手动执行测试，而是将它们生成自动化单元或功能测试的一部分，这样就能在部署流水线中持续运行。定义设计模式帮助开发人员写代码以阻止滥用也起着重要作用，比如为服务设置速率限制并在按下提交按钮后将其灰度化。

8. 保护软件供应链的安全

仅仅保护应用程序、环境、数据和流水线的安全并不够，我们还必须确保软件供应链的安全，尤其是在有让人惊讶的数据（见Sonatype发布的2015年《软件供应链状态》报告以及Verizon发布的2014年《数据泄露调查报告》）显示软件供应链易受攻击的情况下。虽然使用并依赖商业和开源组件很方便，但同时也极具风险。选择软件时，检测具有已知漏洞的组件或库并跟开发人员一起仔细选择具有快速修复追踪记录的组件十分重要。

9. 保护环境的安全

我们必须确保我们的环境处于一种经强化且降低风险的状态。这涉及生成自动化测试以确保所有的恰当设置都已正确应用于配置强化、数据库安全、密钥长度等。它还涉及通过测试扫描环境中存在的已知漏洞，并使用安全扫描器予以识别。

10. 将信息安全整合到生产测量中

通常，内部安全控制在快速检测安全事件中并不起作用，因为在监控中存在盲点或者没有人每天在检测相关的测量情况。为此要将安全测量整合到开发、QA和运营所使用的同样工具中。这样流水线上的每个人都能看到应用程序和环境是如何在存在威胁的环境中表现的。在这种威胁环境中，攻击者不断尝试利用漏洞、获取未经授权的访问权限、植入后门并实施欺诈行为（等等）。