确保Web安全开发意味着将漏洞看作Bug

　　在其最近发布的Web站点安全统计报告中(1)，白帽安全网站发现，在2010年期间平均每个Web站点有230个可能导致被入侵或是数据丢失的漏洞。其他最近的研究也显示，大约70%到80%的Web应用包含严重的漏洞(2)。并且在OWASP(开放Web应用安全项目)的2010年10大风险报告中也报道，这10大软件风险占据Web站点软件漏洞的绝大部分(3)。

　　这仅仅是回顾了多年来漏洞的一系列最新报告，几乎所有报告都显示出同一问题：Web站点和应用仍带着安全漏洞被发布，即使这些漏洞可以很容易地被纠正。不幸的是，这些安全漏洞大多只是在应用和Web站点发布后才被发现。一个有关安全的老生常谈的是，建设安全容易(并且成本低廉)，而不是事后通过补救措施才将螺栓拧紧。

　　为什么这些漏洞能逃过十分熟练的开发人员的眼睛呢?他们开发的应用和Web站点越来越多地支撑着我们全球的经济。作为安全从业人员，我们怎么实现安全Web开发，并为开发人员提供需要的工具来减少这些类型漏洞的数量和发生频率呢?对组织来说，关键是要把安全漏洞像软件缺陷那样来对待，即Bug。

　　这个示范式转变中的第一步，也许也是最艰难的一步，就是让开发部门经理和安全官员对该看法达成一致，把安全漏洞作为可用性或是功能性上的bug来对待。大多数的开发部门经理专注于功能上的缺陷，这些缺陷阻碍了软件正常地运行。挑战在于，让他们明白如果安全漏洞被利用，也可能导致软件无法正常运行，不仅需要宕机时间来修补缺陷，还给组织在经济和名誉上造成损失。

　　安全漏洞就是软件缺陷，需要以同样的方式精确地处理。就这点达成一致可能具有挑战，因为开发部门经理通常不理解安全漏洞对业务潜在的影响，他们不了解如何辨别安全漏洞，甚至即使他们能找到漏洞也不知道该如何纠正。

　　为了支持开发人员克服这些挑战，安全团队可以通过定期的对已在生产环境中的应用和Web站点进行漏洞评估来改进Web应用安全测试。像IBM或是Vercode公司提供的Web安全扫描工具可用于这种类型的测试。测试完成后，开发人员应负责为这些被发现的安全“bug”创建正式的补救计划。这样做，开发人员会逐步熟悉安全测试及补救措施的整个周期。

　　一旦开发人员习惯了为生产环境中软件实施的安全测试和纠正周期，下一步就是将安全测试融合进上线前的QA(质量保证)过程中，同样使用之前用于安全评估的工具。在这点上，安全bug工单应该像其它bug工单一样开启，使用开发人员已上手的同样的bug追踪系统。

　　到了下个步骤，我们能进一步利用软件开发生命周期(software development life cycle，SDLC)模型，以确保开发和测试Web应用的方式的一致性。即使是仅仅开发内部使用软件的小型公司，也正在建立严格的SDLC过程来减少bug。可以利用这些相同的流程，有效地找到安全漏洞。为了充分利用这些已建好的SDLC过程，很可能需要培训开发人员使用上述的工具来找出安全缺陷。好几家厂商提供基于Web的平台，它能够很容易地集成进SDLC过程，并且允许开发人员在SDLC过程的早期，在单元级别测试他们的代码。作为附加的好处，许多这样的工具能在侦测到缺陷时向开发人员提供修复建议。最后，这些工具大多数能与开发人员已使用的bug追踪工具集成，把安全漏洞当作功能性的缺陷来进行闭环管理。

　　通过重新定义安全漏洞为功能性的缺陷或bug，并为Web开发人员提供需要的工具和流程来确定bug和修复它们，这样安全利益相关人就让安全作为组织SDLC过程中不可或缺的一部分，即建设安全而不是事后拉紧门闩。这不仅会促进Web站点和Web应用成本降低，而且更加安全。