原文自博客发布平台medium，作者为 Viktor Petersson，传送门
文外话：不了解 DevSecOps 的同学首先看下什么是 DevSecOps
安全是一个复杂的话题。在设计安全策略时，需要考虑到的攻击媒介和威胁模型不计其数。
在过去的一年中，我们已经和无数个不同规模的公司讨论关于他们实施的安全策略和实施方案。基于这些讨论，我们提出了一种称为 DevSecOps 冰山的概念。这背后的想法是，许多组织倾向于将重点放在应用层上，而忽略了其他的层面。现在让我们来探究这些层面的含义以及如何保护它们。
但是请注意，这篇文章只是简述正常层上的概念，并不是全面的一份检查清单。
应用层
让我们先从应用层开始讲起，因为这应该是开发人员最熟悉的一层了。应用安全本身是一个广泛的领域，但是出于篇章的考虑，我们只将范围限制在易受攻击的层面上。
可以说，开源库对现代开发者来说非常重要，这已经是约定俗成的事实了。无论你从事的是前端开发还是后台开发，你绝大可能都会使用到大量的库来简化以及加快你的开发过程。举例来说，Snyk 的《2019年开源安全状况报告》提到，在2018年，从 npm 上下载的 js 包居然高达 3170 亿次。
由于在我们的源代码中需要更加依赖第三方的软件包，因此我们也面临着巨大的风险。例如，去年流行的 npm 包 “event-stream” 遭到了破坏，并且整个依赖流由于这个包的原因，都在一定程度上受到了污染。由于这个包的下载量达到了每周150万次，所以影响巨大。也由于我们越来越依赖于库，因此将来受到攻击的概率会增加。
那么，应该如何保护我们自己免受这些攻击的打击呢？正确来说，这很大程度上取决于我们的开发流程。如果你所在一家频繁发布应用（每日或者更多）并且使用持续继承（CI）和持续交付（CD）的全自动化发布公司，那么最好的解决方法是将依赖检查作为发布管道的一部分。如果当中检测到 CVE，运行的 CI 将会终止。
如果发布的频率较低，那么就使用那些服务能够让你将依赖提交到审核当中，并且会提醒你会有更好的选择。
容器层
应该 Snyk 在提高开发者对依赖漏洞的认识上做得非常出色，但这只是开发者在初期需要注意的地方。这也是为什么我在插图中将下一层放置在表面之下。尽管容器层也是相当重要，但它经常被忽视。
有很多开发人员将容器化视为解决问题，包括安全，的万能药。但事实并非如此，这看似简单其实内部的安全问题不容忽视。例如，在2018年，docker 就已经从 docker hub 中撤下了17个受损的镜像了。
如果你需要构建自己的镜像，你必须遵循当中的最佳实践方案。为此 Aqua 的 Docker Security Best Practices 就为我们提供了很好的指导。然而，这不能止于此。你还需要将漏洞检查放置到构建管道当中。像 Aqua 的 MicroScanner 工具就可以帮助你搭建这个流程，并且在镜像中捕获那些已受到攻击的软件包。
操作系统层
最后但也同样重要的是，并且我们在最近可能是最容易被忽视的：操作系统层。随着开发人员的注意力逐渐提升到抽象层，许多企业遗忘了修补它们自己的服务器。是的，它可能不像最新的 js 框架那么吸引人，但是监控操作系统的安全状况依然是维护的重中之重。
还记得 Heartleed、Spectre 和 Meltdown 吗？所有这些攻击都会直接影响到操作系统。尽管容器在某种程度上可以缓解部分问题，但实际上操作系统还是需要被定时修复。
尽管操作系统未完全整合到 CI/CD 流程中，但持续监控服务器状态还是非常重要。这包括但不限于以下几点
- 服务配置（例如 openSSH）
- 服务器加固（例如操作系统本身）
- 针对已知漏洞扫描所有已安装包（例如 CVE 扫描）
为了应对管道问题，我们的 WoTT 已经通过 GitHub 集成来处理了。
我们希望本文能够给你提供一个良好的视角来概述不同层面的安全基础。如开头的导论所说，这绝对不是全面的安全指南而只能充其量为概述。结论是，我们每个人都需要在每个层中使用至少一样工具来改善它们的安全状况，而不是仅仅停留在冰山一角。