在我的上一篇博客文章中，我讨论了什么是应用安全计划及其重要性。本文将介绍如何构建和扩展一个有效的应用安全计划。
我见过许多初衷良好的计划最终未能实现目标。虽然失败的原因多种多样，但成功往往取决于几个关键特征：
- 与业务目标绑定
- 具备可衡量的能力
- 能够持续改进
这就是全部！成功计划的其他细节都可以在这个框架下逐步完善。关于具体细节，我将在后续文章中详细讨论。现在让我们聚焦这些关键战略要素，因为如果战略错了，其他一切都无从谈起。
计划必须与业务目标绑定
安全计划必须证明其资金投入的合理性。唯一的方法是将计划直接与支持它的业务目标绑定。这些目标因企业而异，但通常表现为C级管理层制定并经董事会同意的安全政策。这些业务目标本质上是非技术性的、需要工程团队解读的，并且通常不可协商。它们几乎总是关注法规合规性、全球公认标准或客户要求。
如果无法将应用安全计划与企业业务目标紧密绑定，计划注定失败。这是我与新客户沟通时首先提出的问题之一。当客户无法满足这个条件时，我将其视为"僵尸计划"。虽然仍可以提供帮助，但在这种状况改变前，应用安全计划就像行尸走肉。承认这一事实可能是艰难但必要的改进第一步。
计划必须具备可衡量的能力
成功的安防计划必须能够通过一套达成一致的KPI或指标来衡量自身并证明价值，这些指标需要能够准确测量并随时间改进。安全KPI（特别是应用安全领域）可能难以制定，但这并不降低其重要性。
第一步是与利益相关者讨论哪些KPI对他们重要。对高管层来说，可能是某种形式的公司安全政策达标率测量。换句话说，你是否达到了推动该计划的业务目标？如果没有，能否展示向目标迈进的进展？对工程团队来说，可能是更技术性的指标，如发现和修复的漏洞数量、修复新发现漏洞所需时间、团队成员在安全上投入的时间和金钱、外部报告的漏洞数量、实现的安全工程活动、渗透测试和代码审查覆盖率等。
确定KPI后，需要区分哪些现在可以合理测量、哪些需要等待未来测量、哪些可能永远无法测量。知道某个指标重要但无法正式测量也有价值。对于那些可测量的指标，应尽快开始收集数据。数据越多，识别趋势的时间越长，效果就越好。每一天的缺失都是永远失去的改进机会。但需注意：每个纳入KPI的指标都会产生自己的生命力。一旦建立指标，团队就会有动力推动其改进。要考虑副作用和意外后果。指标一旦建立就很难移除，因此要慎重添加每个指标。
计划必须能够持续改进
一旦建立并开始跟踪KPI，改进似乎不言而喻，某种程度上确实如此。工程团队喜欢优化，一旦给出可驱动的数字，他们几乎总会开始工作。但有些例外值得注意，每个例外都是计划成功前需要克服的障碍。
上一节提到需要获得利益相关者的同意，但这一点值得深入探讨。虽然需要高管对高管级KPI的同意和工程团队对工程KPI的同意，但实际情况是：需要工程团队同时同意高管级KPI和工程KPI。由于高管KPI与可能不可协商的业务目标绑定，这可能看起来很困难。常见错误是不与工程团队讨论高管KPI，只是作为法令从高层颁布（“你必须”）。有些人错误地认为，既然业务目标不可协商，相关KPI就不值得讨论。这与事实相去甚远。工程团队不会完全承诺它不理解的目标。如果业务目标是真实的且KPI与之绑定，就值得讨论。一旦工程团队理解这些KPI，他们就会同意。一旦同意，他们就会致力于优化它们。另一方面，如果他们不理解也不同意，可能只会得到表面认同而非全力投入。当客户向我反映工程团队行为问题时，我通常会发现认同问题。获得工程团队的认同不一定困难，但必须完成。
另一个常见错误是获得推动KPI的同意但未能为团队提供成功条件。给已经满负荷的团队增加更多工作并期望他们完成任务是不够的。如果要推动新KPI以实现成功的应用安全计划，就需要充分资助它。充分资助意味着提供足够的工作周期来完成，购买提高效率所需的工具，并提供培训确保团队知道如何完成任务。
注意，这是我第一次提到工具。不要在定义应用安全计划前就购买工具。工具能为已有计划增加效率，但不能也不会为你提供计划定义。任何告诉你相反说法的人都是在推销产品。
完成这些重要步骤后，你就走上了成功计划之路。你已经定义了一套良好的需求，就如何衡量成功达成一致，并为团队设置了能够迭代和改进的条件。一旦启动这个良性循环，几乎就能保证成功的结果。你将从幼稚的计划开始，但随着时间的推移将达到完全成熟，成为他人仰望并希望效仿的安全最佳实践典范。现在就开始工作吧！