在接触不同的客户中，发现很多客户在采购安全产品后，都面临一个同样的问题：不知道如何落地，或如何规模化地应用到企业内部。公司规模越大，这样的问题越明显，而主管和负责安全的人往往缺少相关的经验，或缺少非安全工作的经验，一旦做不好，不仅没有能够将安全水平提升，还会面临其他部门的埋怨，比如研发部门或测试部门向公司上层投诉，称安全部门采购或使用的某某产品导致研发进度受阻、效率降低，或影响测试效果和测试进度，最终影响到产品上线。高层听闻这样的消息，第一反应肯定是要为正常的业务开展考虑，虽不至于当时便影响到安全部门，但久而久之，类似事件发生多次之后，安全部门的形象和话语权都会受到影响，最终可能成为纯技术执行部门，被动地执行重复的安全测试工作，同时承担着超出自己权力的责任。

安全产品的落地，不同于业务支撑类的产品。安全产品的目的是为了增强企业某个方面的安全能力，是锦上添花的效果，而业务支撑类的产品，往往是雪中送炭的效果，比如CRM系统、ERP系统或广告投放。因此在企业采购预算和采购顺序中，安全产品常常是靠后的，也就是安全采购往往不会在一年的Q1开展，待其他采购进度差不多之后，才会考虑安全产品的采购，甚至由于预算超标放弃安全产品采购也是常有的事。

一旦采购安全产品，企业接下来需要做的是能够让安全产品发挥出其应有的价值，无论是安全防护、安全检测，还是安全预警。如果是只是供安全部门自用的、独立的安全产品（如Burp Pro、IDA Pro等），并不存在落地困难的问题，但如果是部署和应用会影响到业务和其他部门（如终端防护、准入系统、IAST、SCA、SAST等），便需要慎之又慎，因为这些产品的部署和应用需要改变或影响到其他部门和业务线原有的工作方式，比如DLP产品，在很多企业内部没有大规模应用和部署，便是由于它会严重干扰和影响员工的日常办公，时不时弹个提示框等等。

本文所指的是后一种安全产品的落地，由于不同的企业有各自的文化、管理、结构和资源，因此下文只谈及落地的思路，而非具体的方案。结合本人接触的不同客户的情况，通常而言，一款安全产品要真正的大规模应用和落地，需要进行以下步骤。

理清现状，确定目标

作为落地的推动者，安全负责人或相关负责人需要对于企业自身的现状有清晰的了解，包括组织结构、研发流程、业务类型、业务复杂度、研发水平、测试水平、运维水平等，以及公司文化、氛围和管理风格。尤其重要的是了解产品落地需要配合的相关部门和负责人的情况，哪些人是积极的，哪些人是被动的，哪些人是抗拒的。了解和熟悉这些可以帮助选择产品落地推动的方式，甚至判断采购哪一类的安全产品，比如：公司文化是保守的、按部就班的，那么便不能通过行政命令来推动产品落地，如果研发水平不佳；CICD流水线还未建立，那么采购IAST这种交互式安全检测产品便无法充分发挥其能力，达到理想效果；如果相关部门负责人对安全是抗拒的心态，那么苦口婆心地劝导其部门落地是收效甚微、难见成效的。

在此基础上，需要基于已经采购的安全产品确定推动和落地目标，如果企业规模非常大，一口吃个胖子显然会被撑到，不如按照年度划分目标，比如今年做SAST白盒产品某某事业部的落地，明年做另一个事业部的推广。有的企业迫不及待地将采购的安全产品大面积部署和应用，后续会面临安全风险或漏洞太多，无人跟进和解决，或者影响面太大，导致各个部门不满的声音越来越多，安全部门骑虎难下。

无论是何种规模，安全产品的落地和推广都需要以点带面，逐渐应用。这其中选择这个点很重要，点的选择需要具备两种条件：相关业务或部门是公司的核心业务或部门，不能是边缘业务和部门；相关部门负责人对于安全的态度是积极的、欢迎的。这两点的具备，可以在单点案例建立并成功后，更好、更顺利地和其他业务和部门宣传，且在过程中会优先解决大而难得技术问题和落地问题，其他业务和部门的落地遇到大的技术难题和应用难题的概率会降低。

优化产品，降低误报

确定某个业务线的某个部门作为安全产品试点之后，一段时间之内只需要跟进该试点的产品应用情况即可，这样不仅可以降低安全部门的成本，还可以快速和安全厂商反馈、互动和调整产品，避免大而多、多而杂的问题扔给厂商后，安全厂商无法在短时间内给出解决办法，或修复周期过长，影响到产品落地的计划，其他部门对产品的评价，甚至公司安全建设目标。

试点部门由于其重要性和关键性，即便产品有瑕疵或缺陷，其反馈的问题也是集中的、有效的、真实的，可以较快的应对和解决。如果涉及到安全检测或防护能力，可以在试点应用过程中，调整产品规则，降低产品误报率，由于同一家公司技术栈的相似性或业务的相似性，即便后期应用到其他业务线，也不会产生过大的误报偏差。之所以强调误报率，是对于企业而言，不可能依赖一款产品来解决相应维度所有的安全问题，误报率低可以同时降低安全工作的时间成本，提升其他部门对于安全工作的信赖度，而误报和漏报不可兼得，如果过于看重漏报率，同时误报率过大，久而久之，不仅安全工作面临大量的工作量，同时其他部门也会失去对安全产品检测结果的信赖，工作量大便意味着安全工作无法快速跟上业务发展的节奏，比如提测的系统需要在3天后发版，但是安全漏洞分析工作7天之后才结束。相同维度的安全检测，可以结合不同方式的检测能力和安全产品，比如软件安全，可以是白盒、灰盒、黑盒、组件、RASP、WAF等多种检测和防护维度的结合做安全检测和防护。

这一步的目标是能够让安全产品的结果让试点部门直接接受，而无需经过安全部门的分析、过滤和再处理，误报率的标准需要安全部门和试点部门达成共识（如20%），但绝对不可能是0。有的企业出于慎重考虑，会让安全产品的检测结果先经由安全产品做分析、处理，而后再同步相关部门解决和修复，如此不仅增加了安全工作量，还会造成安全相对于业务发展的延迟，比如第n天安全部门接收到检测出的100个漏洞，经过分析，前40个漏洞都是误报，并与第n+3天将验证后的真实漏洞同步至研发，而研发在n+1修改了代码，修复了该漏洞，但同时新增了2个真实漏洞，而这2个漏洞又需要在下一轮检测时才能够被发现。

融入流程，优化效率

现如今很多安全产品都需要和企业已有的流程或系统打通或对接，在上一步之后，安全产品已经确认具有企业可以接受的功能质量和安全检测/防护质量，便可以将产品融入到企业的相关流程。在这个过程中，对于企业已有流程的了解，能够对融入流程的效果有一个大概的预期，即最终效果应该是如何提升安全能力覆盖面，和降低安全工作成本。多数安全部门会在这个阶段才真正了解和熟悉相关的流程和机制，通常情况下，需要基于已有的流程和机制改变安全产品的接入方式和流程化方法，另外一些安全部门，能够借用融合流程的机会，重塑、升级和优化现有的流程和机制，不仅能够提升安全覆盖面和安全能力，同时能够提升业务效率，降低公司成本。比如，有的企业在正式交付产品给客户之后，客户会对于交付的产品进行安全检测，对于发现的安全漏洞需要企业做修复后再升级或再部署，增加了产品交付成本和周期。

又比如，终端防护产品的安装，可以结合IT部门或行政部门的电脑设备准备和发放一同进行，有的公司原本没有统一的员工电脑分配制度，甚至可以借该机会，为了解决终端安全风险问题，同员工效率和资产管理一并考量，并最终建立员工电脑分配制度。

以点带面，逐渐铺开

在试点工作取得阶段性成功后，安全产品的融入不仅可以提升产品安全性，降低安全工作成本，还能够对于其他业务和部门形成正面影响。利用试点的产品、方案，可以很容易地在不同的业务和部门落地。

在铺开的过程中，如果完全没有任何产品和方案的问题也是不大可能的，但由于试点工作的完成，大的问题已经大概率被解决，其他的问题在逐渐落地的过程中得以逐个处理和攻破，不至于让安全部门和安全厂商面临多重压力。

安全监测，效果评估

在逐渐推广和落地安全产品的过程中，需要记录、统计、分析安全产品的落地效果，评估产品采购的价值。有的产品采购并应用之后，可能没有发现任何的安全问题，或是发现安全问题后无力应对，以至于最终成为一种摆设。

以安全漏洞检测类产品为例，可以评估的维度包括：

  • 同一个业务的安全漏洞数量在降低；
  • 同一个安全漏洞类型的数量在降低；
  • 同一个安全漏洞类型的危害等级在降低；
  • 整体的安全漏洞数量在降低；
  • 整体的安全漏洞危害等级在降低；

企业安全建设是“三分技术，七分管理”不无道理，良好的运营和管理，甚至可以不借助任何三方安全产品的前提下，取得公司安全性提高的结果，和公司管理层安全感提高的效果（能够天天睡个安稳觉）。在安全工作中，企业的安全部门和安全产品的厂商是一条线的，一荣俱荣，一损俱损。合理调动资源，借用安全厂商的经验和能力，可以高效地构建安全体系。