- 在软件生命周期的各个阶段融入安全性，可以避免瓶颈，并降低修复漏洞的成本。
- DevSecOps 和以开发者为中心的安全机制将工具和控制措施更紧密地融入到开发工作流程本身。
- OWASP SAMM 和 NIST SSDF 等框架指导采用结构化实践来实现安全的软件开发生命周期。
- 培训、持续测试和自动化相结合，可以创造出更能抵御网络攻击的软件。
软件安全不再是项目后期可有可无的附加功能，而是从最初应用程序设计阶段就不可或缺的关键组成部分。在代码每天多次部署、网络攻击日益复杂的今天，继续依赖最后一刻的人工审查无异于自取灭亡。
将安全性贯穿整个开发生命周期（从最初的概念到生产维护）是DevSecOps、以开发者为中心的安全以及OWASP SAMM或NIST SSDF等框架中的安全SDLC模型等方法的基础。目标说起来简单，做起来却很复杂：在设计之初就创建安全的软件，同时又不影响业务敏捷性，并防止安全成为瓶颈。
软件开发中的安全是什么？为什么它如此重要？
当我们谈论软件开发安全时，我们指的是为确保应用程序能够抵御攻击、维护数据完整性并在整个生命周期内保持服务可用性而应用的所有实践、工具和流程。这不仅仅是“设置防火墙”或使用加密，而是要以一种能够降低安全漏洞发生概率的方式来设计和编写软件。
恶意软件攻击和软件漏洞会危及身份验证、授权、完整性和机密性。如果在设计阶段就解决这些威胁，许多问题可以在生产环境中出现之前得到缓解，从而避免紧急补丁和数据泄露。
其核心理念是，所有软件在交付用户之前都应该经过安全测试，而且这些测试不应仅仅是孤立的“筛选”，而应成为每个版本发布的常规环节。这样一来，软件的弹性就更强，无需在发现漏洞后不断叠加额外的安全措施。
最终目标是实现“安全设计”应用程序，将控制措施融入其架构，频繁进行自动化测试，并营造一种开发人员、安全人员和运维人员协同工作的文化。这需要整个技术团队的共同努力，而不仅仅是一小群网络安全专家。
DevSecOps 和以开发者为中心的安全性
DevSecOps的出现是为了解决一个非常具体的问题：传统的安全团队只在开发周期的最后阶段才加入的模式，已经无法适应频繁发布、敏捷方法和 CI/CD 流水线。过去，应用程序每年更新一到两次即可进行彻底的审查；而现在，随着持续部署的普及，这种方法已成为一个无法接受的障碍。
DevSecOps 提倡将安全无缝集成到敏捷开发和 DevOps 流程中，从而从一开始就持续关注应用程序和基础设施的安全。其理念是在漏洞出现之初就进行检测和修复，此时修复成本较低，而不是在部署前不久才发现漏洞。
此外，DevSecOps提倡将安全视为一项共同责任：开发、运维和安全部门紧密协作，而不是各自为政，仅在最后阶段才进行沟通。这种方法的宗旨通常概括为“软件，更安全，更快捷”：通过自动化控制和减少开发生命周期中的摩擦，更快、更安全地交付软件。
这一理念的关键支柱是以开发者为中心的安全。安全团队不再像以往那样在流程末端扮演“警察”的角色，而是将安全工具更贴近开发者的工作环境，例如，将扫描器集成到集成开发环境（IDE）或版本控制系统中。这样一来，部分分析、测试和补丁工作就可以直接由开发者在键盘前完成。
这种“将安全更贴近代码”的方法使得漏洞几乎可以在编写之初就被发现和修复，无需等待定期审计或大规模渗透测试。因此，开发团队不再将安全视为拖慢工作进度的麻烦事，而是将其视为核心质量标准。
安全性已融入软件开发生命周期的每个阶段。
要真正有效保障安全，必须将其融入开发生命周期 (SDLC) 的所有阶段，而不是仅仅作为最后的“质量检查”。如果仅仅在项目收尾阶段才考虑安全问题，会给安全团队造成瓶颈，尤其是在他们不可能精通当今所有技术和云环境的情况下。
现代方法提倡将安全“融入”整个软件开发生命周期：从需求定义、规划设计到实施、测试、部署和维护。整个组织都认同安全是产品成功的关键组成部分，而不是可以推迟的独立事项。
过去，安全审查主要依靠人工测试，每个应用程序或服务都使用独立的工具，将抽查扫描和渗透测试相结合。如今，工具的设计更加注重集成和自动化：它们可以连接到持续集成/持续交付 (CI/CD) 流水线、事件跟踪系统和代码库，从而实现更加流畅的工作流程。
漏洞扫描器已集成到持续集成流程中，因此每次代码更改在进入下一阶段之前都会自动进行分析。同时，分析结果会作为常规任务记录下来，供整个团队查看，从而更容易确定优先级、跟踪问题并衡量解决时间。
这一切都意味着安全不再是事后考虑的问题，而是成为软件开发生命周期（SDLC）的结构性组成部分。组织不再仅仅在部署前“通过安全检查”，而是假定每一次提交、每一次合并和每一次交付都是持续安全检查链的一部分。
常见的软件安全实践
在这种工作方式下，许多组织已经实施或正在开始采用一系列软件安全举措。以下并非完整清单，但有助于我们了解应将哪些活动整合到软件开发生命周期 (SDLC) 中以加强安全性。
关键的第一步是静态代码分析(SAST)。这涉及分析源代码（包括基础设施即代码），以检测不安全的编程模式或已知漏洞。它通常是一个自动化过程，可以在每次提交或推送时运行，从而为开发人员提供近乎实时的反馈。
另一方面，动态安全分析（DAST 及类似方法）会在应用程序运行时对其整个应用程序及其底层基础架构进行评估。这包括端口扫描、跨站脚本攻击测试、容器配置审查以及面向互联网的服务分析，以识别仅在系统运行时才可见的漏洞。
除了自动化工具之外，人工代码审查仍然至关重要。虽然许多功能已经过逻辑错误审查，但将安全视角融入这些代码审查，可以发现扫描器可能遗漏的不太明显的漏洞。然而，这确实要求团队接受一些关于攻击模式和最佳实践的培训。
渗透测试更进一步：它会聘请专家扮演攻击者，尝试入侵基础设施或应用程序。他们可以使用从自动化分析到实际漏洞利用的各种方法，最终通常会生成一份报告，详细列出标准测试遗漏的漏洞，并提出具体的缓解建议。
漏洞赏金计划是一种相关但不同的方法。这种模式鼓励研究人员和高级用户报告漏洞，并给予经济奖励或表彰。它能有效地引导第三方发现，并将潜在的攻击者转化为合作者。
最后，我们绝不能忽视对技术人员的安全培训。威胁形势瞬息万变：十年前行之有效的方法，如今可能已不再适用。让开发人员及时了解 OWASP Top 10、新兴攻击和安全设计模式，能够大大降低人为错误的风险，而人为错误仍然是造成安全漏洞的主要原因之一。
安全软件开发生命周期（安全 SDLC）
将安全性融入软件开发生命周期（SDLC）并非在最后增加一个“额外阶段”，而是将安全实践和控制措施融入现有阶段。这能创建一个可持续的流程，在不干扰团队协作的情况下创造真正的价值。一个安全的软件开发生命周期通常包含以下阶段：
需求阶段明确定义了待解决的问题和所需的安全级别。此时需要将安全事件、新功能请求和已知漏洞转化为具体的项目，并评估其对整体风险的影响。让安全团队参与到这个阶段有助于有效地确定优先级，并了解每项变更的影响。
接下来是规划阶段，在此阶段需要决定构建哪些内容以及如何实现。安全部门也必须参与此阶段，以确保计划的解决方案不会引入新的攻击途径，并且业务目标与数据保护、合规性和弹性要求相一致。
解决方案设计阶段的重点在于架构：哪些系统需要交互，创建哪些服务，它们之间如何关联，以及建立哪些数据流。应与安全团队一起审查架构图，以识别信任边界、入口点、身份验证机制、加密等方面的潜在漏洞。在这些早期阶段保持顺畅的沟通，可以避免在程序编写完成后才发现严重问题。
接下来是实现阶段，即将设计转化为代码。此时，诸如每次提交时进行静态分析、将安全规则集成到持续集成 (CI) 流水线中以及开展以安全性为重点的代码审查等实践就显得至关重要。代码中的缺陷发现得越早，修复成本就越低。
代码编写完成后，便进入测试和部署阶段。除了功能测试之外，建议在此阶段加入更全面的安全分析：例如 DAST 扫描、关键功能的手动安全测试，以及在资源允许的情况下，针对重大变更进行渗透测试。此阶段的测试结果应用于调整自动化工具，以防止安全回归。
部署完成后，预防性维护随即开始。即使软件发布到生产环境时“没有已知漏洞”，环境和威胁也会发生变化：新的 CVE 出现、依赖项缺陷被发现、法律法规要求变更等等。维护阶段包括监控新漏洞、更新组件、审查安全日志以及响应安全事件。
整个过程是一个循环：发现的每一个新缺陷、改进或漏洞都会反馈到需求阶段。因此，安全的软件开发生命周期是一个持续改进的循环，而非线性路径。这种理念有助于团队在每次迭代中完善控制措施和工具，而不是在部署后认为“一切都完成了”。
参考框架：OWASP SAMM 和 NIST SSDF
对于希望更进一步的组织而言，借鉴成熟的成熟度模型和安全开发框架非常有益。其中两个最相关的模型是 OWASP SAMM 模型和 NIST SSDF 框架，它们为将安全性集成到开发流程中提供了切实可行的指导。
OWASP软件保障成熟度模型 (SAMM)是 OWASP 先前 CLASP 的演进版本。它提出了一系列按领域（例如治理、构建、验证和部署）组织的安全实践，并划分了不同的成熟度级别。其理念是，每个组织都应根据自身的风险状况调整这些实践，而不是试图应用一套僵化的控制措施。
美国国家标准与技术研究院(NIST) 安全软件开发框架 (SSDF)基于多个专家组织的建议，概述了基本的安全开发实践。它将安全软件开发生命周期 (SDLC) 分为四个主要部分：组织准备、软件安全、安全软件开发和漏洞响应。每个部分都包含可以逐步实施的具体活动。
“组织准备”是指让人员、流程和技术做好准备，使安全开发成为企业层面和每个团队内部的普遍实践。“软件保护”涵盖防止未经授权篡改代码、构建工件和供应链的措施。
“生产安全软件”模块侧重于最大限度地减少每个版本中的漏洞，并将静态分析、依赖关系审查、容器扫描和类似控制措施集成到日常运维中。“漏洞响应”模块则指的是识别被忽略的缺陷，快速修复它们，并调整流程以防止缺陷再次发生。
培训、威胁建模和安全文化
要实现这一切，仅仅安装工具是不够的；还需要在团队内部建立一种共享的安全文化。这意味着开发人员必须明白，保护应用程序是他们工作的一部分，安全团队必须融入到日常运营中，而不仅仅是在发生安全事件时才介入。
专门的培训是一个很好的起点。赋予开发人员识别漏洞和编写更安全代码的能力，可以显著减少基本错误的发生。像 OWASP Top 10 这样的资源有助于识别 Web 应用程序中最常见的弱点，并了解攻击者的思维方式。
威胁建模是另一项影响深远的实践。它涉及从攻击者的角度分析应用程序（或新功能）：哪些资产需要保护、存在哪些输入、哪些数据流至关重要以及哪些漏洞可能被利用。基于此分析，可以设计缓解措施并将其融入技术设计本身。
如果在设计阶段进行威胁建模，就能从一开始就影响架构，从而避免出现后续需要重写的不安全解决方案。数据流图和已知的攻击模式通常用于构建分析框架，开发团队和安全团队都会参与其中。
与此同时，鼓励开发团队学习像攻击者一样思考也很重要。这并不意味着每个人都需要成为渗透测试专家，而是意味着他们要了解小漏洞如何组合成更大的攻击，凭证是如何被窃取的，或者薄弱的云配置是如何被利用的。
传统渗透测试的局限性
传统渗透测试仍然是一种很有价值的工具，但在持续部署的环境中应用时存在局限性。顾名思义，渗透测试提供的是特定时间点的安全快照：它评估的是应用程序和基础设施在当天的状态。
一旦团队部署新版本或更改配置，部分测试结果可能就会过时。如果版本发布频繁，每次更改后都进行完整的渗透测试，无论从时间还是成本上来说都难以实现。
此外，当渗透测试在开发生命周期的后期阶段进行时，发现的漏洞通常修复成本很高，往往需要应用复杂的安全更新。有时，这甚至需要修改关键组件或重写应用程序的某些部分，从而对计划、预算和团队士气造成影响。
对于拥有众多服务和应用程序的组织而言，很难对整个目录进行大规模的手动渗透测试。人们往往只优先考虑最关键的系统，而忽略了其他可能被攻击者利用的漏洞。
CI/CD管道的持续安全测试
为了适应这种快速变化，持续集成/持续交付 (CI/CD) 流水线中的持续安全测试等模型应运而生，它将全天候自动化扫描与有针对性的、一次性的手动测试相结合。其理念是从临时审计转向持续不断的漏洞检测和修复。
这种方法结合了自动扫描器（用于检查应用程序、Web 资产、API 和暴露的表面）和渗透测试专家的介入，后者会调查最复杂的发现，并寻找工具本身无法检测到的逻辑漏洞。
主要优势在于，即使 CI/CD 流水线速度非常快，团队也能快速获得关于安全问题的详细信息。这缩短了漏洞暴露窗口期，因为在受影响的代码进入（或长时间留在）生产环境之前，漏洞就能被识别并修复。
持续测试的另一个好处是，它有助于将漏洞管理与应用程序安全联系起来。定期生成的报告，清晰地列出了漏洞及其随时间演变的情况，有助于制定风险决策、确定修复优先级，并为安全改进方面的投资提供依据。
有些服务甚至在修复后提供免费的重新测试，让您可以验证解决方案是否真正有效，以及是否引入了任何回归问题。这一切都与DevSecOps的持续改进理念完美契合。
典型的 DevSecOps 组件和工具
实际上，DevSecOps 环境依赖于几个关键的技术组件。持续集成 (CI) 统一了所有开发人员的工作，并在每次集成新代码时自动运行单元测试、集成测试和安全测试。
持续交付 (CD) 通过在每个阶段按顺序验证和批准软件（包括安全检查），确保软件始终处于可部署状态。只有通过所有已定义控制的版本才能升级到更高级别的环境。
安全自动化是通过静态应用安全测试 (SAST) 和动态应用安全测试 (DAST) 工具、依赖项扫描器、基础设施即代码分析和容器审查来实现的。这些工具集成到持续集成/持续交付 (CI/CD) 流水线中，例如 Jenkins、GitLab CI 或类似系统，因此无需人工干预即可运行。
漏洞管理解决方案通常用于集中管理漏洞发现、确定风险优先级并跟踪漏洞解决情况。与此同时，密钥管理工具（例如 Vault）可以防止凭据和密钥在代码或部署配置中泄露。
最后，持续监控和审计依赖于可观测性和 SIEM 平台（例如 ELK 或 Splunk），这些平台收集日志、检测异常行为并协助进行合规性审计。这一层完善了整个闭环，从而能够检测生产事件并及时响应。
将 DevSecOps 应用于移动应用开发
谈到移动应用，DevSecOps 方法必须根据其具体特性进行调整。规划和设计阶段必须考虑特定风险：设备权限管理、安全凭证存储、通信加密以及遵守 GDPR 等法规。
在开发过程中，我们会使用适配 Kotlin、Swift 和 Java 等语言的 SAST 扫描器，并仔细审查外部依赖项和 SDK。移动应用中的许多漏洞正是源于维护不善的第三方库或权限过大的库。
在测试阶段，DAST扫描会与移动端专属测试相结合，包括中间人攻击（MITM）模拟、二进制文件完整性验证、本地存储分析以及后端API交互审查。这有助于识别应用程序及其所依赖的服务中的缺陷。
集成到 CI/CD 流水线意味着每次提交都会经过自动化安全检查，确保任何存在严重缺陷的版本都不会发布到应用商店。此外，还配置了部署后监控系统，用于检测异常行为、错误峰值或可能表明存在攻击的模式。
最后，我们制定了清晰的事件响应流程，以便在生产环境中发现严重漏洞时能够迅速发布紧急补丁。快速响应并更新应用程序的能力是维护用户信任的关键。
综合所有这些实践、框架和工具，安全不再是敏捷开发的障碍，而是助力。通过从一开始就让开发人员参与其中，每次变更都进行自动化测试，并利用 OWASP SAMM 或 NIST SSDF 等标准，企业可以创建更健壮的软件，降低漏洞修复成本，并更好地应对不断演变的威胁形势。