目标
安全软件部署过程旨在实现几个关键目标，有助于确保软件部署工作的成功。这些目标有助于确保软件不仅对客户可靠、安全和安全，而且以受控、高效的方式进行部署。通过纳入及时发现问题、持续改进和适应敏捷开发的机制，安全软件部署过程使团队能够交付高质量软件，同时适应不断变化的要求和技术。
1. 质量流程。健全的质量保证流程有助于确保软件产品能够一致地工作并满足客户期望，而不会造成中断。这种对可靠性的关注通过减少可能导致关键系统或数据失败的故障风险，增强了客户的安全性，从而提高了客户信任度。
2. 成本和影响管理。对于软件制造商来说，当技术缺陷和流程缺陷在早期流程中被捕获时，修复它们的成本较低，对客户系统造成的损害也较小。这些缺陷影响到的客户可能会遭受停机时间和数据丢失，对他们的财务和声誉位置产生不利影响。
3. 受控和衡量部署。一个明确定义的部署策略包括分阶段推出，如金丝雀发布，允许制造商在现实世界环境中监控性能，而不会影响所有客户。这降低了广泛故障的风险，并为完善后续部署提供了宝贵数据。
4. 全面测试。通过包括自动化测试和监控工具在内的全面测试策略的早期检测，允许团队识别和解决缺陷，然后再演变成更大的问题。早期主动捕获问题提高了产品的质量，并减少了后期昂贵修复的可能性。
5. 持续改进。集成到开发和部署流程中的反馈循环使团队能够从每次迭代中学习，并将这些经验教训应用于未来的发布。使用反馈循环有助于发展安全软件部署流程，并改进安全标准的维护实践，以及提高性能，更好地满足用户需求。重要的是要将“近乎失误”纳入反馈循环。“近乎失误”提供了在不使软件制造商或其客户经历实际事件的全部负面影响的情况下增强程序的机会。
6. 优化敏捷性。团队应该能够快速适应要求的变化、新兴技术和安全威胁。更短的开发周期、协作和迭代改进有助于交付满足不断变化的客户期望的高质量软件。
7. 安全开发生态系统。安全开发生态系统旨在支持开发人员，同时减少缺陷进入代码库的可能性。软件制造商通过在整个开发生态系统中实施自动化的技术控制，更有可能更早地检测到并阻止问题。
安全软件部署过程的关键阶段
成功的安全软件部署基于已建立的安全软件框架，如NIST安全软件开发框架（SSDF）。此外，安全部署取决于纳入到SDLC中的结构化、深思熟虑的过程，该过程最小化风险并促进可靠性。安全软件部署过程的关键阶段在指导软件从初始规划到发布的整个过程中发挥着关键作用。安全部署软件的强烈推荐实践包括在规划阶段进行严格的测试、受控部署和持续反馈。通过遵循这些关键阶段，软件制造商可以增强产品质量，降低部署风险，并为他们的客户提供更好的体验。
规划
在编写任何代码之前，应建立一个明确的计划，以定义目标并构建需求，了解客户需求，确定潜在威胁，并指定成功标准。规划阶段为整个部署过程奠定基础，帮助确保团队在开发之前了解范围、潜在风险和成本。
关键考虑因素
- 运营风险评估：实施全面的、持续的评估，了解在环境中部署软件的风险和后果，降低风险。运营风险评估包括了解系统关系和相互依赖性、潜在威胁、安全、安全、可靠性、性能要求以及与常见缺陷相关的风险。例如，如果一项服务依赖于另一产品的服务账户（SA），并且该SA的权限发生变化，系统的某些部分可能会以看似意想不到的方式失败。必须将安全软件部署程序的过程和技术包括在整体书面产品威胁模型中。
- 进行失败预期审查：有时被称为“预-mortem”，这种审查有助于团队识别潜在的失败，从前瞻性回顾（或“post-mortem”）中汲取见解。
- 平台规模和多样性：部署团队应广泛记录与其产品相关的多个潜在推出场景。团队应计划在软件在多个环境中运行时增加平台和设备的多样性。在考虑设备多样性时，不仅要考虑设备数量。多样性可以包括不同类型的操作系统、硬件品牌、固件版本、固件设置、带宽速度和可靠性、环境设置和地理位置。团队应在提高内部部署率之前验证充分的测试覆盖范围。
- 在线服务多样性：在线服务多样性可能包括数据中心区域和网络配置，并在必要时包括故障转移和备份解决方案。
- 规划部署节奏：无论组织是设置每月的“补丁星期二”还是每天交付多个配置更新，团队都应该正式制定这个计划，并明确传达给内部利益相关者和外部客户。
监控和报告策略
制造商应确定提供最清晰视图系统健康状况的信号，并将识别到的问题报告反馈到持续改进过程中。
人员配置
复杂的部署需要能够监控部署和安全软件部署过程改进的团队。运营人员或软件/流程开发人员的短缺会增加意外事件的风险。
容错
系统可以设计成即使在遇到不良或恶意代码或配置更改时也能保持弹性和/或安全失败。每个组织都应该考虑在规划过程中建立弹性。
弃用和生命周期结束
软件制造商应该计划功能弃用和产品生命周期结束。早期警告将减少对客户的影响，并减少他们面临不利影响的可能性。
补丁管理
软件制造商应该计划对其开发的产品和服务进行补丁管理。他们应该使应用补丁的过程尽可能无缝。安全补丁可能需要随后的更新来修复可能被恶意行为者利用的已识别漏洞。（见下面的N-1版本部分）。
开发和测试
此阶段涉及编码和持续测试。此阶段的测试通常包括单元测试、集成测试和自动化测试（包括静态和动态测试），以尽早捕获问题。代码应在与客户环境紧密类似的条件下进行测试，以帮助确保准确性和可靠性。组织应考虑投入资源，积极尝试在受控情况下使部署过程失败，以防止现场失败。
内部部署（内部测试）
根据软件类型和内部企业需求，内部团队应该是首先使用新软件版本的人。这个“内部测试”阶段允许组织在软件到达外部用户之前捕获问题。通过在现实世界中测试产品，内部用户提供了宝贵的反馈，有助于提高产品的稳定性和性能。所需的设备和获取足够覆盖范围所需的时间会有所不同；组织应建立标准并根据以前发布周期的输入进行调整。此外，组织应建立一个鼓励员工报告潜在问题的文化，即使问题看起来微不足道。
部署和金丝雀测试
向客户的部署应该以受控的方式进行。部署选项可以包括金丝雀部署（向有限数量的客户或系统的小规模部署），允许团队在更广泛推出之前监控性能和解决问题。对于软件即服务（SaaS）产品，这可能涉及将更新部署到服务器的一小部分或引导有限流量到更新的组件。对于本地产品，更新可能首先只发布给一部分客户。组织可能希望考虑变化，如“蓝/绿”部署模型或将客户分成“稳定”和“早期访问”组，使他们能够将新功能的访问与他们的风险承受能力相匹配。
受控部署
在验证了成功的金丝雀部署后，部署团队可以向更多用户发布新版本。随着对新版本的信心增长，部署可以逐步扩展到更多设备或系统。这种受控部署防止了突然的、广泛的故障。组织需要考虑适当的部署速度，以便紧急安全修复与更常规的内容部署相比。组织需要考虑他们的风险承受能力和客户的期望和风险胃口。在部署过程中，团队可能需要一个自动断开连接或相当于紧急停止按钮来停止部署，特别是在发生事件时。
反馈纳入规划
整个过程中的持续反馈至关重要，但特别是在发布后。来自客户、开发和质量团队、系统日志、意外或异常系统行为的示例以及性能指标的直接反馈应该直接反馈到下一个开发周期的规划阶段。这种反馈将使持续改进和更快地对问题做出反应成为可能。
图1显示了这些阶段随时间的变化。每个软件和服务提供商都会根据他们的风险承受能力和其他商业考虑来调整曲线的斜率。提供商还应考虑他们的客户风险承受能力。
手册（Playbook）
手册是确保安全软件部署过程被记录、可重复和弹性化的重要工具。它们提供清晰的指导、最佳实践和应急计划，帮助团队导航部署的每个阶段。手册还有助于软件制造商降低风险并在任何出现的问题时有效应对，最终保护依赖它的软件和客户。尽可能实现自动化，可以帮助上述因素与部署目标保持一致。
像所有手册一样，部署团队应该定期培训和模拟事件测试。学习如何反应的时机不是在系统失败并可能给客户带来问题时，而是在事件发生时。
重要的是要认识到，将软件部署到客户系统涉及商业考虑，而不仅仅是技术考虑。高级商业领袖应确保团队随时间策划剧本，请求更改，并至少每年正式批准手册。联合指南“转移网络安全风险平衡”强调了“领导从上而下”的原则。拥有商业领袖拥有流程将有助于确保组织分配必要的资源来实现成功的结果。
像SDLC中的所有其他元素一样，手册需要定期维护，以监控和改进它们的成熟度水平并实现组织的使命。
错误
在部署过程的任何阶段，产品或支持系统都可能遇到错误。这些错误可能是由于软件或部署系统中逃过测试措施的潜在编码错误造成的。它们可能包括性能问题、兼容性问题，甚至安全问题。
技术领导团队应建立书面手册，指导员工在遇到这些类型的错误时如何操作。这些剧本应包括可接受的错误率阈值、员工响应和指挥链升级。
部署实时监控系统以及自动警报和升级系统的组织，与仅依赖人工操作员相比，可以更快地响应异常和错误。尽早发现问题和自动修复减少了从识别到解决的时间，导致受影响的客户数量减少和停机时间最小化。
紧急协议
手册应包括详细步骤，以处理软件部署期间或之后发生紧急情况，包括详细的恢复任务。至少应涵盖以下主题。
事件检测和报告
明确定义如何识别问题，无论是通过自动监控系统、内部测试和/或客户报告。社交媒体也可能是其他更正式渠道可能缺少的重要信息来源。
工程和管理的升级流程
概述一个结构化的升级路径，指示何时以及如何将事件升级给高级工程师、管理层或甚至外部合作伙伴。
恢复和回滚程序
如果部署导致重大故障，应详细记录一个可以迅速执行的恢复计划。这应该包括恢复系统到先前稳定状态的步骤、验证检查以确保回滚有效，以及防止数据丢失的保障措施。了解如何将客户恢复到最后的已知“好”状态将需要仔细规划，特别是如果目标系统高度多样化。一个常见的策略是通过禁用某些配置来增强系统优雅降级，而不是完全停止部署。
注意：无法实施自动回滚的恢复计划场景需要额外的照顾。
根本原因分析和报告
解决即时问题后，进行彻底的根本原因分析（RCA），作为无责备回顾的一部分，以识别出了什么问题以及为什么。RCA应随后对发现的问题和纠正措施进行记录，以防止未来部署中发生类似事件。在此过程中，“近乎失误”可以提供显著价值。
客户和合作伙伴通知计划
确保有一个计划，以便在发生关键问题时通知客户和合作伙伴。这包括确定适当的沟通渠道（电子邮件、社交媒体、应用内通知）和消息时机，并提供有关问题、其影响和预期解决时间的清晰信息。重新验证客户和合作伙伴联系信息可以防止在沟通中出现昂贵的延迟。
注意：安全软件部署过程应在更大的事件响应计划（IRP）中引用。将部署过程纳入事件响应计划，允许从部署管理到事件处理的平稳过渡。它还有助于确保所有相关利益相关者——开发人员、运营团队、安全人员、外部沟通和客户服务——都对齐并装备好，以最小化停机时间，解决安全漏洞，并保持业务连续性。
客户通知计划
即使有安全软件部署过程，事件仍可能发生。为了保持透明度和信任，软件制造商应该有一个结构化的客户通知计划。通知计划中应考虑的元素包括：
1. 部署前通知：在任何重大更新之前，通知客户即将到来的部署，包括预期的时间线、潜在影响和任何计划的停机时间。注意：此元素需要校准，以避免警报疲劳。
2. 支持客户控制的部署：允许客户控制部署时间表和如何接收更新。
3. 推出状态更新：在部署过程中，通过适当渠道（如一个众所周知且持续更新的公共网络门户）提供实时或频繁的推出状态更新。
4. 事件和中断报告：如果在部署期间出现问题，请迅速通知客户事件的本质、对其系统的影响以及正在采取的解决措施。
5. 部署后通知：部署完成后，发送后续通信以确认成功推出。包括新功能、错误修复或更改的详细信息，并提供客户报告任何部署后问题的渠道。
额外的考虑：N-1版本
一些客户更喜欢留在旧版本的软件或配置上——通常称为N-1（上一个版本）或N-2（两个版本前）——以避免与新更新相关的潜在风险。这些风险可能包括错误、兼容性问题或可能影响他们的系统或运营的干扰。
然而，尽管留在旧版本上可能看起来更安全，但延迟更新可能会引入未管理的风险，特别是当更新包括关键安全增强或漏洞补丁时。软件制造商应专注于改进他们的部署实践并证明他们的可靠性给客户。与其放慢部署速度，软件制造领导者应优先考虑增强部署流程，以确保安全性和稳定性。
结论
功能安全和安全事件通常是由多种 contributing factors 导致的，包括人员、流程和技术元素在可能变得不对齐的系统中共同作用（有时以意想不到和不太可能的方式）。安全软件部署过程应与组织的SDLC、质量程序、风险承受能力和对客户环境和运营的understanding 集成。通过采用系统思维方法，团队可以减少他们的部署过程在 safety boundary 之外运行的可能性。
两种方法可以帮助团队保持这个安全边界。首先，培养无责回顾（也称为“事后分析”）文化，团队通过专注于导致结果的流程来分析正面和负面结果，而不是将责任归咎于任何个人。如果环境和流程具有弹性，个人行动不应该导致事件。
其次，将“近乎失误”视为真实事件。“近乎失误”提供了显著的信息来改进流程。它们提供了一个在不承受实际事件后果的情况下发展程序的机会。分析“近乎失误”允许团队发现系统中的弱点并主动解决它们，减少未来故障的可能性。通过研究这些事件，组织可以建立一个持续改进的文化，加强安全性和运营弹性。
组织应正式评估他们的软件部署过程，根据本文概述的要点，并制定计划通过持续改进程序来解决它们。一个设计良好的软件部署过程可以确保客户及时收到新功能、安全性和可靠性，同时将未计划的停机时间最小化。
END
