一、序言

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

二、背景

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

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

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

1	2	3	4	5
姓名	身份证号	电话号码	银行卡信息	联系地址

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

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

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

三、安全部门的尴尬

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

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

（图一安全驱动产品）

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

四、产品驱动安全的合理性

产品驱动安全并非意味着产品经理单一角色推动产品的安全建设，而是说产品经理主动承担相应的产品安全责任，主动与安全部门一起推动产品的安全建设，由安全驱动产品的单轮驱动转变为产品驱动安全的双轮驱动。如下图所示：

（图二产品驱动安全）

安全是软件产品的天然属性，是产品经理职责的一部分。同时产品经理作为产品规划演进与研发资源投入的指挥棒，可以保证研发团队在安全上的适度投入。通过简单分析，产品经理承担产品安全责任，主动推动产品安全建设应该是十分合理的逻辑。

五、产品如何驱动安全

产品经理有意愿做好产品安全，可能会问如下几个问题：

内容方面，产品经理需要做哪些安全工作；
能力方面，为了完成这些工作，产品经理需要具备什么样的安全能力；
方法方面，这些安全工作如何做，才能既兼顾产品业务功能研发与安全，又能保持研发敏捷性和项目管理流程不变形；
安全资源，从安全部门和其他部门可以获取哪些安全支持，来提升自己和研发团队安全工作的效率和效果，降低安全工作的能力门槛；
工作负担，安全工作会不会让产品经理很辛苦，影响其工作品质和生活品质。

为产品经理解决了以上问题，消除其后顾之忧，产品经理才有可能大概率地拥抱安全，从根本上解决研发与安全间的矛盾。

本文转载自宜信技术学院。

原文链接：http://college.creditease.cn/detail/332

创作场景

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