搜索引擎里输入“安全开发”，结果页面里是长篇累牍的建议和最佳实践。你可以相对快速地创建长长的最佳实践和指南清单，内容事无巨细，涵盖从怎样建立威胁模型，到避免跨站脚本错误的注意事项等等。新一点的文章可能聚焦移动应用安全开发，或关注在 DevOps 环境中有效应用安全开发，因为我们构建代码的方式已经随时间推移而发生了改变。

然而，创建安全代码的理论车载斗量，真正实现安全开发的企业却寥寥无几，很多公司都苦于难以实际运用安全开发。

事实上，微软强制推行其安全开发生命周期 (SDL) 也就 15 年多点的时间，从 2004 年夏天开始的。此前两年，现在广为人知的可信计算 (Trustworthy Computing) 推出，微软开始在安全软件开发上投入空前资源。但 2004 年是特别重要的一个时间节点，蕴藏着长篇累牍的指南和最佳实践中往往会漏掉的一课，同时也是 SDL 在快速变迁的技术思潮中保持长青的关键一课——SDL 全是关于开发人员的。我们很快就发现，如果不考虑软件开发的实际进行方式，或者不关注开发人员须怎样才能成功，那么软件开发实践注定失败。

我们必须先理解开发过程，然后界定出该过程中安全应如何操作。SDL 旨在支持开发人员构建更安全的软件，进而令产品更安全，让终端用户更满意。

我们发现 SDL 方法真的有效。15 年过后，尽管技术使用方法和软件构建方式都发生了很大变化，SDL 依然在很多全球软件巨头企业中充当软件安全项目的基石，其采纳并没有减缓的迹象。当然，多年前微软设置的原始参数是做了些修改。但这正是 SDL 的魅力所在：专注进化。

过去 15 年来发生在 SDL 身上的三大变化可总结为：

• 多样性
• 速度
• 供应链

最初，微软构建的 SDL 针对使用 C、C++ 和 C# 编程语言进行的软件开发。如今，公司企业可能使用 10～15 种语言，增加了 SDL 团队的工作量和工作复杂度。（但并没有给开发人员带来麻烦，他们就用自己在用的语言，且只需要用该语言编写安全代码就行。）所以，随时间推移，语言越来越多样。

速度是 SDL 发生重大变化的另一个领域。SDL 很适应敏捷方法或 DevOps，但一开始也遭到了开发人员的一些抵制。正是这些反馈，通过专注安全开发工具集成，尽可能地自动化验证，以及确定某些要求可以发布后实现，帮助改善了 SDL 的功能。及时产出安全的产品依旧是 SDL 给开发过程带来的最主要好处之一。

供应链是经历了重大变化的第三个领域。鉴于使用“第三方代码”——尤其是开源软件，几乎成为当今标准操作，供应链或许是变化最大的领域。“第三方代码”的使用给 SDL 过程又加了一层。使用“第三方代码”时，公司里最好有人负责列清单、设置验收与使用标准，并用系统检测这些公司外部创建的代码中可能存在的安全问题。最重要的是，准备好在有需要的时候响应问题。

下面五条经验习自 15 年来实现和管理 SDL 环境所得：

1. 开发人员想做正确的事

开发人员自豪于自己的公司、产品和工作，知道安全很重要。SDL 直击开发人员需求，只要正确实现，便可帮助开发人员达成目标。

2. 安全必须融入软件开发过程，而不仅仅是在产品完成后才测试

SDL “产品完成即安全完成”的文化是发售安全代码的唯一途径，可帮助避免业务目标与安全产生冲突。

3. SDL 是 SDL 团队建议的产品团队活动

产品团队必须信任 SDL 团队，充分理解安全的重要性，才可以使 SDL 的种种好处在公司里落地开花。文化很重要。

4. 持续改进是 SDL 成功的中心

新型漏洞自然能让你去更新工具和/或过程。

5. 培训很好，但工具更好，因为人会忘记，但代码不会

SDL 生来就是和安全工具协同工作的。专注开发人员并不意味着保持手动操作，公司企业反而应经常考虑技术和自动化可怎样支持开发人员实现他们的安全目标。

对在软件安全领域工作过一段时间的人而言，以上这些都不是什么惊天动地的东西。最终，无非就是赋权开发人员。但或许是因为我们大多数人内心都是工程师或技师，有时候我们会失去焦点，拘泥于操作和工具，然后开始将 SDL 当成检查清单而非一个过程。所以，时不时地，有必要后退一步，记起我们的起点和一路走来所学到的东西，确保始终铭记 SDL 所有的一切都是关于开发人员的。

可查看 SAFCode 最近的 Security Champions 论文，获悉更多关于软件安全中“人”这一方面的知识。

SAFCode Security Champions 论文：

Publications

相关阅读

28款DevSecOps工具助力安全开发