Security+ 学习笔记9 软件开发周期

一、软件平台

当我们评估软件的安全性时，必须在其运行的平台的背景下考虑该软件。平台承载着提供资源访问的操作系统，它是软件安全环境的一个重要组成部分。最基本的软件执行环境是一个简单的终端设备(endpoint device)。在这种情况下，一个软件程序完全在桌面或笔记本电脑系统上运行，不与任何其他系统互动。例如，如果笔记本电脑上打开计算器应用程序。

大多数商业应用程序在某种客户端/服务器(C/S) 环境中运行。在客户端/服务器系统中，终端作为客户端，运行一些与服务器上运行的其他软件进行交互的软件。Web应用是客户端/服务器计算的一个典型例子。在Web应用中，终端用户在其终端设备上运行一个网络浏览器作为客户端，该网络浏览器与世界各地的网络服务器连接，收集用户要求的信息。

移动终端(Mobile endpoints) 在许多环境中越来越普遍。而且在许多情况下，它们甚至超过了其他类型的终端设备对一些应用程序的访问。移动设备运行自己的操作系统，如iOS或Android，然后在该操作系统之上运行应用程序。这些可能是简单的终端应用，也可能使用客户/服务器模式运行。也有不少专门的终端设备，如为车辆、工业控制系统和其他物联网(IoT)应用提供动力的嵌入式设备和芯片上的系统。这些专门的设备可能将其软件应用程序存储在固件中，在那里可以快速和随时访问。

二、开发方法论(Development methodologies)

许多组织会自己在开发软件，无论是为自己的内部使用还是为客户开发产品。在软件开发过程的每个阶段都必须考虑到安全问题，并符合组织业务要求的代码。

首先需要做的是定义需求，每一个软件项目都应该从一套坚实的业务需求开始。开发人员应该与其客户携手合作，勾勒出软件的具体目的和它将实现的商业目标的细节。

在明确业务需求后，软件开发人员继续前进，将这些需求转化为技术设计。技术专家为软件开发制定路线图，并确定各组件之间的接口，以确保最终所有的东西都能正确地结合在一起。软件开发是一个复杂的工程的过程，其复杂程度不亚于一个大型建筑项目。软件工程师如果在没有仔细定义需求的情况下开始开发过程，就像建筑工人在没有一套蓝图的情况下开始建造房屋。完成的产品不可能符合客户的要求，而且很有可能会崩溃。根据他们组织的方法和具体项目的细节，软件工程师可以选择几种不同的软件开发方法中的一种：

1. 软件开发的经典方法是一种被称为**瀑布法(Waterfall approach)**的方法，它将软件开发作为一个非常线性(very linear)的过程，并遵循一系列相当严格的步骤。他们从开发系统需求开始，接着开发软件需求，然后根据这些需求产生一个初步设计，作为详细设计的基础。一旦设计完成，开发人员就开始编码和调试过程，在这个过程中他们创建软件。当他们完成编码后，对软件进行严格的测试，如果通过了这些测试，就进入运营和维护模式。这种方法确实允许回到早期的步骤，但每次只允许一个阶段。例如，如果软件在测试过程中失败，它就会回到编码和调试阶段，然后再提交给其他测试。这个过程是非常僵化的，它不允许在开发过程中对软件进行许多改变。例如，如果一个业务部门在编码过程中发现了一个理想的新功能，就没有机会修改设计。正因为如此，现代的软件开发基本没有使用瀑布模型。

   

2. 在20世纪80年代，螺旋模型(spiral motion) 被提出，这种软件开发方法为了减轻与瀑布模型相关的一些缺点。这是一个迭代(iterarive) 的过程，并分为有四个阶段。在第一阶段，开发人员确定目标、备选方案和约束条件。然后，他们开始评估替代方案，识别和解决风险。完成后，进行开发和测试产品，然后开始为未来的开发工作进行规划阶段。虽然这听起来与瀑布模型相似，但主要的区别在于，开发人员是按照螺旋式的运动方式，以迭代的方式完成这些阶段。他们从第一阶段开始，多次通过每个阶段，直到他们有一个满意的成品。

   

3. 目前，世界各地的开发人员已经开始接受敏捷的软件开发方法(Agile software approach)。这种方法的价值迅速转移到软件的创造上，而且相当流行。敏捷的软件开发方法有四个价值声明。他们重视个人和互动，而不是过程和工具；他们重视工作中的软件，而不是全面的文件；他们重视客户合作，而不是合同谈判；他们重视对变化的反应，而不是遵循一个计划。其中的5个规则：Rule1:适应性原则。 Keep Relevant-时刻保持与背景“复杂系统”的关联，适应“复杂系统”的变化；Rule2: 灵活性原则。 Always be optional-拥有多重选项，根据环境的变化进行灵活选择；Rule3: 利用系统的“原力”——Leverage the Gravity。人的力量毕竟微弱，需要充分挖掘“复杂系统”自有的力量并加以利用；Rule4: 模式识别——Patterns Recognition。识别“复杂系统”中所呈现出的“模式”，基于“模式”，逐步理解“复杂系统”。Rule5: “自下而上”原则（Bottom-up）。由于“复杂系统”的未知性和不确定性，在缺乏必要信息的情况下，无法通过“自上而下”（Top-down）的方式来理解系统。因此，从基本的“模式”出发，并在过程中学习和认知，不断地向上发展更高层的“模式”，才能最终实现对“复杂系统”的全面认知。

每个组织都需要考虑到他们可用的不同的软件开发方法，并选择最适合他们情况和需求的方法。

三、成熟度模型(Maturity models)

成熟度模型为公司提供了一种方法，使其能够根据标准基准对自己进行评估，并确定在发展其软件开发实践方面的下一步行动。能力成熟度模型集成(The Capability Maturity Model Integration)，或称CMMI，以帮助组织确定他们在成熟过程中的位置。

CMMI由五个不同的级别组成。初始(Initial)、管理(Managed)、定义(Defined)、定量管理(Quantitatively)和优化(Optimizing)。

当前版本的CMMI可以软件开发，但现在也被用于产品开发、供应链管理、收购和服务交付。

1. 当一个组织处于第一级时，即初始阶段，他们刚刚开始正式的开发实践。他们完成了他们的工作，但工作通常会出现延误和预算超支。
2. 一个组织发展的下一步是进入第二层次，即管理阶段。在这个阶段，他们开始了一些基本的过程，如在项目之间重复使用代码。在这个阶段开始的一些关键活动包括配置管理、测量和分析、项目监测和控制、项目规划、过程和产品质量保证、需求管理和供应商协议管理。
3. 第三级组织存在于定义阶段。他们在许多过程领域都有正式记录的实践。这一层次的活动包括决策分析和决议、综合项目管理、组织过程定义、组织培训和组织过程重点、产品集成、需求开发、风险管理、技术解决方案、验证和确认。
4. 第四层次的组织是定量管理的。他们使用量化的措施来评估他们的进展，了解自己开发实践的有效性。这个阶段的活动包括组织流程绩效和量化项目管理。
5. 最后，第五级组织是在优化阶段。他们使用持续的过程改进来争取永远做得更好。来自项目的反馈流回开发过程，使组织在每个新项目中都能得到改善。这里的实践包括因果分析和解决以及组织绩效管理。

CMMI只是评估一个组织的软件开发实践的一种方法。还有其他可用的方法。例如，IDEAL模型也有五个阶段。启动(Initiating)、诊断(Diagnosing)、建立(Establishing)、行动(Action)和学习(Learning)。 它更注重于一个组织为改进自己所遵循的过程。

无论选择使用什么成熟度模型，该模型都可以作为继续改进你的软件开发实践的指南，更好的软件开发实践会带来更好的安全性。

四、变革管理(Change management）

一旦软件被开发出来，它就进入了运营和维护阶段。在这个阶段，组织应该遵循标准的变更管理流程，力求避免不必要的中断，并控制新代码应用到生产环境。软件是永远不会完成的。一旦开发过程结束，组织仍然要负责维护和操作该代码，直到它最终退役。如果软件是为内部开发的，开发人员和运营专家很可能会有内部客户，他们会要求对代码进行错误修复、功能增强以及其他必须管理的变化。如果软件是卖给客户的，他们的要求会更高，会打电话来请求支持。组织必须制定流程来处理这些需求。

组织制定的最重要的流程之一是变更管理方法，以确保任何代码变更都能在适当的测试和批准下有序地进行。变更管理计划应包括三个关键要素，请求控制(request control)、变更控制(change control)和发布控制(release control)*。

1. 请求控制过程允许客户请求修改目前部署的软件。管理人员接收并评估客户的请求，估计实施这些请求的成本和效益，然后对开发人员的工作进行优先排序。在一个典型的请求控制过程中，许多请求从未被实施，因为它们没有被优先考虑，无法使用有限的资源。
2. 当开发人员修改完了代码，他们通过变更控制流程进行修改。无论是开发者还是经理，都会写一份变更请求（RFC）文件，解释预期的变更，然后他们将该变更提交给组织的变更咨询委员会审查。当变更被批准后，开发者就有权限对代码进行修改。这可以确保组织在进行修改之前了解修改的影响，同时也提供了一个修改文件的来源。
3. 在开发人员写完新的代码后，他们将其放入发布管理流程。在发布管理过程中，质量保证团队对代码进行测试，并验证它是否符合要求，是否在实施RFC中描述的变化。在得到质量保证的批准后，发布经理将代码转移到生产中。通常情况下，开发人员实际上没有更新生产代码的权限。这可以确保他们只通过认可的发布管理流程发布代码变更。当代码在变更管理过程中前进时，它也在一系列不同的操作环境中转移。

   

   这些环境为开发人员提供了不同的空间，使他们能够在不影响其他用户的情况下对代码进行操作。当开发者创建和修改代码时，他们在一个开发环境中工作。当他们准备好进行代码测试时，发布管理流程会将该代码转移到测试环境中。一旦测试完成并成功，发布管理就会把代码从测试环境移到准备用于生产的暂存环境中。最后，当发布管理流程批准代码用于生产时，它就会从暂存环境转移到生产环境中供一般使用。

五、自动化与DevOps

DevOps，试图将过去经常发现自己有冲突的两个世界结合起来。软件开发人员负责创建代码，建立应用程序和集成，以满足客户和企业的需求。他们被激励着快速发布代码并满足这些客户的需求。IT运营人员负责维护基础设施并保持企业的稳定。他们经常对变化保持警惕，因为变化带来不稳定的可能性。这使得他们在开发人员寻求快速部署新代码时感到紧张。

DevOps试图将这两个方向结合起来，世界各地的IT组织正在迅速接受DevOps理念，以改善软件开发人员和技术运营团队之间的关系。DevOps寻求在开发人员和操作人员之间建立开放的沟通协作关系。DevOps运动拥抱自动化，将其作为开发和运营的助推器。而且，DevOps从业者寻求创造一个环境，让开发者可以快速发布新代码，而运营人员可以为这些代码提供一个稳定的操作环境。DevOps理念经常与敏捷软件开发方法联系在一起。虽然它们是两个不同的概念，但DevOps和Agile之间有着深刻的联系。遵循这些策略的开发者，寻求实施持续集成的软件开发方法，他们可以快速发布软件更新，每天创建多个软件版本，有时甚至在一天内发布数百个更新。云计算是DevOps环境的受益技术之一。具体来说，DevOps给我们带来了一个称为基础设施即代码(IaC) 的概念。

在这种方法中，运营团队不再通过登录和直接修改配置来手动配置服务器和其他基础设施组件。相反，他们编写脚本，指定如何从基线(baseline)配置镜像开始，然后定制该基线以满足特定情况的要求。例如，一个组织可能有一个Linux系统的标准基线。当有人需要一个新的Linux系统时，他们写一个脚本，用基线配置启动服务器实例，然后脚本自动配置该实例以满足服务器请求的具体功能需要。IaC将服务器配置与特定的物理或虚拟服务器分开。这对组织有一些明显的优势：

1. 它实现了可扩展性。如果组织需要更多的服务器，代码可以极其迅速地创建所需的数量；
2. 通过使用不可变的服务器，它减少了用户的错误。这意味着工程师永远不会直接登录或修改服务器。如果他们需要做出改变，他们会修改代码，然后用这些代码来创建新的服务器；
3. 这种方法使测试变得容易。开发人员可以为新的服务器编写代码，并在不影响生产的情况下建立一个功能齐全的测试环境。一旦他们验证了新的代码可以正常工作，他们就可以将其转移到生产中，并销毁旧的服务器。

DevOps工具集涉及一系列提供自动化行动方案的工具。它们包括在开发人员更新代码时立即执行软件测试的持续验证(continuous validation)，保持不同代码元素之间联系的持续集成(continuous integration)，自动将代码移入适当环境的持续交付(continuous delivery)，自动发布代码供生产使用的持续部署(continuous deployment)，以及确保代码正常工作的持续监控(continuous monitoring) 工具，并在出现问题时触发自动补救措施。

DevOps方法为组织提供了许多不同的好处。安全团队也可以通过使用安全自动化技术从这种方法中获益。网络安全团队没有理由不接受DevOps理念，并使用基础设施即代码的方法建立安全基础设施和分析工具。当DevOps整合网络安全时，它通常被称为DevSecOps，并引入了安全即代码的网络安全方法。DevOps工具集涉及一系列提供自动行动方案的工具。

参考资料来源：

https://www.linkedin.com/learning/paths/become-a-comptia-security-plus-certified-security-professional-sy0-601

https://www.zhihu.com/question/23429937