宜信SDL实践：产品经理如何驱动产品安全建设

 

一、序言

本文从产品经理的角度出发，对产品经理的安全职责、产品驱动安全的内涵、工作内容、工作方法、所需安全资源、以及产品经理的安全工作量进行了分析。希望所有产品经理在没有心理负担的情况下，有目标、有方法、有资源推进产品安全建设。

二、背景

安全是软件产品天然属性的一部分，“无安全不金融”，对于金融软件产品而言，安全尤为重要，因为客户总是能够从各种安全漏洞联想到他的金融资产安全和个人信息安全。以前偶尔会在一些安全沙龙或峰会听见同行吐槽，“信息安全说起来重要、做起来次要、忙起来不要”。吐槽背后的原因很复杂，其中很重要的一点是跟产品经理安全意识淡薄、不清楚如何推进产品安全建设有关，比如不重视产品安全属性、产品安全需求不明确、产品安全资源不充分、产品安全建设无从下手等。本文主要站在产品经理的角度，从产品经理能力维度出发，探讨产品经理如何推动产品的安全性建设。

众所周知，安全性作为软件产品的天然属性，从产品定义与规划角度来看，产品经理对产品安全负有不可推卸的责任，但产品经理如何履行自己的安全职责，业界还没有给出一个清晰可行的行动方案。

目前，软件产品安全需求通常是基于开发人员和安全人员的职业常识提出相应的解决方案，比如目前业内比较通用的敏感信息五要素分析方法：

​这种方法简单易行，但往往不能涵盖所有的敏感信息，比如

• 用户的多系统用户数据关联ID（超级ID）。
• 交易过程中的音视频等多媒体数据。
• 各种非结构化的文档数据，如合同扫描件。
• 用户的行为画像数据等内容。

这些信息均为有价值的敏感数据，显然不属于前述的敏感数据范围，但往往没有明确的防护要求。从特定业务场景出发，产品经理对敏感数据范围及其业务价值最有发言权。

三、安全部门的尴尬

前述的敏感信息五要素分析方法是典型的安全驱动产品的方法，即安全部门推动产品相关各团队的安全工作开展。这种模式存在很多弊端，比如：

• 安全需求可能不完整，职业常识代替不了特定业务场景的深度分析；
• 产品各团队的安全工作资源无法保证，研发团队有理由认为安全团队干扰研发计划，研发进度与资源不变的情况下，额外增加了工作量；
• 安全部门通常没机会参与制订研发计划，产品研发计划与安全脱节；
• 安全团队高度依赖话语权，强制性驱动往往陷入窘境。

 

（图1 安全驱动产品）

​众多的安全实践表明，安全驱动产品的思路与方法存在众多弊端，如果反过来，产品驱动安全，让产品经理明晰自己的安全职责、主动推动产品的安全建设，就会产生对比鲜