安全不是主角，中国银联：低侵入、少打扰是高效安全研发体系的前提

在当前金融科技行业中，安全问题已经成为各大公司和机构关注的焦点。随着敏捷模式的普及，由于前台市场需要的是高质量的快速响应，软件研发周期日益缩短，传统的安全措施逐渐显示出其局限性，新的安全策略和方向成为业内热议的话题。如何在研发的早期阶段就整合安全措施，以及如何在整个研发生命周期中确保产品的安全性，是当前面临的两大挑战。

2017 年前后，以“安全左移”为核心的 DevSecOps 概念开始出现，强调将安全测试环节尽量前置，在研发测试过程中完成一些安全工作，给开发留出整改时间，从而避免影响软件上线进度，或导致应用“带病”上线。

但是，安全手段真的是越“左”越好吗？在中国银联技术开发中心安全攻防团队总监蔡水捷看来，事实并非如此。

“安全左移与内生安全都旨在提高产品安全，但责任定位有显著差异。安全左移强调尽早集成安全措施，但过度强调可能导致责任推诿。每个研发阶段都有其特点，而过分侧重早期阶段可能会忽略后期的安全工作。实际操作中应结合组织特点，确保整体安全性，而非仅追求左移。”

在日前的 InfoQ《超级连麦·数智大脑》直播节目中，蔡水捷深入介绍了中国银联的安全研发体系建设实践。他表示，有效的安全措施应低侵入、少打扰，尽量融入到现有的研发流程中。在各个阶段，中国银联都明确了安全的重点，比如，在需求阶段主要关注合规性和数据安全，并设计了易于理解的场景式安全问卷；而在编码和测试阶段，则利用自动扫描和各种测试工具来保障代码的安全。

以下是全文（经 InfoQ 进行不改变原意的编辑整理）：

InfoQ：我们看到，研发安全保障的技术和理念是随着软件研发模式而演化的，根据您在金融行业应用安全领域的多年经验，软件研发模式及背后的安全理念，近年来经历了哪些里程碑式的演变和发展？

蔡水捷：软件研发在历史进程中主要经历了三个核心模式。首先，是传统的瀑布式模式。其次，随着市场对快速响应的需求，敏捷模式应运而生，其中包括结对编程等方法。最后，人们可能最为熟知的就是研运一体化模式，简称 DevOps。

然而，在软件研发模式的演变过程中，安全的发展相对滞后。早期，人们对于软件安全的认知大多停留在工具扫描阶段，即在版本上线或交付前做一次扫描并出报告。如果当时有专业安全人员参与人工渗透测试，那已经算是非常细致的工作了。但随着敏捷模式的兴起，市场对于高质量、快速响应的需求日益增强。传统的上线前的安全检测方式，如发现安全漏洞，往往会处于尴尬的地步，因为交付时间已经确定，此时要么推迟版本上线，要么带有安全隐患上线，都可能对公司的信誉造成损害。

为了解决这个问题，安全工作开始提前介入，不再集中在交付的最后阶段，而是融入到研发测试的中间环节。这样既可以为问题修复留出更多时间，又能保证软件的安全性。进入研运一体化的时代，它的初衷是为了满足软件开发和基础设施管理更高效、可靠的需求，将开发与运维整合在一起，实现持续集成和持续交付。在这个阶段，软件开发所需的基础设施已经相对完善，自动化能力如发布、安装等也日趋成熟。传统的安全检测方式，如黑盒扫描、白盒扫描等，纷纷与流水线集成，进行自动化扫描、开单和跟踪，从而提高信息化程度。

总体来看，随着研发模式的变化和企业基础能力的完善，安全也逐渐从原始的手动扫描转变为更自动化、信息化的方式。

InfoQ：能不能具体介绍一下“左移”和“内生”这两个概念的本质区别？是什么导致谈了这么多年的“安全左移”无法再发挥优势？

蔡水捷：首先，左移和内生本身字典的解释就不一样，一个强调的是移动，将能力赋予下一个对象，一个强调的是内部自我进化。我认为左移和内生本质区别在于责任担当的定位。

我查了一些资料，关于安全左移是何时提出的，有个说法是在 2017 年的 RSAC 会议引入了 DevSecOps 概念，国外某个科技公司负责 DevSecOps 的一个总监的，我也进一步查了这个人的背景，是数据中心出身。包括后来很多人提的左移，大都是站在尽量避免安全测试等在应用系统上线前一刻才做的角度去讲。

将安全越左越好，但是真的是这样吗？我认为不是的，从软件研发生命周期来看，每个阶段都有自己的特点，比如需求阶段，这个时候我们关注的是什么，是需求中侧重安全合规性的内容，因为需求是产品人员、非技术人员写的，我们能说在需求阶段就把后续一系列安全工作包圆了吗？很难。从另一个角度看，我把研发安全的工作堆积到左侧，那右侧是不是不用做了，因为左侧显然从组织分工上也是不现实的。

我认为发展至今，安全左移的优势已慢慢退怯，现在的工作是越来越精细化了，组织结构也是越来越完善，职责边界很清楚，各方都擅长自己熟悉的领域，一味强调左移，造成了安全工作的推诿扯皮，重心都在“我希望在你的地盘把安全做的再好一点，使得自己这一端的压力小一点”。可是凭什么呢？到最后，整体的安全没有多少提升。

InfoQ：中国银联整体的安全研发体系思路是如何设计的？其中有哪些亮点？

蔡水捷：在整合安全保障措施的各个环节中，一个至关重要的前提是企业组织的研发过程必须是完备且相对成熟的。这是因为安全不能脱离研发过程单独存在。如果安全措施过于强硬或太过侵入地插入研发过程，可能会对整个研发产生较大的影响，甚至阻碍整体工作的进展。

安全保障并不是自然而然地存在于每个环节中，而是需要与组织的成熟度相结合。没有了这样的基础，谈论如何自动化或嵌入就毫无根基可言。幸运的是，由于我们的研发过程相对成熟，可以基于现有的技术平台进行工作。在实际操作中，我们遵循的原则是低侵入、少打扰，因为安全不能，也不应该成为主角。

我们的策略是尽量将安全活动融入到研发流程中，明确各个阶段的安全边界。例如，在需求阶段，我们主要关注合规性、数据安全和监管红线等问题。为此，我们设计了场景式的安全问卷，使用业务语言，如“是否使用验证码登录？”或“是否处理身份证号码等敏感信息？”这样，业务和产品人员可以轻松地理解并回答。

在编码阶段，我们的策略已经相对成熟，例如代码入库时自动触发扫描。在测试阶段，我们利用各种工具，如灰盒测试和黑盒测试。关键是，所有这些工作都是基于常用的研发流水线和平台，使其自然地融入研发过程中，对开发的影响也较小。

总的来说，我们的策略确实对开发人员有所帮助。当然，在初步实施安全策略时，我们采取了逐步的方法，首先关注大家普遍关心的问题，然后再逐渐扩大范围。

InfoQ：什么样的研发过程可以被视为“完备和成熟”？它具备哪些核心特点或标准？

蔡水捷：完备的研发过程首先要求企业组织有其自身的研发模式，无论是瀑布式还是敏捷式，都应有一个相对统一和标准的方法论。例如，当需求提交时，应该拆分功能点、进行开发，并在上线前进行变更委员会评审等一系列工作。整个研发管理流程应完备。缺乏这样的流程，谈论安全实际上是没有理论基础的。

只有当组织有了完整的研发管理过程，我们才能在其中找到合适的时机和点，将安全措施融入其中。制度的生命力在于落地执行。这些安全措施能否真正落地，取决于是否有一个数字化的研发平台供所有开发人员使用。

通过这样的平台，结合管理要求，我们可以将安全的自动化工具和其他数字化能力融入其中，形成一个有机组合。否则，任何措施都可能成为空谈。例如，一个组织如果没有任何流程，随性而至，那么在这样的环境下很难说要全方位开展安全工作的。可能只会在最后关头进行简单的安全扫描。所以，这些基础设施是推动安全实施的关键，不能被忽视。

InfoQ：在从设计、编码、测试到发布的整个开发流程中，涉及到的各个角色比如开发、设计和测试等等，大家都有自己的关注点。如何平衡这些不同角色的需求和关注点呢？

蔡水捷：为了确保研发过程中的安全，深入地调研是必不可少的。在需求阶段，与需求和产品人员的沟通显得尤为重要。当前的大环境下，监管要求日益严格，而需求和产品人员对此也持关注态度。他们同样希望产品能够做到安全。因此，这为安全团队提供了与他们沟通的契机，可以从安全的角度分享多年来内外部发生的安全风险事件。

例如，当涉及到个人敏感信息时，如何确保数据安全和加密需求成为关注焦点。这时，安全团队需要与业务方明确如何进行数据脱敏，以及脱敏后可能对业务带来的影响。引导业务和产品团队意识到敏感信息的脱敏是非常关键的。

在这个阶段，安全团队主要的任务是启发式地帮助他们框定在做需求时应考虑的安全点。有的产品或需求人员由于资历较老，可能已经踩过一些安全的坑，他们可能会自然地将安全因素考虑进需求中。但对于资历较轻的人员，他们的安全意识可能存在差距。这时，安全团队可以设计一些安全问卷，但问题数量不宜太多，大约 7-10 个问题，帮助他们框定安全考虑点，确保不偏离安全红线。

总的来说，如果一个团队在进行前期需求和设计时能综合地考虑到安全因素，并规避安全和合规红线，那对于整个开发部门而言，已经是很大的幸运了。在这个阶段，我们不能对他们的安全意识要求过高。只要他们能按照给定的框架去思考，并确保不违反相关规定，那就已经达到了我们的目标。

InfoQ：在数字化转型的过程中，经常听到业务方向技术方提出的所谓“伪需求”，即那些看似重要但实际上并非真正业务需求的请求。在安全领域中，是否也存在类似情况？

蔡水捷：对于业务方提给安全侧的需求，实际上并不能简单称之为“伪需求”。当业务人员在填写我们提供的安全问卷时，这个过程实际上已经促使他们进行了一次自我思考。例如，当问卷询问“是否采集个人敏感信息”时，业务人员在选择“是”或“否”的过程中，其实已经对自己的业务需求进行了一次反思。

我们的问卷背后有一个完善的知识库，涵盖了各种合规要求和相应的最佳实践方案。因此，业务人员提出的需求大多数都能在知识库中找到匹配。当然，也存在一些之前未被考虑的需求，这对我们来说，实际上是一个机会，促使我们更进一步思考是否有遗漏。

如果真要说安全领域的“伪需求”，我认为更多的是过度保护。但这种过度保护是可以通过引导和沟通来调整的，确保既满足安全要求，又不妨碍业务的正常运作。

InfoQ：您提到了在各个阶段明确划分安全边界的重要性。如何具体界定这些边界，并确保过程中避免双方就责任界定产生争议？

蔡水捷：关于各个阶段明确安全边界的问题，我们首先要确定的是问题导向。在软件研发的生命周期中，每一阶段我们都要清晰地知道我们在安全方面关心的是什么。以需求阶段为例，安全人员应该明确在这个阶段希望解决或发现什么安全问题。

例如，在设计阶段，我们作为安全人员期望的是一些关键的安全设计方案，如数据加密。我们希望开发团队能使用统一的加密算法和组件，而不是自行设计。在这个阶段，我们的目标并不是要求开发团队详细展示如何调用这些组件，而是确保他们在设计中纳入了这些安全要求。

进入编码阶段，职责转变。如果我们在设计阶段规定要使用某种统一的加密组件，那么在编码阶段，我们的任务就是检测开发团队是否真正地使用了这个组件。例如，如果我们要求使用国密算法而不是国际算法，那么在编码阶段我们要验证代码中是否存在任何国际算法。

简而言之，设计阶段我们提出安全要求，而编码阶段我们验证这些要求是否得到满足。通过问题导向的思路，我们可以更清晰地界定每个阶段的安全工作要点，确保整个流程的安全性。每个阶段都应有明确的安全目标，并采取相应的措施来实现这些目标。

InfoQ：要实现全生命周期的有机联动，不仅需要引入新技术，还涉及人、文化、流程等各个关键点，在中国银联实施和落地内生安全研发体系的过程中，最大的难题和挑战有哪些？

蔡水捷：首先，在我们的实践中，安全与发展的动态平衡是最大的挑战。尽管适可而止很重要，但实现它并不容易。由于工种的差异，对同一事物的看法和处理方式可能各不相同。以需求阶段的安全为例，我们最初采用了等保要求中的 Checklist。为了确保全面性，其中包含了许多安全术语，这对非安全人员来说可能难以理解。

尽管我们的初衷是好的，但实际效果并不理想。有的人认为安全团队是在甩锅，有的则彻底放弃，只关注自己的工作。这种做法并没有助于提高研发的安全性。为了解决这个问题，我们与需求和开发团队进行了深入沟通，并进行了反思。我们考虑了研发和安全各方的需求，最终形成了一个以业务场景为切入点的轻量化威胁建模方案。用大家都能理解的语言来描述安全问题，并提炼出大家关心的内容，如合规和数据安全。通过长期的实践和反馈，逐渐形成了共识。

其次，各阶段安全活动的联动是另一个较大的挑战。各阶段的安全活动如果没有联动，那还是一座座孤岛，各自为政，难以发挥乘数效应。安全已经从粗犷发展到精细化，我们需要考虑如何提高效率，而不是不管什么样场景，一成不变地使用同样的安全方法。软件研发来源于各种需求，每个需求都包含了不同的功能。对于安全而言，这些功能就是当前需求的安全重点。我们需要考虑如何将这些重点分散到后面的各个阶段，并验证前面的工作是否真的达到了预期。

为了做到这一点，我们需要非常了解安全工作的特点。例如，需求中提到的自建用户体系，我们在需求阶段需要考虑密码存储、登录方式、账户锁定等功能。在设计、编码和测试阶段，我们还需要考虑对应的方案、密钥存储方法、验证码设计、关键函数的使用和检测等问题。

最后，在建设过程中，我们还面临着许多其他挑战，如工具检测的准确率和闭环验证手段等。我们仍然在不断地探索和前进。

InfoQ：前沿技术的发展（尤其是 AI 大模型）会如何塑造和影响未来的研发安全模式？

蔡水捷：我认为现有的研发安全模式已经趋近于一个发展的天花板。大部分的工作都在做细化和优化。然而，新兴的技术可能会引发一些变革。例如，当前兴起的 AI 技术和大模型可能会将研发工作推向一个全新的领域。我们已经开始尝试使用 AI 进行需求分析，根据需求特点开展安全工具自动编排。此外，我们还在探索 AI 的其他应用，如安全知识图谱，自动修复漏洞等。

研发安全当前及过去都是在出现了新的研发模式后随之产生的，随着新技术发展及安全环境的变化，很有可能出现安全推动新研发模式的产生。

总的来说，虽然 AI 技术为研发安全带来了新的机会，但也带来了新的挑战。我们应该保持警惕，不断探索和学习，以确保在利用新技术的同时，也能确保安全。

关于 FCon

首届FCon全球金融科技大会将于 11 月 19-20 日在上海举办。本次大会已邀请到工商银行、招商银行、汇丰银行、兴业银行、中信银行、北京银行、平安人寿、度小满、蚂蚁集团等业界知名银行以及金融机构的大咖，前来分享大模型、 Web 3.0 、隐私计算、数字货币、区块链等前沿技术在金融领域的落地案例。

我们诚挚地邀请您加入我们，共同探索金融科技的未来，扫码或点击链接即可查看全部演讲专题。

目前是 8折特惠购票，报名立减 ¥1360，咨询购票可联系：17310043226（微信同手机号）。