四、制定连续性的方法，以发现并评估漏洞

　　1、使用厂商的警告和公共的漏洞数据库，以跟踪新出现的应用程序安全问题，并长期且连续地评估漏洞。

　　企业不妨考虑构建一种职责来跟踪已知的问题，用以防止遗漏安全检查的工作岗位。该角色还可以监视常规的漏洞评估。保持应用程序的安全并不是一个一次性的过程，虽然它要求与最初发现漏洞一样的检查。必须经常地对照标准检查安全问题，查找任何异常情况。

　　2、对环境中的每一次更改都要扫描并测试应用程序的安全性。

　　要针对所有的已知漏洞扫描所有的新代码，在每一次部署中，对于新确认的漏洞也要扫描所有的老代码。要记录、跟踪以前的软件漏洞，并确保将来不会犯同样的错误。如果你的应用程序环境并未发生任何变化，尽量保持与厂商的警告和新安全威胁的同步也就足够了。当然，由于安全扫描和测试自身也会发生变化，你还需要监视新出现的问题，以决定是否采用新的测试过程。否则，就要在每次变更时测试应用程序的安全性，并至少运行一次测试，以捕捉任何意外的、及授权的变更。

　　3、向开发人员提供一套可靠的程序，使其在应用程序的编译和部署之前、在投入生产中之后都能够扫描代码中的漏洞。

　　静态分析产品在开发过程中变得日益普遍。但是，要理解对质量和安全的静态分析需要采取不同的方法，这很重要。质量的静态分析受到能够理解漏洞的开发人员的广泛认同。而安全的静态分析，常常要求安全专家具备一套健全的“安全思想和理念”。

　　五、在应用程序的整个开发周期都要保障应用程序安全

　　1、要为安全架构和应用程序的安全设计确立责任和义务

　　安全的开发周期，在保证跟踪并强化开发过程的任何时期，都要建议一套特定的检查和活动，确保开发团队产出代码的安全性。例如，在设计阶段，安全的开发周期将会建议安全团队进行架构检查，验证是否解决了安全问题。

　　2、提供与现有的IT工具和程序相集成的修复功能

　　由于时间在安全问题上至关重要，所以任何应用程序的安全解决方案都应当包含这种工具：能够在安全人员、开发人员、重要业务的关系人等方面促进团队工作。与现有的程序相集成，如与漏洞跟踪系统或开发环境的集成，可以改善通信，并可以提高对新威胁的响应速度。

　　3、将多种漏洞检测方法整合到一个健全的控制点上

　　应用程序的安全解决方案必须从应用程序的内部出发，能够在多个点上捕获数据，实现更全面的漏洞检查。这可以使IT人员寻找能够指明哪些漏洞需要优先解决的模式。只有应用程序安全的测试方案同时包含静态分析和动态分析，才可以检测最大范围和数量的安全漏洞。静态的分析，可以在编码的过程中实现，它可以自动检查应用程序的源代码，并向应用程序的开发人员发出漏洞警告。而动态分析则是在测试和生产阶段的应用程序内部进行，其目的是为了查找仅在执行代码时才可能表现明显的安全问题。

　　4、在软件通过完全的测试之前，禁止其进入生产环境。

　　在没有针对当前的已知威胁进行测试之前，不要将应用程序投入使用。在系统开发周期中，应当对任何代码的变更都实施此要求。

　　六、将应用程序的安全作为日常运维的一个不可分割的组成部分

　　高效的应用程序安全策略要能够解决紧急的和系统性的风险。多数企业使用的应用程序的范围都很广，这包括外包的和现货供应的应用程序、开源的及内部开发的应用程序，每一种程序都有其发现并修复安全漏洞的不同方法。然而，多数软件开发者并非安全专家，而多数安全专家也不开发软件。要让一个IT团队有那么即使一两个在安全和开发两方面都精通的“通才”也几乎是不可能的。将应用程序的安全问题完全交给内部解决，就如同要求招聘特殊技术人才一样困难，或者就像通过培训现有的雇员来构建这种技术一样不太可能。这两种选择都极其昂贵并会消耗大量的时间。

　　应用程序的安全保障是一个系统工程，是应对应用程序的风险问题的不同人员、过程、技术等的综合体。应用程序的安全保障有三个不同的要素：在现有应用程序中能够衡量风险的减少数量， 防止新风险的引入，确保与应用程序的安全要求保持一致。

　　企业可选择的一种解决方案是，与一个在安全和开发方面都擅长的厂商合作。这个解决方案应当扫描现有应用程序中的漏洞，并告诉开发人员如何修复这些漏洞。还要确保在每个阶段（从设计到代码编写，再到测试和实施阶段）的代码安全性。这不但能够解决评估和修复安全风险的问题，还可以解决系统化的问题。实际上，多数软件开发从一开始就没有将安全性整合到编码和测试过程中。