不应该将软件安全活动仅限于技术SDLC活动，尤其是渗透测试。你当然应该利用渗透测试的优势，但你需要了解它的局限性。主要的限制是经济方面：当你在内部系统（或者即将出货的系统）中发现一个安全问题，解决问题将变得非常昂贵。你要解决你所发现的问题，对吗？这里需要注意的是，软件安全不仅仅是充斥着各种漏洞以及攻击者威胁的技术问题。当然你需要做大量适当的技术操作，但永远不要忘记将这些操作直接联系到业务影响和风险管理。你正在修复开发器以确保开发人员在最开始制造更少的安全漏洞吗？你正在构建安全的中间件解决方案以供开发人员和架构师使用吗？你正在测量安全活动，并内部公开相关结果吗？你应该这样做。这也是BSIMM涵盖的范围广于架构师、开发人员和测试人员的工作范围的原因。我们询问了很多企业有关提出、创建和部署安全软件的一切数据，我们记录了这些数据，并产生了BSIMM。我们与跨多个垂直行业的各种规模的几十家公司（包括软件供应商）的持续接触都表明，一个涵盖政策、风险、合规、管理、衡量、运营、服务水平协议以及相关条目的软件安全计划除了设计、编码和测试中所有重要关键的因素，他们认为是这些业务流程以及他们产生的文化和环境对生产和维护安全软件至关重要。

　　为你的SSG发展和培养软件安全专家（因为周围没有足够的合格的专家）。最佳软件安全组成员是软件安全人员，但软件安全人员往往找不到。如果你必须从头开始创建软件安全类型，从开发人员开始，教他们安全知识。不要试图从网络安全人员开始--教他们关于软件、编译器、SDLC、漏洞追踪和软件界的一切知识。再多的传统安全知识也无法克服软件的“木讷”。应该像种树一样，从播种开始，逐渐将其培育成参天大树。当你开始这样做时，你应该尝试培养“瑞士军刀”类型的专家，而不是重视每分钟的专家。我一直期待找到可以审查代码、做一些渗透测试，以及能够解决安全问题的人。

　　关注来自业务、运营和事件响应人员的情报信息，并相应地调整SSI控制。安全是一个过程，而不是一个产品。软件安全更是如此。你可以构建世界上最好的代码，具有超级“防弹”架构，但在操作过程中仍然可能发生问题。使用你经历过（以及你的同行经历过）的安全攻击来提高你的软件安全方法，并根据业务重要性来进行调整。尽可能地了解你的敌人。

　　仔细追踪你的数据，知道数据的位置，无论你的架构多么云计算化。云时代已经来临，你的数据将被转移到云中。请了解清楚，你不能将软件安全责任外包给你的云供应商。你的客户还依赖你来保护他们的数据，在某些情况下，政府还会监管这种责任。云计算的弊端在于应用在云端运行。现在正确地构建，能让以后的日子更轻松。