首先出现了 “DevOps” 这个术语。
它有很多不同的方面。 对于某些人来说，DevOps 主要是一种重视协作、开放性和透明性的文化。 其他人则更关注关键实践和原则，例如自动化一切、不断迭代和大量检测。 尽管 DevOps 并非关于特定工具，但某些平台和工具使其成为更实际的命题。 考虑容器和相关的开源云原生技术，如 Kubernetes 和 CI/CD 管道工具，如 Jenkins，以及原生的 Linux 功能。
然而，最早围绕 DevOps 提出的概念之一就是打破开发人员和运营团队之间专门的“迷惑之墙”。 这源于这样一种观点，即开发人员不太关心运营问题，而运营人员不太关心应用程序开发。 加上开发人员希望快速行动，而运营人员更关心（并且往往以）稳定而非速度来衡量，因此很容易理解为什么很难让这两个群体达成共识。 因此，DevOps 开始象征着开发人员和运营人员更紧密地合作，甚至在某种程度上合并角色。
当然，改进沟通和更好集成工作流程的呼声从来不仅仅是关于开发和运营。 业务负责人也应该参与对话。 还有软件的实际用户。 实际上，您可以列出一个几乎任意长的利益相关者名单，他们关心软件及其相关基础设施的功能、成本、可靠性和其他方面。 这就引出了许多人提出的问题：“安全有什么特别之处，我们需要一个 DevSecOps 术语？”
很高兴你问了。
首先，它只是作为一个有用的提醒。 如果开发人员和运营人员历来是 IT 组织中最常见的两个孤岛，那么安全就是（而且通常仍然是）另一个孤岛。 安全人员通常被认为是保守的守门人，“不” 对于新的软件版本和技术来说，通常似乎是最安全的回应。 安全部门的工作是保护公司，即使这意味着阻止快速开发过程。
传统安全的许多方面，甚至它的词汇，对于非专业人士来说也显得晦涩难懂。 这也导致了这样一种观念，即安全是主流 IT 之外的东西。 我经常分享以下轶事：一两年前，我正在伦敦的 DevOpsDays 活动中主持一个安全讨论，我们在讨论传统的安全角色。 其中一位参与者举手承认他就是那些安全守门人之一。 他接着说，这是他职业生涯中第一次参加不是 RSA 等传统安全会议的会议。 （他还指出，他将更广泛地拓展他和他团队的视野。）
因此，DevSecOps 或许不应该是一个必要的术语。 但在软件安全威胁不断升级的时候，明确地指出它似乎是一个很好的做法。
第二个原因是，云原生技术（尤其是那些围绕容器构建的技术）的广泛引入与 DevOps 实践密切相关。 这些新技术正在导致并实现更大的规模和更动态的基础设施。 静态安全策略和清单不再足够。 安全必须成为一项持续的活动。 并且必须在您的应用程序和基础设施生命周期的每个阶段都考虑它。
以下是一些示例
您需要保护管道和应用程序。 您需要使用可信的内容来源，以便您知道谁已签署容器镜像，并且它们是最新的补丁。 您的持续集成系统必须集成自动化安全测试。 您有时会听到人们谈论“将安全左移”，这意味着在流程中更早地进行，以便可以更快地处理问题。 但实际上，最好考虑在测试、集成、部署和持续管理过程的每个步骤中，将安全性嵌入到整个管道中。
您需要保护底层基础设施。 这意味着保护主机 Linux 内核免受容器逃逸，并保护容器彼此隔离。 这意味着使用具有集成安全功能的容器编排平台。 这意味着通过使用网络命名空间将应用程序与集群中的其他应用程序隔离，并将环境（如开发、测试和生产）彼此隔离来保护网络。
这意味着利用更广泛的安全生态系统，例如容器内容扫描器和漏洞管理工具。
简而言之，它是 DevSecOps，因为现代应用程序开发和容器平台需要一种新型的 Dev 和一种新型的 Ops。 但它们也需要一种新型的 Sec。 因此，DevSecOps。
1 条评论