好问题。
首先，您引用的“最低”是指微软的最低要求政策，不一定是“行业最佳实践”最低。并不是说我说错了，但 MS-SDL 本身确实继续说他们的 SDL 不一定适合微软以外的任何组织......事实上，像 Michael Howard 这样的 MS-SDL 架构师经常——引述说：

不要做我们所做的，做我们所做的。

也就是说，与其说是文件中具体出现的规定要求（尽管它们可能大多非常好），而是他们反复进行研究，包括基于风险的分析、历史指标比较、趋势分析、根原因分析，在不同团队中进行试验以查看“需要”什么等。

没有定义明确、简单的 SDL，您只需下载安装即可确保安全。MS 的这一点是正确的——您确实需要根据您的特定组织、您的团队、他们的熟练程度、他们正在构建的产品类型、当前的开发过程、风险状况等来定制您的 SDL。并且这确实是“尝试”的最佳解决方案......

此外，SDL 不是一次性的事情，甚至不是定义和实施正确策略的问题。构建 SDL 本身就是一个持续的过程，诚然可能需要几年时间才能完全实施。微软进行了多次迭代，直到他们的 SDL 达到了堪称典范的水平……而且又花了几年时间才真正在他们的（大多数）开发人员中根深蒂固。您不能真正“试用” SDL，因为收益通常不会在一两个月内显现出来 - 这确实是一项长期投资。

因此，对于刚开始并希望定义其 SDL 的组织 - 我建议慢慢来，让有经验的人在此过程中指导他们：

• 从规划当前情况、流程、团队、经验、灵活性等开始。
• 如果团队 + 管理层不是 100% 相信 SDL 的必要性和一般的安全性，请考虑进行初步安全审查以解决问题......渗透测试通常在这里最有用，因为它可以相当视觉（不是因为此时 SDL 本身需要它）。
• 在这一点上确保你得到了支持——无论是来自执行发起人，还是来自团队本身。没有任何一个，SDL 注定要失败。
• 训练！开发人员喜欢做正确的事情，如果他们知道如何做的话。
• 根据您将获得的收益，与投入的工作量相比 - 以及对开发团队的干扰，慢慢添加最少的额外安全活动。请记住，练习的重点是让每个人都参与安全，而不是立即关闭它们。
• 在您的团队（作为安全拥护者）或在每个人都可以交谈的中央团队中建立安全专业知识 -并让他们交谈。更好的是，它是两者的混合模型（如 MS 模型）。
• 根据您额外安全投资的能力，在每个周期中添加最少的额外活动，在之前的活动之上。关键是让他们习惯于做一两件小事，它（几乎）成为第二天性，并且不再“花很长时间来做这些安全工作”。然后你将有更多的带宽......
• 在此过程中收集指标，这样您就可以分辨出哪些有效，哪些无效，并展示 SDL 投资对管理的好处。
• 更多培训！

现在，真正的问题是上面的列表，看起来很多。
但它确实不是，因为大多数子弹都是“元活动”。其中一些可能应该由经验丰富的安全人员/gal/顾问来完成，他们在与您类似的环境中实施 SDL 方面有经验。诚然，仍然不是那么简单，但是当我这样做时，我将重点放在最小的干扰和持续的投资上。它可以做到轻量级。

我曾经写过一篇非常好的文章，称为持续预防安全生命周期(CPSL)，并进行了后续回顾。我认为它们现在有些过时了，但它们正是您所要求的。