数字产品路线图：每次交付的安全检查表

大多数组织都知道安全很重要。缺少的不是信念，而是一种将这种信念转变为例行公事的实用方法，而不是成为与路线图竞争并且总是失败的单独项目。

路线图中的安全性不需要重组。它需要纪律和一个简单的工具：应用于每次交付的清单。不是一份无人阅读的一百页文档，而是团队在考虑现成功能之前回答的一组精简问题。

本文提供了该清单。它适合产品领导者和技术团队，他们已经了解安全的重要性，并希望每天实施这一点，将良好的意图转化为开发过程的一部分。

为什么是清单而不是门

在检查清单之前，理由是值得的。将安全视为最后一道关卡（即启动前的一次性审查）的方法失败的原因有两个。首先，它来得太晚了：那里看起来已经建错了，而且重做的成本很高。其次，它成为瓶颈，而瓶颈是在期限压力下首先跳跃的。

在每个项目的设计和开发过程中应用的清单可以解决这两个问题。它将安全性移至左侧，移至流程的开始，那里的修复成本较低。它将其分散到小额支票中，而不是集中在一个阻碍发布的事件上。

论文：当安全成为一种轻松而持续的习惯时，而不是当它成为一种繁重而准时的检查时，安全就会规模化。清单使这个习惯可以重复。

并非所有功能都具有相同的风险。将完整的清单应用于按钮颜色更改是浪费的；中途将其应用于新的支付流是疏忽。因此，第一个检查是根据风险来校准工作量。

在每个项目的开头询问：该交付物是否涉及个人数据？有钱吗？具有[身份验证0或权限？与外部集成？ “是”越多，清单就需要越深入。越是“不”，就越轻。这种筛选可以防止流程变得统一的官僚主义，并让重点集中在风险所在。

以下是一组按主题组织的检查。不能盲目跟风，而是要根据每一项的风险进行调整。价值在于不断地提出这些问题。

按比例应用的这套风险涵盖了绝大多数日常产品风险。它并不详尽，足以避免导致大多数事件的错误。

清单只有在使用时才有效。为此，他需要住在已经工作的地方。将其纳入团队对“完成”的定义、任务描述或代码审查过程中，使其可以自然地回答，而不是作为一个容易忘记的额外步骤。

自动化有很大帮助。对依赖关系、暴露的秘密和不安全模式的大部分检查可以通过集成到开发过程中的工具来完成，从而使人们能够专注于需要判断的问题，例如授权和隐私。

目标是每次交付响应清单只需几分钟，而不是几个小时。如果它成为一种负担，它就会被抛弃。轻盈是保证一致性的保证。

只有当错误的答案产生行动时，清单才有价值。确定交付未正确验证授权并“因为期限紧迫”而仍然发布它是没有意义的。当这成为一种习惯时，清单就变成了戏剧：每个人都做出回应，没有人纠正。

支持该流程的规则是，针对发现的每个风险，在三种路径之间做出决定：在释放之前纠正，与有权这样做的人正式接受风险，或者将其登记为债务，并在规定的解决期限内解决。不可能存在的是第四个非正式选项：忽略并继续前进。

这种在每个周期都会重新审视的担保债务记录是防止无声积累的原因。随着时间的推移，它会将清单从一次性照片转变为风险管理工具，使领导层能够真正了解推迟的内容及其原因。

这是该工具的诚实限制。在没有理解的情况下机械地填写的清单会给人一种错误的安全感。人们勾选了这些框，他们觉得自己已经完成了，而真正的问题却被忽视了，因为没有人真正考虑过它。

检查表是对头脑的支持，而不是替代它。它确保提出正确的问题，但答案取决于理解每个问题存在原因的团队。投资于团队的安全培训才能使清单变得生动起来。

还存在检查表变旧的风险。威胁发生变化，产品不断发展，新的风险类别出现。从未审查过的清单已成为一种过时的仪式。它需要被视为一个动态文档，并随着产品和威胁形势的变化而进行调整。

最后，清单的优点是将安全从模糊的意图转变为具体的、可重复的实践。它并不能让任何人成为专家，但它可以防止在压力下忘记基础知识，而大多数事件都源于忘记基础知识。集成到路线图中，它使安全性随着每次交付而变化，而不是永远落后。

如果您的组织想要开始将安全性纳入路线图，但不知道在哪里，那么根据您的实际情况调整这样的清单是很好的第一步。博客上还有其他关于路线图、LGPD 和应用程序安全性的文章，对本文进行了补充。如果你想在你的团队中构建这一点，那么就值得讨论。