不要单纯地依靠安全特性与功能来构建安全软件，因为安全是整个系统的新兴资产，它依赖于正确地建立和整合所有部分。无论我们说多少次，开发人员、架构师和建造者仍然将安全作为一件事情。他们接受的多年的培训都是将系统认为是特性和功能集，这是我们需要克服的。不要陷入“神奇加密神话”的陷阱。加密当然是有用的，一些系统仍将需要加密功能，但安全是一个系统级属性。聪明的攻击者很少会试图攻破加密功能，他们往往会攻击系统其它晦涩部分的漏洞。当你在选择和部署安全功能时，请确保你花了尽可能多的实践来试图消除漏洞和问题。即使是具有良好加密、强大的身份验证、细粒度授权、费解的CAPTCHA以及很多其他完美编码的安全功能的软件，都可能遭受攻击。这些功能通常会阻止授权用户做已知的不好的事情。但他们很少阻止未经授权的用户做未知的不好的事情。你需要一个软件安全计划来为整个产品组合有效且高效地构建安全软件。

　　你应该修复已识别的软件问题：漏洞和缺陷。这很讨厌，但在实践中，软件安全就是这样的。你聘请一些洗心革面的黑客来进行渗透测试，你知道他们已经洗心革面了，因为他们是这样告诉你的。在你让他们从外部探测你的系统的一周内，他们就找出六个安全漏洞，然而，他们可能只会告诉你其中的五个漏洞。你修复了两个看似可修复的漏洞，然后宣布胜利。但其他四个漏洞呢？简单地说，如果你将所有精力花费在通过架构风险分析、代码审查和渗透测试来找出软件中的问题，而不花时间修复你找出的漏洞，你的软件将变得更加不安全。修复软件吧！当然，修复漏洞是一个风险管理活动，没有哪个公司有无限的资金投入其中。因此，企业应该根据影响、成本和其他重要业务因素，来优先漏洞修复顺序。然而，极少数企业会追踪每个没有被修复的漏洞。10个低严重漏洞会变成中级严重漏洞吗？那100个？1000个漏洞呢？此外，极少数企业会关联来自多个测试方法的研究结果，而是在每个测试后，独立作出决定。分别来自架构评估、静态分析、模糊技术以及渗透测试的低严重性漏洞相结合，会成为紧急漏洞吗？我也不知道，但企业应该考虑这个问题。修复软件可能更容易。

　　有关描述性模型的规范性建议

　　最终，你需要确定和采用你自己的规范性SSDL方法，然后使用描述性的测量系统来跟踪进度。我们的建议是使用BSIMM来测量你的软件安全计划的当前状态，确定你应该开始着手的其他软件安全活动。如果你的企业确定需要投资的领域之一与SDL中的一个做法相匹配（举例来说），你可以利用微软对此的智慧来做。

　　鉴于多年来我们一直在观察51家公司的真正的软件安全计划，我们可以自信地说，如果你的软件安全计划没有每年进行改善，你将落后于其他公司。我们知道，每个软件安全计划都是独一无二的，就像所有其他软件安全计划一样，你的同样也是独特的。幸运的是，无论你为软件安全采取哪种规范性方法，BSIMM都可以作为测量标杆、灵感源泉以及是否进步的客观测量标准。