书名：DevSecOps极简入门
ISBN：978-7-115-67873-7
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] 史蒂夫·苏哈林（Steve Suehring）
译 刘 华
责任编辑 秦 健
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2024 Steve Suehring. All rights reserved.
Simplified Chinese Edition, jointly published by O’Reilly Media, Inc. and Posts & Telecom Press, 2026. Authorized translation of the English edition of “Learning DevSecOps” © 2024 O’Reilly Media, Inc., the owner of all rights to publish and sell the same.
All rights reserved including the rights of reproduction in whole or in part in any form.
本书中文简体字版由O’Reilly Media, Inc.授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。
本书从需求到实践，围绕DevSecOps展开，系统讲解其核心理念与应用。首先，从DevSecOps的需求入手，强调了文化优先和流程胜于工具的原则，同时分享了软件开发的基础知识；其次，聚焦集成安全，涵盖最小权限、数据保护、安全意识等内容；再次，探讨代码管理与测试，讲解Git的使用方法及测试类型；最后，通过示例介绍了与部署、运维、监控及扩展相关的话题，内容涉及Docker、Kubernetes等工具的应用。此外，还展望了DevSecOps的未来发展趋势。
本书适合软件开发人员、运维工程师、安全专家及对DevSecOps感兴趣的IT从业者阅读。
本书提供如下资源：
• 书中图片文件；
• 本书思维导图；
• 异步社区7天VIP会员。
要获得以上资源，您可以扫描下方二维码，根据指引领取。
作者、译者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区（https://www.epubit.com），按书名搜索，进入本书页面，单击“发表勘误”，输入勘误信息，单击“提交勘误”按钮即可（见下页图）。本书的作者、译者和编辑会对您提交的勘误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们。
如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是由人民邮电出版社创办的IT专业图书社区，于2015年8月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作者与读者在线交流互动，以及传统出版与数字出版的融合发展。
“异步图书”是异步社区策划出版的精品IT图书的品牌，依托于人民邮电出版社在计算机图书领域四十余年的发展与积淀。异步图书面向各行业的信息技术用户。
DevSecOps的职位空缺非常多，但只要你仔细查看这些职位的具体要求，不难发现，业界对于DevSecOps的实际需求尚未达成共识。这正是撰写本书面临的挑战之一。我撰写过从MySQL到JavaScript，再到Windows Server以及Linux防火墙等主题的图书。这些技术都有其明确界定的范围。例如，撰写Linux防火墙的书，并不需要在同一本书中涵盖多种不同的技术和技能。然而，DevSecOps的定义则不够明确。撰写有关DevSecOps的内容，会暴露出我们在实际操作与概念推广之间定义技术的差异。此外，DevSecOps这一术语的使用频率远不及DevOps，这不仅仅是因为它念起来不如DevOps顺口。为DevSecOps的定义发声是我决定写这本书的原因之一。
本书的目标并不是成为一本关于如何实施DevSecOps的全面、手把手指南（无论该术语如何定义）。由于工具快速更迭，且每个组织在向DevSecOps转型时的需求各不相同，编写这样一份详尽的指南是不切实际的。相反，本书旨在展示一些成功的模式，并分享一些大型DevSecOps实施过程中涉及的部分技术和实践。本书并未试图涵盖组织在DevSecOps中可能使用到的所有软件工具。这不是疏忽，或更准确地说，这是一种有意为之的选择，目的是将关注点放在流程和人员上，而非技术与工具上。毕竟，技术与工具会不断更新换代，而拥有最优秀的人才并实施最佳的流程，才是持久不变的目标。
什么是DevSecOps？这取决于你问谁。根据本书的定义，DevSecOps是一套敏捷迭代的实践方法，旨在帮助研发人员快速、准确且持续地交付软件和技术系统，其核心在于强调流程和人员的重要性超过工具。
DevSecOps关乎文化。我曾在一些未实施敏捷和迭代方法的组织工作过，在这些组织中，软件开发流程中频繁出现返工现象，技术选型往往由不具备资格的人决定，他们没有充分考虑工作流、生产力或最佳实践，更不用说终端用户的体验了。甚至在我们还未明确要构建什么之前，截止日期就已经确定好了。相比之下，在DevSecOps文化中，测试和安全是开发流程中的自然组成部分，而非事后的附加项。无论是DevOps还是DevSecOps，都非常重视自动化和脚本的应用。
计算机领域一直在不断自我重塑。本书中提及的许多实践，自计算机诞生之初就已存在。例如，大型机曾允许多个用户分时使用计算时间和资源，这与今天我们通过云配置所做的工作类似，只是规模更大。如今我们所践行的所谓“现代DevSecOps实践”，其实在Linux操作系统上已经存在几十年了。虽然脚本和自动化不是新鲜事物，但将其规范化，并确保得到组织内所有成员的支持，正是DevSecOps带来的价值。简言之，DevSecOps的核心：赋能人员，利用流程和工具，快速且持续地提高软件质量。
本书适合任何希望深入了解DevSecOps及其前身DevOps的读者阅读。无论你从事开发、运维还是安全工作，如果希望了解如何将这三者融合成一套统一的工具和流程，以简化生产环境部署，本书都将为你提供宝贵的见解。为了最大化地从本书中获益，拥有一定的计算机背景是有帮助的。但即便没有深厚的技术背景，对DevSecOps感兴趣的读者也能从第1章中受益。
在DevSecOps实践中，能够编写、提交并推送代码，以及对该代码执行自动化测试是一项关键技能。跨云部署同样常见且重要，而所有这些步骤都可以无缝完成。当然，实现这种程度的自动化不仅需要理解自动化的目标，还需要掌握配置自动化的技术知识。鉴于此，如果你有兴趣探索DevSecOps所涉及的流程，并想学习相关技术细节，那么本书将会是一份有价值的资源。
本书共分为8章，除少数示例贯穿全书以外，大部分章节设计为独立的内容模块，读者可以根据自己的兴趣和需求选择性地阅读特定章节。
第1章为本书后续内容构建了框架。这一章不仅展示了如何通过瀑布模型和敏捷等方法开发软件，还特别介绍了DevSecOps的开发方式。第1章讨论了打破部门壁垒的必要性，并深入探讨了文化在DevSecOps中的重要性。
第2章浓缩了成功实施DevSecOps所需的一些基础知识，或者说是获得此类知识所需的基础。这一章尝试将广泛的计算机课程内容精炼于一处，为读者提供一个坚实的知识起点。
第3章在第2章的基础上进一步深化，专注于安全方面，并讨论了OWASP ZAP工具。
第4章探讨了DevSecOps中的Git和Gitflow模式。这一章还介绍了各个级别的测试方法。
第5章探讨了“配置即代码”的概念，并引入了Docker技术。此外，这一章还将指导读者如何为Docker构建本地仓库。
第6章涵盖了使用Ansible和Jenkins进行部署和代码构建的方法，虽然这些不是唯一的解决方案，但应用非常广泛。这一章还讨论了监控的最佳实践。
第7章将焦点转向Kubernetes，讨论如何将其集成到DevSecOps流程中，以便于集群化和扩展软件部署，满足组织成长的需求。
第8章总结了本书提出的5种模式以及成功的DevSecOps组织的关键要素。
下面是本书所使用的印刷约定。
斜体（Italic）
表示新的术语、URL、电子邮件地址、文件名和文件扩展名。
等宽字体（Constant Width）
用于代码清单，以及在段落中引用程序元素，如变量或函数名称、数据库、数据类型、环境变量、语句和关键字。
等宽斜体（Constant width italic）
表示应由用户提供的值或由上下文确定的值替换的文本。
这表示提示或建议。
这表示一般性的注释。
这表示警告或注意。
近40年来，O’Reilly Media致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。
我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享知识和经验。O’Reilly的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境，以及O’Reilly和200多家其他出版商提供的大量文本和视频资源。更多相关信息请访问http://oreilly.com。
如果读者对本书有任何的评论或疑问，可以与出版社联系。
美国：
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
我们为本书提供了一个网页，其中包含勘误表、示例和其他信息，读者可以通过https://oreilly.com/library/view/learning-devsecops/9781098144852/进行访问。
如果你对本书有任何评论或技术上的建议，请发送电子邮件到errata@oreilly.com.cn。
关于我们的书籍和课程的新闻与信息，可以访问https://oreilly.com。
感谢技术审阅者Patrick Dubois、David Volm、Swapnil Shevate和Vladislav Bilay所付出的时间、精力以及提供的宝贵反馈。他们的专业知识帮我指出了本书需要进一步涵盖的领域，从而提高了内容的质量和全面性。同时，也要感谢Partners的Rob、Jim和Jaclyn以及Tim在审阅过程中给予的帮助和支持。
软件是为了应对问题而设计的。然而，在创建软件的过程中，往往会出现一系列挑战，甚至有时会引发新的问题。组织需要决定是开发定制软件还是选购现成的软件。对于像办公生产力套件这样的通用软件，购买预制软件通常是更经济的选择。但在涉及复杂业务功能领域的解决方案时，通常需要进行定制化开发。这类定制解决方案旨在实现获得竞争优势或提升效率等最终目标。
自20世纪90年代末至21世纪初，软件开发过程经历了显著变革。这一时期的重大转变体现在从集中精力收集需求转向强调迭代和速度。通过可重复的流程和自动化，迭代式软件开发方法能够快速部署新功能，并在整个开发生命周期中融入反馈机制。同时，随着崇尚开源和透明价值观的文化转变，组织内部形成了注重整体质量而非单个领域表现的跨职能团队。此外，开发、运维和安全等多个团队的整合催生了DevSecOps组织模式。
本章将探讨推动DevSecOps发展的因素。首先关注软件开发过程，因为了解软件开发方法的演进有助于成功实施DevSecOps。其次，本章还将突出文化变革在组织向DevSecOps转型中的重要性。
为了实现目标，组织会分配一定的资源用于软件开发。首先需要考虑的是，这些资源若投资于其他领域，可能会带来更高的回报。例如，投资10万元进行市场营销活动，可能比将相同金额用于简化网站的客户注册流程能吸引更多的客户。
即使资金充足，速度依然是关键考量因素之一。快速创建和部署软件的能力往往是获取竞争优势或提升效率的决定性因素。然而，在某个时间点之后，单纯增加开发者数量并不能加快项目进度。实际上，随着更多开发者的加入，保持沟通的顺畅变得更加困难。
软件的起点是一个想法。将这一想法转化为实用的软件，需要仔细思考与规划。根据所开发软件的不同类型，可以采用多种管理流程。软件开发过程通常包括收集需求、设计方案、开发代码以及测试代码等阶段，如图1-1所示。
图1-1 软件开发过程
这4个阶段有时也被称为软件开发生命周期（Software Development Life Cycle，SDLC）。这一过程可以被概念化为瀑布模型。在这一模型中，每个阶段都会产生一个或多个工件，这些工件随后会被传递到下一个阶段，如图1-2所示。
图1-2 瀑布模型中的每个阶段
在采用瀑布式方法进行软件开发时，必须在完成前序所有阶段之后才能开始下一阶段。例如，在图1-1中，只有在彻底完成需求收集和记录之后，才会进入被标记为“设计方案”的阶段。如果在设计方案阶段发现了新的需求或是出现了其他问题导致新需求的产生，这些新需求通常会被安排到后续的项目或迭代中解决。
在收集需求阶段结束时，项目的范围会被正式定义下来，这包括了软件应具备的所有特性和功能。这些特性不仅涵盖了软件的主要功能，也包含了非功能需求，如响应速度、安全以及其他应用行为等。满足这些非功能需求对于确保最终软件产品的用户体验至关重要，因为任何在这方面的不足都可能导致用户的不满与失望。
以一个业务需求为例：让客户能够找到产品并下订单。在计算机和互联网普及之前，实现这一需求的方式多样，如客户亲自前往商店购买产品，或者通过产品目录查询产品后电话订购。然而，随着计算机和互联网的发展，这样的业务需求现在大多通过网络渠道来实现。
满足让客户能够使用网站查找产品并下订单的业务需求确实可以有多种解决方案。虽然上传产品目录的PDF文件到网站，并提供一个允许客户通过电子邮件发送订单的表格，可能达到了最低的功能性要求，但这远不能满足现代客户的期望。这样的流程显得笨拙且不便，很可能无法吸引大多数客户通过这个渠道进行购买。
因此，在实现功能需求的同时，我们也需要关注非功能需求，以确保为用户提供满意的在线购物体验。向利益相关者或项目发起人提出一些探索性问题可以帮助明确项目的详细需求和预期目标。例如下面这些问题。
• 产品将如何在网站上呈现（包括照片、叙述、技术规格等）？
• 谁负责拍摄产品照片并将其发布到网上，以及谁来撰写产品描述？
• 如何实时更新库存信息，以避免客户订购缺货产品？
• 客户如何完成下单操作？
• 当有新订单时，如何及时通知员工？
• 谁负责维护在线产品的更新？
• 网站接受哪些付款方式？
• 是否需要客户提供账户信息以便跟踪订单历史和发货状态？
这些问题仅是初步探索会议中需要讨论的部分内容。一些问题可能会转化为后续可行性研究或收集需求阶段的具体功能需求。然而，如果参与会议的人员缺乏类似项目的执行经验，则有可能会遗漏某些关键需求。
项目范围明确了哪些元素将被包含在内，并详细描述了那些不打算纳入项目的其他元素。任何未被明确包含的需求都将被视为超出了项目范围。如果一项基本需求被遗漏，项目发起人将面临艰难的选择：要么重新定义项目范围以包含这项需求，要么决定在没有该需求的情况下继续推进项目，计划在未来通过后续项目来添加遗漏的功能。
从最初的想法到最终的实施可能需要经历数月甚至数年的时间。在从概念产生到软件产品发布的这段时间里，项目发起人在面对遗漏的功能时会感到尤为棘手。特别是在此期间，如果竞争对手发布了包含这些被遗漏功能的产品，那么原本希望通过该项目实现的竞争优势可能会迅速消失，因为市场动态和竞争环境已发生变化。
接下来的章节将会深入探讨这些问题，并介绍现代软件开发方法所提供的解决方案。
为了应对项目定义和完成之间的时间滞后，许多组织已转向采用敏捷和Scrum等迭代方法，以此作为快速向利益相关者交付价值的有效手段。在迭代式软件开发过程中，开发团队能够循环执行收集需求、设计方案、开发代码和测试代码这4个阶段。与试图一次性收集所有细节需求的传统方法不同，迭代开发方法专注于当前对利益相关者最有价值的功能特性。然后，通过一轮轮的收集需求、设计方案、开发代码、测试代码直至发布产品，迭代过程能够在极短的周期内（通常为2到4周）实现最有价值的功能。图1-3展示了如何利用敏捷等迭代流程处理SDLC中的每个阶段。
图1-3 利用敏捷类迭代流程处理SDLC中的每个阶段
如图1-3所示，在一次迭代中，软件开发的每个阶段都会被涉及，并且每个迭代周期结束时都会产生可工作的软件。然而，由于迭代开发本质上是一个产品逐步演进的过程，它并不会尝试在项目一开始就收集所有需求。如果在这个过程中遗漏了某些需求，利益相关者可以选择不在当前版本发布该功能，或者在后续迭代中添加这些被遗漏的需求。因为每次迭代的周期很短，通常只有几周时间，所以新需求或修改可以在较短时间内得到实现和发布，而不像瀑布模型那样需要等待几个月甚至几年的时间才能看到结果。
此外，迭代开发还具有快速响应市场变化的优势。例如，当你对于一个撒手锏应用有了很好的创意并开始着手开发时，如果竞争对手发布了类似的应用，采用瀑布模型则可能意味着你需要完全放弃该项目，因为它无法及时调整以应对市场变化。但在迭代开发模式下，你可以迅速调整开发重点，将资源集中在那些竞争对手的产品可能缺失或用户急需的新功能上。
敏捷软件开发包含几个关键的仪式或会议，如Sprint计划会议、每日站立会议、Sprint评审会议、Sprint回顾会议和Backlog整理会议。首先，需要创建一个Backlog，即列出一定时期内所有已知的功能，并对其进行排序。其次，基于这个排序后的功能列表，团队将创建Sprint Backlog。Sprint Backlog反映了团队在当前迭代期间承诺实现的功能。它的制定依据团队成员可承担的工作总量，以及对Backlog中每个条目工作量的估算，这一估算也被称为工作量级别。
在Sprint结束时，会举行评审会议，团队将展示他们本次迭代中取得的成果。Sprint评审会议结束后，团队将在Sprint回顾会议中审视在Sprint期间有哪些做法可以改进。团队可能会在Sprint回顾会议中讨论以下3个问题。
• 我们应该开始做什么？
• 我们应该停止做什么？
• 我们应该继续做什么？
这3个问题将帮助团队反思哪些做法是有效的，哪些是无效的，并确定在下次迭代中可以做出的改进。Sprint回顾会议结束后，团队可以进行Backlog整理，在此过程中对产品Backlog进行梳理和重新排序。通常，这一过程需要利益相关者或产品负责人的参与，他们将为团队设定优先级，确保接下来的开发工作能够聚焦于最有价值的任务。
有缺陷的需求会导致产生有缺陷的软件，或无法满足原始需求的产品。即使成功从项目发起人那里获取了原始需求，仍可能开发出存在问题的软件。这样的结果会导致用户不满意、功能不符合预期，并带来潜在的安全风险。
在检查需求过程中，开发者经常会遇到各种问题。这些问题的范围非常广泛，从一些相对简单的问题（如特定语言中条件语句中大括号的位置）到更为关键的问题（如获取数据库连接所需的凭证）。对于后一种情况，项目的开发工作可能会因此暂停，直到所需的凭据被提供为止。而在其他情况下，开发者则可能尝试通过自己的方式解决问题并继续前进。
如果开发者在孤立的环境中进行软件开发，即与团队之外的人没有任何互动，也会导致软件出现诸多问题。在这种孤岛式的开发模式下，无论采用瀑布模型还是类似方法，开发者都会尽可能地去理解和检查需求。然而，这往往会出现以下情景：“网站应该支持哪些Web浏览器？”一个典型的回答可能是：“浏览器？我一直使用Chrome进行开发，没有考虑过网站能否在其他浏览器上正常运行。”图1-4展示了这种孤立环境下的开发情形。在这种情形下，开发者、运维人员和安全工程师之间缺乏有效沟通，彼此无法了解对方的想法。
截止日期对功能的数量和质量有着直接影响。为了赶上交付的最后期限，开发者可能没有足够的时间去考虑或解决在不同浏览器或设备（如手机）上测试时可能出现的问题，更不用说去修复这些问题了。如果跨浏览器测试不是项目流程的一部分，并且需求文档中也没有明确规定网站需要兼容哪些浏览器，那么最终网站能在哪些浏览器上正常运行将无法预测。
图1-4 组织内孤立的开发导致成员彼此无法了解对方的想法
在软件开发项目管理中，截止日期或项目时间表是可调整的3个关键因素之一，其他两个因素分别是成本和功能。这三者之间的关系常被比喻为“软件开发三角”（见图1-5），意味着在一个项目中只能同时优化其中两个方面：如果项目要完成得快并且功能丰富，成本就不得不增加；如果需要在预算有限的情况下实现众多功能，则项目周期必然会延长；同样地，如果必须严格控制时间和成本，就需要在功能上做出妥协。
图1-5 软件开发三角
下一个要解决的问题是开发和质量保证（Quality Assurance，QA）之间的交接。
在开发与测试流程过渡到生产环境部署的过程中，开发者与运维团队之间的交接往往颇为棘手。这里的运维团队可能涵盖网络管理员、系统管理员或工程师（如站点可靠性工程师、生产工程师等），他们的职责在于确保软件能够在生产环境中顺利运行、操作及维护。
运维团队面临的一个挑战是，他们需要接手那些未曾在生产环境中测试过的软件，并确保这些软件能够依据组织的服务级别协议（Service Level Agreement，SLA）正常运行。通常，这类软件仅在开发者的个人计算机上进行初步测试，随后在规模较小的QA环境中进一步验证。然而，QA环境与生产环境之间可能存在显著差异，例如，前者或许没有配备负载均衡器，或部署于不同的地理区域，甚至其工作负载远高于生产环境。即便如此，软件依旧被部署到生产环境中，而运维团队则肩负起支持这些软件的责任。
设想这样一个情景：在软件部署之前，一切似乎都运行得相当顺利。任何请求几乎都没有延迟，即使所有开发者同时在网站上工作，响应时间也没有显著增加。然而，这里忽略了一个关键点——开发者使用的服务器与他们位于同一局域网内，并且应用程序访问的数据来自一个很少收到请求的非生产数据库副本。
当运维团队将软件部署到生产环境中时，网站性能迅速恶化至几乎无法使用。登录的用户遇到了严重的问题，因为会话现在分布在多台服务器上，而不像开发环境中那样仅限于一台服务器。此外，还会遇到一系列安全问题。
在一些组织中，可能存在一种“不惜一切代价交付”的心态以及对最小可行产品（Minimum Viable Product，MVP）的追求。理论上，这种开发策略或许能够奏效，即假设未来会有时间来解决当前遗留的问题，从而先以“最小可行”的方式推出产品。然而，在现实中，这样的未来时间往往不存在。
随着截止日期的临近，安全往往是第一个被牺牲的方面，或者至少给人一种已经充分考虑了安全的错觉。如同数学问题一样，确保安全是一个复杂且困难的问题。对于安全分析师来说，他们需要确保每一次的安全措施都无懈可击，而攻击者只需要找到一处漏洞即可成功。
在组织内部，数据安全部门通常被视为那个总是说“不”的部门。无论是关于新应用程序的请求、防火墙规则的更改，还是放宽数据库访问权限的要求，负责维护安全的人员往往会倾向于在变更请求过程中采取保守态度，也就是拒绝这些请求。
运维和数据安全的固有挑战是，它们在问题浮现之前通常是不可见的。就数据安全而言，大量时间被花费在合规性审计上，但这些审计对许多组织的日常安全似乎帮助有限。尽管遵守法律和法规至关重要，但这些规定往往落后于现实，这意味着它们主要针对的是过去的漏洞，而攻击者则利用最新的零日漏洞进行攻击。
在DevSecOps框架内，安全集成尤为重要，这样可以确保诸如绕过防火墙防护或采用不合规的数据访问与存储方法等变更不会被考虑。如果缺乏这种集成，开发者可能会采取一些不安全的做法，例如，使用未加密的密码或将凭据存储在源代码管理系统中，这可能导致敏感信息暴露给无权访问的人员。
本节探讨了与软件开发相关的多个问题，其中一部分可以通过实施DevOps和DevSecOps来解决。接下来，我们将深入分析组织文化如何影响成功引入DevSecOps的能力。
组织文化是决定DevSecOps能否成功实施的关键因素。在一个以控制为导向、遵循自上而下管理模式的组织中，实现DevSecOps所需的变革将面临重重困难。这样的组织或许能够采用看似符合DevSecOps的技术手段，但由于跨团队之间缺乏有效的文化交流和合作，真正的转型难以达成。
若未曾亲身体验在高度控制导向的组织内尝试推行类似敏捷的实践，可能很难理解文化契合度的重要性。在这些组织中，重点往往不是寻找最佳解决方案，而是维持层级结构和分离状态，确保高层管理者的控制权得以保持。没有这种经验的人可能会低估文化在DevSecOps成功中的作用。
然而，无政府状态和混乱绝非DevSecOps的目标。相反，DevSecOps提倡一种开放且协作式的问题解决方法，鼓励来自不同部门的人员共同参与并贡献解决方案。值得注意的是，尽管有人认为创业公司那种灵活的文化更适合DevSecOps的发展，但实际上，远非如此。
创业心态代表着竞争与创新，它不拘泥于传统的等级制度，而是更关注如何开拓新领域。在这样的环境中，创业公司的创始人常常与员工并肩工作，既作为同事也担任导师，共同推动产品发展。在创业公司中，职位头衔远不如确保实际工作的完成来得重要。
类似地，在DevSecOps实践中，成员们跨职能协作，根据项目需要灵活运用各自的专业技能。就像在一家创业公司中一样，团队的工作是透明且公开的，最终目标是完成有意义的工作。这种环境促进了早期问题的发现与解决，使得团队在问题显现之前就能处理好。
| 未集成安全的DevOps 在DevSecOps概念出现之前，已经存在DevOps（开发和运维一体化）。然而，人们很快意识到，如果未集成安全最佳实践，开发和运维的成效将大打折扣。 通过在项目初期就引入安全讨论，可以使安全贯穿整个开发过程，而不会显得突兀或造成阻碍。 |
即使某些组织尚未准备好全面集成安全措施，DevOps仍然能够为其带来价值。然而，值得注意的是，那些导致DevOps运动兴起的问题（如部署问题），往往到后期才被发现，也可能因为生产环境或实际应用环境中缺乏（必要的）安全控制措施而再次浮现。当这类情况发生时，便凸显出向DevSecOps文化转变的重要性，并强调了在整个软件开发生命周期中融入安全思考的必要性。
1.3节将介绍DevSecOps的核心概念，重点强调的是流程而非用于实现流程的工具。
DevOps和DevSecOps更加注重流程，而非用于实现流程的工具。如果缺乏文化契合和流程变革，在DevSecOps中使用的工具往往可能成为开发进展的障碍，甚至有时会减缓开发的速度。即使组织尚未完全准备好进行DevSecOps所需的文化转型，依旧可以通过采纳一些DevSecOps的最佳实践来获得益处。现在，让我们探索其中一部分，首先识别那些愿意接受并适应DevSecOps的人才。
管理层的认可和对DevSecOps流程的明确承诺是决定DevSecOps成功的关键因素。虽然促进团队间的交流是一个必要的开始，但这可能更多地具有象征意义而非实际效果。管理者不应寄希望于将利益有时相互冲突的各方聚集在一起就能自然而然地产生理想的结果。
识别DevSecOps的价值涉及跨多个职能领域的技能。例如，一个能够自行部署集群，并能够清晰地解释域名系统（Domain Name System，DNS）和动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）之间的差异的开发者，可以成为组织内推行DevSecOps试点项目的合适人选。这些具备多样化技能的人员能够为推动DevSecOps的发展提供有力的支持。
确定并融合多种技能，然后让拥有这些技能的员工跨越职能界限工作，是推动DevSecOps成功的第一步，这同时也彰显了管理层对DevSecOps认可的重要性。开发者需要访问或至少了解可能完全归运维部门管理的服务器和网络领域。同时，运维人员和安全人员应在项目的早期阶段就实际参与到项目中，以便他们能够提供反馈来优化后续流程。
例如，在开发过程中可能会遇到显著增加磁盘使用率的情况。然而，通过简单的调整，可以将这种使用率重新分配到不同的系统上，从而避免潜在的问题。实施此类变更的机会仅在开发过程的初期，这正是要确保运维人员真正参与到每一个项目中的原因。
DevSecOps流程将来自不同职能领域的人员聚集在一起。一旦这些人员汇聚一堂，目标便是开发出更优质的软件，即能够满足需求并实现快速且精准交付的软件。这一目标的达成可能涉及众多工具的应用。在后续内容中，我们将深入探讨这些过程和工具。
工具对于高效完成特定工作至关重要。例如，一位工人使用连接到压缩气罐的射钉枪将瓦片固定在屋顶上。同样的工作理论上也可以用锤子完成，但使用螺丝刀则会变得异常艰难。当然，可以尝试使用螺丝刀的手柄敲击钉子将其钉入，但这不仅速度慢，而且可能导致钉子弯曲以及瓦片损坏。如果缺乏经验的我在屋顶上尝试操作射钉枪，则很可能因操作不当而受伤。
DevSecOps的情况与此类似。就像正确地为建筑物加盖屋顶需要熟练的工人和合适的工具一样，DevSecOps也需要恰当的工具及专业的人员。正如强大的射钉枪在合适的人员手中能成为得力助手一样，DevSecOps工具在合适的人员手中也能极大地提升效率。
工具应当辅助完成任务，而不是定义任务本身。
DevSecOps专注于构建可重复的流程，从而推动自动化的发展。同时，自动化也促进了可重复流程的形成。确实，两者是相辅相成的。自动创建环境和部署代码使得这些流程能够被反复执行，并且每次都能获得一致的结果。自动化测试减轻了手动测试和对相同代码区域进行重复测试的负担，即使在进行了更改或修复错误之后亦如此。
在实施有助于提升可重复性的流程和工具时，“即代码”范式在实践DevSecOps的组织中占据了核心位置。“基础设施即代码”“配置即代码”“一切即代码”等概念均指向同一个理念：尽可能利用源代码管理工具和流程来管理尽可能多的方面。
大多数服务器采用文本文件或类似的文本文件格式来存储配置元素。这些文件能够纳入源代码管理工具（如Git）中进行管理。通过这种方法，可以对配置的更改进行版本控制。例如，其他管理员可以通过查阅提交历史发现我曾经在DNS主机名中误用了下画线，导致数千个域离线。如果该仓库是私有的，这样的错误就不会被发现。当配置更改引发问题时，版本控制系统能够快速恢复到之前的稳定状态。服务器配置的源代码管理不仅促进了版本控制，也意味着开发者可以部署特定版本的配置，以便在相同的环境下重现已报告的问题。
相同软件版本和配置集的使用确保了软件部署的可重复性，这一点与持续集成/持续部署（Continuous Integration/Continuous Deployment，CI/CD）场景紧密相关。在这些场景中，代码会经过一系列环境自动测试并提交，最终部署到生产环境。管理员更改服务的配置元素后，将修改提交到配置文件，并推送这些更改至远程仓库，远程仓库检测到这些变化后，自动触发相应服务器上的部署流程。
|
我故意忽略了用于存储配置的多种格式，如YAML、INI、XML、JavaScript对象表示法（JSON）、brew脚本、m4命令以及任何其他可以通过文本编辑器（如Vim）编辑的格式。在本书中，除非特定情况下需要详细说明以避免混淆，否则所有这些格式均简称为文本文件。以下是YAML的一个示例。 - name: add docker apt key
apt_key:
url:https://download.docker.com/linux/debian/gpg
state: present
- name: add docker repo
apt_repository:
repo: deb [arch=amd64] \
https://download.docker.com/linux/debian stretch stable
state: present |
DevSecOps还能在整个开发过程中提供更好的可见性。这种可见性不仅能通过敏捷仪式（如每日站会）得以实现，也能通过根据需要自动将代码部署到不同环境的工具来达成。DevSecOps团队的成员可以精确地了解哪些代码和配置位于哪个环境中，并能够在需要时部署新的环境。
可重复性和可见性提高了系统的可靠性。通过这些特性，代码和环境能够以一致的方式反复部署，确保每次部署的稳定性和一致性。如果在部署过程中出现错误，由于部署工具和流程本身具备高可见性，因此这些问题可以迅速被识别和定位。这种可靠性进一步促进了响应速度的提升，即系统能够快速适应请求量的变化。无论是需要扩展以应对增加的需求，还是缩减规模以优化资源利用，都变得简单可行。这是因为部署依赖于可重复且可靠的流程，从而使得调整变得更加容易和高效。
虽然DevSecOps并不一定依赖于微服务，但采用微服务架构能够提升开发速度及扩大开发规模。通过微服务，可以识别并分离出小的功能代码区域，使得这些功能可以独立运作，为架构内的其他服务提供稳定的应用程序接口（Application Program Interface，API）。通常，API是通过HTTP Web服务来实现的。由于微服务具有独立性，团队成员可以单独进行开发和部署，这进一步增强了整体的开发速度和能力。
本节探讨了涉及DevOps和DevSecOps的一些流程。在1.4节中，我们将基于本章前面介绍的SDLC进行扩展，结合相关流程的核心思想，为实施DevSecOps创建一个增强版的SDLC。
到目前为止，你应当已经了解到软件开发中固有的某些问题。值得注意的是，即使是像敏捷开发这样相对较新的方法，也可能会导致形成孤岛心态。图1-2所示的4阶段模型已经被一个更全面的8阶段模型所取代。新模型整合了计划、构建和测试以及其他关键任务，如图1-6所示。
图1-6 为DevOps创建的新的SDLC模型
适应DevOps的SDLC模型的主要优势在于它更贴近软件开发的实际过程。在实际操作中，编码和测试阶段往往比最初的计划编码和测试所需的时间要长得多。不过，其中的“构建”阶段强调了集成阶段的重要性，在这个阶段，现代应用程序的各个组件被相互连接起来。“发布”阶段则体现了软件的多个组件必须通过的所有审批流程，以便开始部署。值得注意的是，本章前面介绍的SDLC模型并未涵盖软件上线后的运维和监控需求。没有包括“运维”和“监控”阶段，可能会导致运维团队的工作变得不可见。
你可能已经注意到，上述内容和图1-6中暂时缺失了“安全”（Sec）。这是因为，在最初发展时，DevOps作为一项独立的活动并未直接包含安全。显然，我们需要安全，但关键在于它应该如何融入现有流程。从概念和实际操作上看，将安全作为一个单独的阶段来实施是具有挑战性的。如果将“增加安全”设定为一个新的阶段，并安排在计划之后进行，那么在编码过程中引入的安全问题又该如何解决？同样，尝试在测试之后、期间或是发布阶段加入安全检查也存在难度。假设出现严重安全问题，是否整个项目都需要暂停以解决问题？若将安全推迟至运维和监控阶段处理，则意味着问题将在生产环境中浮现，从而面临即时的安全威胁风险。
因此，通常的做法是将安全作为贯穿于每个阶段的基础要素。正如图1-7所示，安全应当融入DevOps流程的每一个环节中。
图1-7 在适应DevSecOps的SDLC模型中，安全是每个阶段的一部分
安全通常以这种方式描述，旨在强调在软件开发的每一个阶段都应融入安全和面向安全的流程。这避免了需要确定安全阶段应在开发流程中的哪个位置出现，以及当发现安全问题时该如何处理的难题。
SDLC从原先的4阶段模型扩展到新的8阶段模型，并将安全纳入考量，使得DevSecOps的从业者能够更好地反映现代软件开发所必需的流程。更重要的是，每个阶段要完成的任务无论如何都会发生。适应DevSecOps的SDLC模型仅仅突显了这些任务的重要性。这些阶段将在本书的后续部分中得到进一步的展开和讨论。
DevSecOps是软件开发演进的自然结果，它继承了敏捷流程和透明开源的理念，致力于消除那些阻碍开发进行并降低其可靠性的孤立工作模式。文化变革，尤其是从组织的高层开始的文化转变，是实现DevSecOps最大收益的关键因素。如果管理层未能做出承诺，DevSecOps可能会退化为一种事倍功半的做法，仅仅增加了工具的使用而未带来实质性的改进。然而，随着文化的转变以及团队间壁垒的拆除，通过引入适当的工具可以提升现代组织所需的可重复性、可见性、可靠性、速度和可扩展性。
基于此，本书将以图1-7的内容作为指导，探讨常见的DevSecOps实践案例。每一章将覆盖适应DevSecOps的SDLC模型中的一个或多个阶段，特别关注流程与实践，并介绍在这些阶段中使用的精选工具。第2章将为读者提供一些基础知识，这有助于理解后续章节的内容。尽管许多读者可能已经掌握了相关知识，且对第2章涉及的部分领域有所了解（这取决于其背景），但第2章所涵盖的技术可能是全新的。不过，提前定义好涉及的技术术语，对所有人深入理解DevSecOps来说都将是有益的。这样，随着本书内容的推进，所有读者都能在同一基础上更好地理解和探索DevSecOps的核心概念。
