Web 应用程序扫描器并不是 Web 应用程序安全的全部，简单地运行现成的工具并不能解决应用程序不安全的问题。话虽如此，桌面应用程序的安全影响很大程度上取决于您的应用程序的功能。是服务器吗？它是否通过网络进行通信？它有数据库吗？

没有现成的应用程序可以解决这个问题。您需要聘请专业的安全分析师来审查此应用程序并（很可能）手动对其进行测试。

这显然是为了促进经过合理测试的应用程序而编写的。对此我有三点意见：

1. 首先，他们应该有自己的内部扫描程序（漏洞评估），作为验收测试的一部分，他们将提供一个测试平台来运行您的程序。软件供应商可能会选择拥有并开发自己的软件，但永远不能指望根据请求“n”个程序变体的“n”个合同来扩展“现成的解决方案”——即使是国防部也认识到这一点。

2. 这个开发方面必须在要部署的环境中进行，否则你没有合理的“利用”图片。漏洞利用分析的目的是获取系统的漏洞，并确定漏洞利用后可能带来的痛苦（即，查看实际的真实影响和潜在损害）。当然，只有在要部署的场景中才能真正评估。

3. 这个客户的想法有点错误，他们认为软件的创建者是软件的测试人员符合他们的最大利益。这种情况在 Q/A 中一直发生，但出于真正审计的目的，绝不应允许在安全性中使用。他们需要有自己的人，或者更好的是一个公正的第三者（让他们联系我:)）来执行漏洞和利用分析。

我专注于应用程序安全。首先，应用程序几乎不会在生产环境中进行测试。您通常在开发后部署应用程序的测试环境中验证漏洞。

只要桌面应用程序使用 HTTP 或 HTTPS，IBM AppScan 很可能用于针对桌面应用程序执行测试，就像它用于测试 Web 应用程序一样。为此，您需要配置一个代理以侦听您的 RFC 1918 地址而不是您的环回，并将桌面应用程序部署在专用 VM 中。在 Windows 中配置 Internet 选项以指向您绑定代理的地址和端口。我会建议 Burp Suite 胜过其他任何东西。

想要入门的个人的信息通常可以在 OWASP 网站上找到。一个很好的起点是 OWASP 测试指南 v4，但如果您正在寻找一些东西来证明应用程序通过某种标准是安全的，请使用 ASVS。

理想情况下，您希望将安全实践集成到 SDLC 的所有阶段，并开发一个与实际 SDLC 分开的框架，称为 Secure-SDLC。Secure-SDLC 将概述安全实践，应根据需要将其集成到 SDLC 工作中。

否则，您可以只进行部署前渗透测试，但成本更高，因为您不可避免地会在 SDLC 中被踢回以修复已识别的漏洞。PCI 和 HIPPA 可能会指定与创建安全开发实践以及针对应用程序运行自动化或手动测试以识别漏洞相关的要求。