上一次我们讲述了如何在自动化测试环节应用BSI，包含静态代码扫描、动态安全扫描和依赖扫描等，这一次我们的关注点将转向主动出击和团队协作，最后展望一下BSI的趋势。
由于在应用开发过程中不可避免的会产生一些安全问题，所以大多数企业在应用上线之前会安排做安全审查，通过审查之后得到的安全报告来了解应用的安全状况，并作出下一步行动。典型的例子是由企业自己的安全团队进行安全审查，就如本文P2P案例里的那样，或者聘请第三方安全公司来做渗透测试，在安全报告里罗列出发现的安全漏洞细节及修复建议，开发团队根据这份报告对安全漏洞加以修复，决策层则根据报告内容以及问题修复状态，再综合其他因素作出是否批准上线的决定。
有些企业还建立了安全事件应急响应机制，在应用上线之后，一旦安全漏洞被攻击者发现或者被白帽子报告，企业会积极的根据应急预案采取相应的措施加以应对，例如服务切换、固定事发现场并取证调查、发布安全公告等等。
无论安全渗透测试能发现多少安全问题，不管应急响应机制设计是否完善高效，这些做法都属于事后被动应对的范畴，即安全漏洞已经存在了很长时间，甚至都演化成了安全事件，在这之后才通过一些补救措施来发现漏洞、减轻损失。这就好比如，一位每年都会做例行常规体检的人，拿到体检报告后发现自己得了某种疾病，此时赶紧加以治疗。实际上有很多疾病是难以通过体检发现的，当身体已经极度不适的时候才去医院检查治疗，而这时候罹患重病就是大概率事件了。疾病既已形成，无论体检还是急救，都是事后弥补措施。
BSI倡导主动应对安全问题，通过分析潜在威胁、明确安全需求，以及安全测试驱动开发的方式，在应用开发过程中提前预知可能发生的安全问题，并提前采取行动加以避免，不给安全漏洞生根发芽的机会。例如，在项目需求分析和架构设计中引入威胁建模，在分析业务需求、设计系统架构的同时，主动分析应用面临的安全威胁，制定应对措施，并进一步将其转化为安全需求；在编码实现时，开发人员在具体开发某个功能的时候，根据安全需求编写对应的安全测试用例，甚至还可以把这一步加以强化，在编写代码之前先编写安全测试用例，实现安全测试驱动开发。与传统的安全审查和应急响应相比，BSI所倡导的各种实践是在安全漏洞产生之前进行的，是对安全漏洞的主动应对。
如果做一个关于谁应该对产品的安全性负责的调查，绝大多数团队会认为这是测试人员的职责，理由是测试人员要对产品进行各种测试，其理所当然应该进行安全测试，进而能发现产品中的各种安全问题。如果企业里还有专门的安全团队，此时的调查结果很可能很可能会变为：安全团队应该主导产品的安全性并为此负责，理由也很简单，这不就是安全团队天生的职责吗？然而很不幸，这其实是一种误解。
无论是测试人员还是安全团队，一旦团队认为安全应该由他们负责，往往就会形成这样的氛围：反正有人专门在进行安全测试，等他们发现了问题再改就行了。然而这种氛围有众多弊端，首先是它非常消极，并且容易形成相互对立的局面，其次，寻找安全漏洞对于绝大多数测试人员而言是一项几乎难以完成的任务，最后，这种氛围不利于团队安全能力的建立和提升。
消极
如果团队认为有测试人员或者安全团队在扮演守门员的角色，容易让团队成员产生一种错觉：反正专门有人在做安全测试，这部分工作就交给他们去做吧。看似是对团队其他成员的信任，实则是以消极的态度对待安全问题，久而久之就会在开发过程中放松警惕，一些本来可以尽早发现并消除的安全问题会悄然被埋藏在产品里，等到最后发现这些安全问题的时候可能为时已晚，要么修复成本高昂，要么被攻击者利用造成更大的损失。
对立
在这种氛围下，由于团队认为安全是团队中测试人员的职责，所以团队成员之间可能出现相互推诿和对立的情况，业务分析人员认为安全是技术问题，和业务分析没有任何关系，开发人员不愿意主动承认代码存在安全问题，他们认为这是测试人员的失误，没有把安全问题测出来，而测试人员则认为安全问题是开发人员一手造成的却由自己来背黑锅，实在有失公允。
难以完成的任务
一个无奈的事实是，由于绝大多数测试人员的安全技能是缺失的，要么不具备安全测试的能力，要么只能利用自动化工具做非常简单的安全扫描，对于那些比较隐蔽的、需要深入进行手动分析和测试的安全漏洞就无能为力了，而往往正是这些才是最具破坏力的安全漏洞，因此对于普通测试人员而言，很难做到全面、深入的发现安全漏洞。
团队安全技能
如果团队只依赖某一个人或者一个角色来保证产品的安全，那就存在单点失败的风险，一旦他们因为某些原因离开了，势必会给团队带来巨大的影响。这些人或者角色虽然能发现安全问题，但与此同时也是整个团队安全能力提升的瓶颈，因为团队过于依赖他们，安全问题都被他们发现和解决了，在其他团队成员的眼里看来，自己是否具备安全能力仿佛无关紧要，也就不会再主动关注安全技能的培养和提升了。
除此之外，从安全团队的角度来看，情况也不容乐观。很多中小企业里其实并没有全职的应用安全团队，往往是由IT部门兼职负责对应用进行安全审查，但由于他们还有其他工作需要进行，例如对企业中的IT设备、网络设备等进行管理维护，甚至还要负责产品的运维工作，因此难以做到全面、深入的安全审查。拥有专职安全团队的企业为数不多，而拥有大型安全团队，并且人员安全技能优秀的企业则更是凤毛麟角。造成这种局面的因素是多方面的，市场上高质量的安全人才非常稀缺，人力成本高昂是重要因素之一。无论企业拥有怎样一支安全团队，如果让产品的安全性仅仅依赖于安全团队的渗透测试，很容易形成一个恶性循环，既开发团队认为有安全团队对安全性最后把关，只要他们不抱怨就间接证明产品是安全的，而安全团队则会发现安全改进很难在企业中推进，因为开发团队不认为这是他们自身职责的一部分，从而缺乏改进动力。
靠打针吃药可以治好眼前的疾病，但终究不是长久之计，唯有想办法提高自身免疫力，才能降低患病机率，或者更快的恢复健康。
和传统的高度依赖于某个人或者安全团队来保证产品安全的做法不同，BSI则是把安全职责拆分到团队中的每个角色身上，让所有人都参与进来，共同协作解决安全问题。由于每个人都肩负着维护产品安全性的责任，所以每位团队成员都会主动为此付出努力。业务分析人员在分析业务需求的同时会把产品的安全性纳入考虑的范围之内，如果他们没有相关的安全技能，则会积极主动的去和技术人员合作，以达到明确安全需求的目标，开发人员在编码的同时会有意识的去避开安全风险，并协助测试人员对产品进行安全测试。在产品交给安全团队进行安全审查的时候，一些安全漏洞已经被发现并修复了，甚至在需求分析之时就已经开始刻意避免了，此时的产品已经具备了较好的安全性，也为安全团队争取到了更多的时间，使得他们可以把更多的精力放在检测深层次安全漏洞上面。
通过这种共同分担职责的方式，一些安全问题能更早的暴露出来并及时的加以解决，开发团队在应对安全问题上的内部凝聚力会得到增强，团队成员会更有意愿和动力去提升自己的安全能力，并且能不断从中得到正面反馈，与此同时，安全团队也能更好的和开发团队进行协作，从而逐渐形成一个良性循环。
安全，永远都是每一个公司一直所追求的，而在互联网时代，更是重中之重。全美规模最大银行之一的首席执行官曾说他只担心三件事会在一夜之间摧毁自己的银行:“天降陨石、核武器以及网络安全。”毕竟当前大部分企业级软件已经接入互联网，未来势必会越来越多，所以公司在安全上的挑战可想而知。而安全的最主要的两个因素是：人和系统。人的安全是一个复杂问题，而系统安全是一个工程问题，并且通过系统安全可以减少由人引发的安全问题，所以应该优先考虑系统安全。而系统安全的重点是需要开发出一套安全的系统，所以如何开发出一套安全的系统就是系统安全的前提，无此前提系统安全将无从谈起。
BSI旨在通过在软件系统的开发流程中增加各种不同的安全实践，从而保证软件系统在发布前在业务和技术层面上已经足够安全了。由于当前的大部分软件系统都不是一次性的开发，而是在软件交付使用之后还会继续维护开发，比如修复bug，增加新功能等。所以BSI不仅仅是在软件开发流程中实施，还需要在后期维护流程里面持续实施（因为有些软件系统的维护团队和开发团队并不是同一个团队）。但是并不是说实施了BSI后软件系统就无后顾之忧了，因为软件系统交付使用之后的运维也非常重要，就算拥有一个十分安全的软件系统，如果运维不当，也会出现很多安全问题，比如内部人员故意破坏造成安全问题，所以一个软件系统还需要有一套安全运维实践，由于它不属于本文讨论的范围，这里将不进行深入讨论。
不可否认使用BSI必将会增加开发成本，比如增加了业务的分析成本，在CI上搭建安全扫描的成本，安全扫描结果审查的成本等。不过相对于这些成本，更应该关注的是系统的安全漏洞被黑客发现并被利用以后造成的损失。所以将安全开发增加的成本和未来因为安全漏洞可能造成的损失进行比较才能理解其合理性。如果损失可能大于增加的成本系统，比如银行、保险等金融相关的系统，应该使用BSI来减少安全漏洞和损失；而如果损失可能小于增加的成本系统，比如一个博客系统，在被黑客攻击以后损失很小，考虑BSI并不是第一优先级（前提是并不在乎使用这个系统的客户的损失）。
文章阐述到这里还有一个问题没有被提及，就是如何度量BSI。作为一个想要实施BSI的软件开发团队，抛开如何实施怎样实施这个操作层面的东西，企业管理层一定会首先关心如何评估团队BSI成熟度，如何界定，具体标准是什么。这部分内容会在后续的文章里专门介绍。
安全不是绝对的，所以BSI对于安全的保证也是相对的，但是对于业务越来越复杂，规模越来越庞大的软件系统，BSI这种安全软件开发流程和其实践方法们必将从源头上减少安全风险，大大降低被黑客攻击的可能，从而显著减少系统在投入运维之后由于安全问题造成的损失，使其更适合在互联网的大潮中存活下来。