现如今，尽管各种骇人听闻的网络攻击事件已是各类新闻头条的“常客”了，但是大多数企业仍会在其IT环境的搭建之初就忽略了、或错误地实施了安全管控。
而对于一些初创型企业及其新建的IT系统而言，它们时常会将有限的资金花费在无关的资产、或流程的保护之上。根据Verizon 2018年度数据泄露调查报告显示，在一般企业的系统中，有40%的漏洞会出现在应用层。而他们花费在保护应用程序上的年度安全预算，却只有3%～4%。
与此同时，一般企业的IT部门在人员岗位分配上也存在着不均衡的现象，时常会出现100名开发人员仅配备了一位安全技术专家的状况。而这些孤独的安全人员，往往不得不疲于提供瀑布式的安全策略与实践，以赶上整个研发团队的敏捷开发节奏。因此，当他们根据安全检查表中的不达标项，叫停某些应用编码工作、进而导致延迟产生的时候，都将被视为是对公司当前项目推进的阻碍、内部生产效率的破坏、甚至是对整体文化的“毒害”。
在现实情况中，如果您没有在整个软件交付的管道中实施安全流程管控的话，那么您必将面临着各种组件的延迟交付或风险发布，而且这些组件往往会带有潜在的漏洞。不过，这恰好是DevSecOps能够发挥作用的地方。它通过各种安全实践，来最小化软件交付管道中的各种脆弱性，为组织的IT和业务的目标保驾护航。
在XebiaLabs公司(译者注：一家独立的软件公司，专注于为大型组织开发企业级的持续交付与DevOps软件)最近组织的一次网络研讨会上，来自Signal Sciences的研究主管--James Wickett，与DevOps思想领袖--Gene Kim，以及XebiaLabs的首席产品官(CPO)--Rob Stroud，讨论了如何将安全性接入到整个DevOps生命周期中的三项原则。
您除了可以通过链接：https://xebialabs.com/community/webinars/devsecops-missing-link-of-business-velocity/，来收听该网络研讨会的现场录音之外，还可以通过如下文字阅读有关DevSecOps的三项核心原则。
原则1：为最坏的场景做好设计
为了将安全性尽量“左移”(指各项流程管道的初始阶段)，获取开发部门的理解与支持是非常重要的。为了实现该目标，各个企业需要帮助研发人员了解到，在他们的应用程序中可能存在的威胁与漏洞，并需要有针对性的进行各种计划与设计。Wickett建议采用如下四种方式：
- 舱壁模式(Bulkhead Patterns)-- 以一种分割应用程序之间依赖性的方式，来设计您的程序代码。这是一种“未雨绸缪”的设计理念。如果您能够隔离应用程序中的各个组件，那么纵然某一个组件出现了故障，而其他组件仍然可以运行并提供服务。Wickett说，该模式的典型应用案例就是针对微服务的引入。您会很自然地借用舱壁的理念，将大的整块服务分割成多个小的单功能服务。虽然这是一种绝佳的安全实践，不过我们也需要在企业环境中事先考虑到微服务的扩展限制问题。
- 恶意用户场景(Evil User Stories) -- 您可以通过描述用户如何破坏系统的安全性，来提醒敏捷开发团队，在他们编写最终产品代码时限制恶意用户的各种可能行为。例如他们可以这样制定代码的逻辑：如果有用户在访问某个网站时，试图进行跨站点脚本注入攻击，那么就直接拒绝其任何操作行为。Wickett说，那些具有高安全性的组织，通常会使用各种既定的语言、模式和测试框架，来描述不同的用户场景，并以此融入现有的敏捷开发企业文化之中，使之成为可接受的系统的一部分。
- 威胁建模(Threat modeling) -- 在软件开发的过程中，您可以使用威胁模型来说明应用程序在运行时所涉及到的组件，并识别出这些组件可能面临的潜在风险，进而选取最好的防护措施。威胁建模对于那些缺乏安全专家人手的环境是至关重要的。同时，通过提供一些具有针对性的风险管控模型，安全人员会更容易实现与研发部门的沟通，并达成共识。
- 风险评估(Risk Assessments) -- 您可以将基于风险的评估方法运用到自己的环境中，以确定哪些给定的措施更适合于自己的用例环境。这将有助于开发人员通过提供参数输入的方式，将评估集成到应用的设计与实施阶段，并贯穿整个项目的生命周期。
原则2：安全测试贯穿整个管道
一般而言，针对软件交付管道的全面安全加固，就意味着：在应用程序的整个生命周期，对每一个组件和阶段，都采取漏洞测试。您可以采用如下的方法测试软件交付管道的安全性。
- 逆境测试(Adversity Testing) -- 您可以通过各种“实战性”的攻击工具，对自己的管道进行注入攻击，以找出不同的安全漏洞。Wickett推荐下载的工具包括：Metasploit(https://www.metasploit.com/)、Nikto(https://cirt.net/Nikto2)和Arachni(http://www.arachni-scanner.com/)。安全人员通过利用它们来对某个网站进行测试，以找出那些薄弱的环节。这些测试的目的都是为了获悉您系统环境中的漏洞，以及整体抗攻击的能力。
- 安全即代码(Security-as-Code) -- 类似于基础设施即代码(infrastructure-as-code, https://xebialabs.com/glossary/infrastructure-as-code/)，安全即代码是将各种安全模式集成到代码系统之中，成为一个自动化的流程部分。由于它能够更多地将开发人员带入安全相关的流程中，因此安全即代码是企业塑造DevSecOps文化的重要组成部分。
- 漏洞测试(Vulnerability Testing) -- 通常情况下，我们会用不同的方法对应用程序进行漏洞测试。其中包括：
- 静态应用程序安全测试(SAST)，提供了一套检测应用程序代码漏洞的工具集。
- 动态应用程序安全测试(DAST)，是采用外部攻击，来测试应用程序的运行状态的一种方法。
- 交互式应用程序安全测试(IAST)，是在测试阶段分析应用程序的行为，以帮助开发者对所发现的漏洞进行优先级排序的一种方法。
原则3：摒弃只重视AppSec培训的谬误
在过去十年间，整个行业都过于重视培训开发人员编出具有安全性的代码。虽然AppSec培训非常重要，而且其各种最佳实践能够提高企业的整体安全意识，但是它也会带来一些其他问题。对于一些新手程序员而言，只要是用人工编写代码的方式，就可能会带有漏洞。因此我们不应盲目地认为他们所开发的代码，足以让其应用程序固若金汤。同时，接受过AppSec培训的研发人员，会更具备“全栈”的开发能力，当然更容易被其他公司所“挖”走。
因此，我们不能只专注于开发人员是否能编写出更为安全的代码，而应该尽可能地将各种流程自动化，并放置到软件交付管道的左侧(初始阶段)，同时在右侧(管道的末端)增设各种与安全相关的监测工具。另外，我们应当尽量通过一套部署管理系统，来强制实施各项自动化的进程，以保证代码在最终发布阶段的安全性。
安全性和敏捷性并重
对于一般企业而言，将不同职能部门的团队组织起来，通过DevOps的协作方式，在规定时间内交付出软件产品是极具挑战性的。我们时常会看到一些实施了DevOps的企业，他们的团队虽然实现了在软件产品交付上的“提速”，却无法让产品达到相应的安全水准。因此，如果您在软件持续交付的过程中忽略了安全性的保障的话，那么您最后将会失去客户的信任，也没有人愿意、或敢去使用您的软件产品。
原文标题：Delivering Security and Speed: The 3 Core Principles of DevSecOps ，作者：Tim Buntel
