当“应用程序”是运行在单一服务器上的巨大软件的一个单元时，应用程序生命周期管理(ALM)将仍然会是一个挑战，这是因为为了在整个软件改变的级别上维持业务运营的需求。随着在员工一侧的云计算与弹性资源，多供应商集成、模块化和编排的结合，挑战也被放大了。
放大效果非常严重的地方是安全领域。像其它在应用部署中的需求一样，云安全需求应该在ALM中得到反应，而不是靠运气。
当“应用程序”是运行在单一服务器上的巨大软件的一个单元时，应用程序生命周期管理(ALM)将仍然会是一个挑战，这是因为为了在整个软件改变的级别上维持业务运营的需求。随着在员工一侧的云计算与弹性资源，多供应商集成、模块化和编排的结合，挑战也被放大了。放大效果非常严重的地方是安全领域。像其它在应用部署中的需求一样，云安全需求应该在ALM中得到反应，而不是靠运气。
在ALM中，应用程序贯穿在开发/修改、测试、展示，部署、生产/运营、版本管理和然后从头开始的整个迭代周期中。在传统的静态数据中心部署中，安全流程经常是用在像数据中心、网络之类的环境中，在那里部署、测试应用程序，而且更像为运营作部署而不应用程序本身。周期性的ALM流程在一个一致的安全保护伞下运行着。不幸地，这种方法对云步不起作用。
在云部署中，应用程序越来越多地部署在托管关虚拟机或SaaS组件元素的虚拟子网络中。然后经过通过网关连接到这个应用子网络上的WAN来访问这些。所有的这些虚拟化都掩盖了一个事实：出于安全目的每一种应用程序结构都是新的基础设施。仅仅只是作为一个虚拟LAN，而没有任何网关，是不能支持用户连接的，没有关于那个网络的具体安全功能的LAN也是不安全的。这迫使用户反把安全管理的环境问题转向了应用程序问题，这也就是转向了ALM问题。
基于ALM安全的起点必须是一个虚拟网络模型，例如真正的基础设施，这样可以得到保护。不论是公有云，还是私有云，以及所有云服务的SaaS模型，都应该也这样的假设兼容，假设一个给定的应用程序组件托管在一个虚拟的LAN上，并在IP地址集上通过网关可以访问。这个模型提供了一个网络连接框架，这样可以你LAN在数据中心那样得到保护，这意味着防火墙、访问控制之类的可以遵循ALM专业人士很可能在内部IT中已经使用的标准的数据中心模型。该模型将来不得不要适应云，同时也必须要涉及到整个ALM流程，从开发/修改到版本控制和发起一个新的变化周期。
为了云安全实践做的修改现在与托管应用的虚拟网络模型和用于数据中心应用听真实网络模型的不同之处有关。如果应用程序的虚拟网络只是对控制的 VPN有用，那么这就代表着与传统的从同样的VPN访问应用程序相比，安全性并没有提高。如果应用虚拟网络通过互联网和互联网VPN可访问，那么应用程序的网关在互联网上是可寻址，以及是受黑客或DDoS攻击的目标。这往往是通过ISP或应用听VLAN网关来缓解，但无论是哪种情况，激活安全流程都必须是明确的(通过合同或通过选择和设置正确的网状)。这些步骤将来不得不加入到ALM流程的清单中，不不仅是为生产的部署，也是为了应用程序曝光之前的所有阶段。
在ALM中适应去的问题是，版本的多样性和应用程序可以在一个给定的点的操作状态。一个给定的软件很可能存在于在至少两个操作状态(生产和测试)中，也可能是5个，甚至更多的状态中，这要取决于软件修改流程的复杂性和测试的数量，与迁移一个应用程序相关的全面生产的前期制作阶段的数量。虽然每个测试阶段测试安全以及应用程序功能是重要的，但同样重要的是，安全流程要明显不同与所有其他版本相控资源集。只是有一个安全保护伞来保护所有的软件 ALM阶段，或测试污染生产使用存在风险，是不能令人满意的。
事实上，在ALM中保护应用程序的多状态或多版本的最安全路径是，假设每一个ALM状态或版本(例如，生产和测试)有他们自己的虚拟网络，以及有相同的工具集和操作流程不保护每一个虚拟网络，每个都有自己的迭代的工具和流程。
这些必须相互保护独立，就像真实的软件版本保持独立一样，也是同样的理由。混合安全流程可能会经意间影响生产应用程序安全，或者是允许用户访问测试系统，当他们确信他们正在使用产生版本的进修。最重要的是，对于云来说，安全必须是ALM的一个元素，因为虚拟资源安全不能简简单单地就被管理，或得到保障，只是借助于传统的网络和与固定资源和设备相关的IT流程。
安全并不是唯一的工具集和实践，它不得不从一个整体基础设施转移到一个应用程序为重点的，从固定托管移动到云上的应用程上，但它很可能是第一个，也是最重要的。假设云安全问题是把应用迁移到云上的主要技术障碍，那么就可以合理的假设，在ALM中未能适应新的安全模型，可能放缓云应用的速度并减少整体利益。
