应用程序的安全问题是在软件开发中正在形成的一个重要的需求。严重的品牌破坏，可能的财务损失，以及秘密问题，风险敏感客户。例如金融机构和政府组织，正在寻找方法来评估他们构建或购买的产品的安全情况，并计划最终保证销售商对他们的软件中的安全问题负责。这个问题进一步加剧了开发的风险，也如同源程序的共享与开放。

2002年，微软开始致力于通过它自己的开发过程提高软件的安全性，包括培训和过程的改进。在这个工作开始的两个月，它的整个开发工作都被禁止对任何产品进行变更，除非有特定目的变更改进了安全性。很多其他的销售商，例如Oracle，也采用类似的方式高度重视软件安全性的影响。

有效地定位软件安全问题是困难的，因为传统的软件开发生命周期并没有很好地处理这些问题。这是因为软件开发者缺乏结构化的指导；很少有比较新的这方面的书籍，他们只有收集最佳实践。

另外，安全性不是一个较普遍的特性。开发组织通常更倾向于关注核心功能属性，然后在开发过程中以一种特殊的方式处理安全性。但是开发者在安全性方面缺乏经验，只会提供服务的最小集。这通常导致了理解安全技术很匮乏。

比如，SSL是为在网络中传输数据提供数据机密性和完整性服务的最流行的方式。然而，大多数SSL部署会受到网络攻击的影响，因为这项技术普遍地都认识不清。特别是，人们倾向于把SSL看成是传统socket的补充，但是当运用这种方法时，关键服务器验证步骤被忽略了。执行合适的验证通常是一个高度复杂的过程。

开发技术是SSL或Java的组织经常对软件的安全性产生失败的感觉。例如，安全软件是一个非正式的Java程序，安全风险显现了出来，平均起来，一旦有千行的代码，就是一个非常大的数量。

对软件安全性的通常的小规模的方法是，组织经过了他们的认可，希望安全性问题将不会再自己出席，将大多数安全问题推延到他们出现时处理，经常是在软件部署之后进行。这就是所谓的被称为“透过和补丁”模型。

当然，当问题找到后，避免安全解决方案就是在软件开发后，增加一个可靠的模型来修复问题。实际上，IBM研究了在不同情况下选择安全问题的代价。