前言
The concept of integrating security into the software development process is not new. While I cannot definitively assert that Microsoft was the pioneer of this concept, the Secure Development Lifecycle (SDL) published by Microsoft in 2002 undoubtedly laid the foundation for what is now commonly known as a Secure Software Development Lifecycle (Secure SDLC or SSDLC).
将安全性融入软件开发过程并非新概念。虽然我不能断言微软是这一概念的先驱，但微软在 2002 年发布的安全开发生命周期（SDL）无疑为现在通常所说的安全软件开发生命周期（Secure SDLC 或 SSDLC）奠定了基础。
Even today, over 20 years later, Microsoft’s SDL can still be useful for illustrating the general concept of an SSDLC. However, it may not be the optimal choice as a blueprint for implementing software security in today’s practical scenarios. Without delving into extensive details here, it’s worth noting that our comprehension of software development and security has naturally progressed over the past two decades.
即使在 20 多年后的今天，微软的 SDL 对于说明 SSDLC 的一般概念仍然有用。不过，在当今的实际应用中，它可能并不是实施软件安全的最佳蓝图。在此，我们无需深入探讨大量细节，但值得注意的是，在过去二十年中，我们对软件开发和安全的理解自然也在不断进步。
Development has become more complex, agile, and the boundaries between development, operations, and security have blurred significantly. What we require now is a more comprehensive understanding of software security that encompasses all relevant aspects, extending beyond just the development process, and encompasses aspects like training and incident response. I’d like to refer to this approach as Secure Software Lifecycle Management (SSLM).
开发变得更加复杂和敏捷，开发、运营和安全之间的界限也变得非常模糊。我们现在需要的是对软件安全有一个更全面的理解，它包含所有相关方面，不仅仅是开发过程，还包括培训和事件响应等方面。我想把这种方法称为安全软件生命周期管理（SSLM）
一、现代理念
Although this term seems not to be widely used yet, we find the idea behind it implemented by many of today’s secure software development frameworks. For instance, SafeCodes Fundamental Practices for Secure Software Development from 2018, the BSA Framework from 2020, the NIST SSDF from 2021, and OWASP SAMM from 2020.
I recently came across another interesting concept that is absolutely worth mentioning in this context. In their book Agile Secure Software Lifecycle Management by Barry Derksen and others from the Secure Software Alliance, the authors describe their version of a modern secure software lifecycle management in the following way:
尽管这一术语似乎尚未被广泛使用，但我们发现，当今许多安全软件开发框架都在贯彻这一术语背后的理念。例如，2018 年的《SafeCodes 安全软件开发基本实践》、2020 年的《BSA 框架》、2021 年的《NIST SSDF》和 2020 年的《OWASP SAMM》。
最近还发现了另一个有趣的概念，在这方面绝对值得一提。在安全软件联盟 Barry Derksen 等人所著的《敏捷安全软件生命周期管理》一书中，作者用以下方式描述了他们版本的现代安全软件生命周期管理：
I think this is a great example of such a lifecycle for a particular application or product, starting with the initial project kickoff and ending with its operational servicing time which shows a lot of understanding of the practice to me. However, this is, of course, not really a framework but an example implementation like Microsoft SDL. Also, what I miss a bit are practices like AppSec architecture & governance that are not part of the development process or lifecycle itself.
这是一个很好的例子，说明了特定应用程序或产品的生命周期，从最初的项目启动开始，到其运行服务时间结束，这在我看来显示了对实践的理解。当然，这并不是一个真正的框架，而是一个类似于微软 SDL 的实施范例。此外，还有点怀念那些不属于开发流程或生命周期本身的应用安全架构和治理等实践。
二、安全的软件生命周期管理
After some reflection, I came up with the following holistic view of how a Secure Software Lifecycle Management could look like and which works with all kinds of development methodologies, including DevOps. It even includes one important aspect that I often came across: Companies can actually have multiple Secure SDLC processes – e.g. one for modern development and one for SAP development.
得出了以下关于安全软件生命周期管理的整体观点，它可以与包括 DevOps 在内的各种开发方法一起使用。它甚至包括我经常遇到的一个重要方面：公司实际上可以有多个安全 SDLC 流程，例如一个用于现代开发，一个用于 SAP 开发。
It’s important to understand that the underlying concept here is not about establishing a new standard or similar measures. Naturally, not everyone would (or should) be required to implement all these practices. However, this visualization can be valuable for identifying relevant practices and especially crucial areas that may have been overlooked.
Addressing AppSec in governance and, particularly, central AppSec architecture are two such areas that often receive insufficient attention. Especially in a landscape dominated by DevOps, where releases are frequently brief and development teams are granted increasing autonomy, establishing a robust AppSec architecture becomes vital. This can be achieved through reference architectures, blueprints, and guardrails, providing dev teams the flexibility to make their own decisions.
Since not every organization builds and operates software in the same manner, there can’t be a universal standard applicable to everyone. Here are some important aspects that distinguish what parts of an SSLM you may consider implementing and how to do that:
重要的是要明白，这里的基本概念并不是要制定新的标准或类似措施。当然，并不是每个人都会（或应该）被要求实施所有这些做法。不过，这种可视化方法对于识别相关实践，尤其是可能被忽视的关键领域，还是很有价值的。
在治理中解决 AppSec 问题，尤其是中央 AppSec 架构，就是这样两个经常得不到足够重视的领域。特别是在以 DevOps 为主导的环境中，发布时间经常很短，开发团队被赋予越来越多的自主权，因此建立一个强大的 AppSec 架构变得至关重要。这可以通过参考架构、蓝图和护栏来实现，为开发团队提供自主决策的灵活性。
由于并非每个组织都以相同的方式构建和运行软件，因此不可能有一个适用于所有人的通用标准。以下是一些重要的方面，可以区分 SSLM 的哪些部分可以考虑实施，以及如何实施：
- 工程思维：企业、机构或混合
- 开发模式：自主开发、由提供商开发或作为提供商开发
- 运营模式：自己运营、由供应商运营、由客户运营
- 安全风险和风险偏好。
- 范围
可以根据企业的独特情况为其量身定制 SSLM 实施方案。这种灵活性解释了为什么该领域有众多不同的实施方案。
总结
When aiming to enhance AppSec across an entire organization, we must consider more than just the development process. Software security extends beyond the shift-left paradigm; we need to integrate security comprehensively. This is particularly crucial in the era of Dev(Sec)Ops, where the distinctions between development, operations, and security are becoming increasingly blurred.
Given the unique nature of each organization, there cannot be a one-size-fits-all set of practices. The concept behind SSLM is to promote a more holistic perspective on AppSec and assist organizations in identifying gaps and controls that may be missing
当我们要在整个组织内加强 AppSec 时，我们必须考虑的不仅仅是开发流程。软件安全超越了左移模式；我们需要全面整合安全。这一点在 Dev(Sec)Ops 时代尤为重要，因为在这个时代，开发、运营和安全之间的界限正变得越来越模糊。
鉴于每个组织的独特性，不可能有一套放之四海而皆准的做法。SSLM 背后的理念是促进从更全面的角度看待 AppSec，并帮助企业找出可能缺失的差距和控制措施。
When aiming to enhance AppSec across an entire organization, we must consider more than just the development process. Software security extends beyond the shift-left paradigm; we need to integrate security comprehensively. This is particularly crucial in the era of Dev(Sec)Ops, where the distinctions between development, operations, and security are becoming increasingly blurred.
Given the unique nature of each organization, there cannot be a one-size-fits-all set of practices. The concept behind SSLM is to promote a more holistic perspective on AppSec and assist organizations in identifying gaps and controls that may be missing