在我见过的几乎每一个产品路线图中,安全性都占据着相同的位置:“重要,我们稍后再做”。它输给了畅销的功能、客户抱怨的修复以及市场规定的最后期限。它始终是一个优先事项,只是从来没有这个冲刺。
问题是延迟的安全并没有消失。它像债务一样悄无声息地积累,直到在最糟糕的时刻以事件的形式一次性收取利息。然后,一夜之间,它就成为唯一的优先事项。
本文使用匿名但代表重复模式的真实案例来展示当安全性被排除在路线图之外时会发生什么。它适用于正在决定在哪里投资并需要在将安全性推向下一个版本之前真正了解权衡的产品和技术领导者。
为什么安全总是失去优先权
这种动力是结构性的,而不是恶意的结果。新功能会产生可见的收入和好评。执行良好的安全措施意味着不会出现任何问题,而且没有人会庆祝没有发生的事件。当您优先考虑可见的内容时,安全性自然会下降。
再加上市场压力、销售截止日期和“什么都没发生”的感觉。结果是可以预见的:路线图充满了功能,安全性成为每个季度都被重写为“下一个季度”的脚注。
我捍卫的论点是:安全不是路线图上的一个项目,而是路线图上每个项目的一个属性。将其视为一条单独的线可以保证在截止日期到来时它会被削减。以下案例说明了为什么这种区别很重要。
案例 1:为了自身安全而增长过快的初创公司
一家科技初创公司获得了迅速的关注。一开始的重点是发展和证明产品,这是正确的。安全性是“产品与市场契合之后”的。路线图只有功能。
随着庞大的用户群出现了这样的事件:访问控制缺陷允许一个用户仅通过更改请求中的标识符来查看另一个用户的数据。修复本身很简单。不是伤害。存在个人数据泄露、[LGPD0] 下的强制通知、客户疲劳以及急于审核在没有安全标准的情况下构建的所有内容的情况。
教训:一开始解决起来很便宜,从第一个端点嵌入授权验证,随着产品规模庞大并投入生产,解决起来变得昂贵。延迟安全并不会随着时间的推移而变得更便宜。它更昂贵,因为它随着产品的增长而增长。
案例2:在最重要的日子停止的公共产品
开发了公民服务系统,并制定了路线图,重点是在政治期限内提供功能。连续性、经过测试的备份和针对负载攻击的保护是“未来阶段”的。
事件发生之前,未来阶段从未到来。在高峰日,即基本服务的截止日期,系统无法使用。不是由于复杂的攻击,而是由于缺乏基本的弹性,而这种弹性在路线图中已被取消优先级。该公民没有其他竞争性的申请可以求助,因此无法获得他所依赖的公共服务。
这里的成本不仅仅是技术成本。这是一项公共信托,是政府部门最难重建的资产。这个教训是惨痛的:在公共部门,安全性和连续性是不可谈判的特征,因为失败不会影响公司,而是影响民众。
案例 3:阻碍增长的证券债务
一个成熟的产品最终决定寻求更大的客户。这些客户要求在签订合同之前进行安全审核。就在那时,递延安全法案出现了。
多年来没有安全标准的路线图积累了巨大的债务:过时的依赖关系、缺乏基本控制、缺乏流程。为了通过审核并完成大型合同,团队不得不停止几乎所有功能开发数月来进行修复。
这个悖论是残酷的。 “为了不阻碍增长”而推迟的安全措施最终却阻碍了本应成为可能的增长。教训:安全不仅仅是防止损失,它还是进入更大市场和要求更高客户的条件。
统一这三种情况的模式
纵观这三者,模式就很清楚了。在所有这些项目中,安全都被视为一个单独的、可推迟的项目。总而言之,推迟在当时看来是合理的。总而言之,这笔费用比一路上完成的工作要大。
持续嵌入安全性的成本是分散且可控的。在事件或审计压力下一次性进行全部补救的成本是集中且痛苦的。这就是按月付费和一次性支付全部年度账单之间的区别。
战略愿景:将安全纳入路线图的每一项中,并没有放缓。这是为了避免突然停止,从而有效地破坏节奏。可持续的速度来自于不积累爆炸性债务。
如何在不阻塞路线图的情况下添加安全性
解决方案不是将路线图变成安全项目。它是以与风险成比例的方式将安全性集成到正常的产品流程中。
每一个新功能诞生时都应该问这样一个问题:“这里的安全和隐私方面可能会出现什么问题?”答案在图画本身中。处理敏感数据、金钱或[身份验证1]的功能值得更多关注;表面上的改变,则不然。规则就是风险。
保留团队容量的一致部分,以减少安全债务并保持依赖项最新,防止爆炸性积压。它并不迷人,但它是控制利率的原因。将 [LGPD2 合规性视为设计要求,而不是事后的想法,可以减少返工并保护组织。
给那些做出决定的人的反思
文化陷阱是缺席的乐观主义。 “我们从未发生过事故”被解释为“我们很安全”,而它只是意味着“我们尚未受到指控”。这是大多数未解决的危机之前的平静。
产品领导者的成熟体现在愿意为不会立即引起掌声的路线图上保留空间。答应客户要求的功能比访问没有人会注意到的控制更容易,直到有一天它的缺席破坏了多年来建立的信任。
这些案例从不同的角度展示了同样的道理:路线图之外的安全不是储蓄,而是高息债务。谁能理解这一点,就不再问“我们可以把安全留到以后再说吗?”并接着问“每次交付的风险程度如何?”。第二个问题是打造持久的产品。
如果您的组织已经将安全性推向下一个版本几个周期,那么您可能已经积累了这些案例所描述的债务。博客上还有其他关于路线图、[LGPD3´ 和安全性的文章,深入探讨了如何集成这一点。如果这是您产品中的敏感点,则值得在此事成为事件之前进行讨论。
另请阅读
- [数字产品路线图:每次交付的安全检查表4
- 【创建应用时:初学者不能忽视的安全5
- 【内容推荐:系统扩容时的安全与隐私6
- [数字产品生命周期:基本趋势和步骤7
- [数字化合规性:与实际案例的实际比较8
- 【数字化产品策略:从零到可扩展的完整指南9