安全公司内部博弈：红蓝对抗、SRC与合规的平衡之道

1. 红队和蓝队，真不是外人想的那种"同一个战壕"

我在安全行业待了快十年，前几年一直在想一个问题：为什么一家对外号称"铁板一块"的安全公司，内部打起来比攻击客户系统还狠？

后来我想明白了。对外的时候，红队和蓝队当然是一个战壕的兄弟——客户被攻破了，大家一起丢脸。但对内的时候，这两拨人的KPI、工作习惯、甚至思维方式根本就是拧着的。红队的天职是"证明系统能被攻破"，蓝队的天职是"证明系统没那么容易被攻破"。这两个目标听着不矛盾，落到实处全是矛盾。

先说最表象的东西：考核指标。

看到没，一边觉得"我多挖出一个严重漏洞，说明我工作做得漂亮"，另一边心里想的却是"你多报一个严重漏洞，我这周就得加班加点上应急，还得跟业务部门解释为什么又要改配置"。这不是谁对谁错的问题，是两者在企业里的生存逻辑不一样。

我自己经历过最典型的场景，是一次大型护网行动结束后的复盘会。红队在演练期间利用一个边界设备的未授权访问漏洞，直接打穿了内网，拿到了核心业务服务器的权限。演示的时候全场安静，大家都觉得漂亮。可到了复盘阶段，蓝队负责人当着所有领导的面问了一句："这个漏洞我们之前就知道，也在排期修复，你们为什么不能提前告诉我们，非要留到演练的时候打？"

红队那边也不退让："提前告诉你们，那还演练什么？我们负责模拟真实攻击者，真实攻击者会提前打招呼吗？"

这个对话基本就是两个团队日常状态的缩影。红队觉得蓝队"就知道捂盖子"，蓝队觉得红队"就知道搞突然袭击，根本不管业务死活"。两边都有道理，但两边都觉得自己受了委屈。

后来我在好几个公司见过同一个解法，效果都还行：把红队提交漏洞的流程里加一个强制字段——"漏洞已知状态"。如果是已知漏洞，红队必须说明为什么不相信蓝队的修复方案、复测结果是什么、问题出在哪一环。这个字段平时没人愿意填，但它逼着红队从"为了打穿而打穿"变成"帮蓝队把修复闭环堵上"。说白了，红队存在的价值不是制造恐慌，而是让蓝队知道自己哪里真的会出事。

这里我还想多说一句，很多人把红蓝对抗理解成"两边拼命给对方找麻烦"，这是不对的。真正良性的红蓝关系，应该像拳击陪练——一方出拳，一方防守，但目的是让双方都变强，不是为了把对方打住院。可惜很多公司的考核制度设计出来之后，实际效果就是让两边往死里打。

2. SRC平台里的暗流：白帽、运营方和企业之间的"三方博弈"

聊完内部的红蓝，再说一个外人不太容易看到但同样暗流涌动的场景——SRC平台，也就是漏洞响应平台。这几年"反正有SRC"成了不少安全公司的标配，对外宣传都是"我们拥有上万名白帽黑客组成的众测社区"，听起来很风光。但SRC平台的运营内部，几乎每天都在进行一场三方博弈。

这三方分别是：提交漏洞的白帽、审核漏洞的运营方、以及花钱买了漏洞报告的企业。每一方都有自己的小算盘。

白帽的想法最简单直接：我花时间挖洞，挖到了高价值漏洞，凭什么只给我几百块钱的积分奖励？尤其是那些明明可以造成严重影响的漏洞，被运营方以"业务影响有限""利用条件苛刻"为由降级，那种被压价的感觉，做过SRC的人应该都懂。

运营方的难处在于，他们要同时安抚两边。一边压低漏洞评级，企业方就高兴，因为要付的钱少了；但压得太狠，白帽就不来了，平台就没内容了。另一边，如果漏洞评级给得太高，企业方会觉得平台在"吃里扒外"，帮着白帽薅甲方羊毛。两头受气的活，做久了真的会怀疑人生。

企业那边呢，也有自己的心思。他们希望SRC平台不仅是发现漏洞的渠道，还能帮忙做漏洞情报共享、做行业风险预警。但一旦涉及情报共享，就又碰上了归属权的问题——这个漏洞是白帽发现的，平台运营方有没有权利把漏洞信息同步给同行业的其他公司？如果不经过白帽同意就共享，白帽会觉得自己的劳动成果被白嫖了；如果每次都要征求同意，共享的效率又大打折扣。

我做过的几个SRC项目中，踩过最深的坑是"漏洞定级标准"这个东西。你以为定级标准是一份文档？不是。文档是写给别人看的，真正执行的是一套动态的、灰色的心证体系。同一个漏洞，在不同季度、不同预算周期、不同运营人员手里，最后给的等级都可能不一样。原因很简单：SRC平台的漏洞奖励预算有限，上半年花多了，下半年就得收紧。

所以我给想入驻SRC平台当白帽的朋友一个实在的建议：提交漏洞之前，先翻翻这个平台过去三个月的历史漏洞公示，看看同类型漏洞通常给什么等级。如果发现你的漏洞明显比公示里那些级别更高，却被降级了，该申诉就申诉，不要怕得罪人。申诉不仅是维护你自己的利益，也是在帮平台把定级标准逼向透明。

另外，从运营方的角度，我也想说一句公道话：SRC平台不是慈善机构，它本质上是一个"用最低成本获取安全情报"的商业渠道。白帽不要对平台抱有过高的道德期待，把它当成一个正常的交易场所就好——你提供漏洞信息，它提供奖励，双方在商言商。反而一旦把关系搞成"雇佣兵和雇主"，麻烦就来了。

3. 安服交付现场的多方角力，每一个项目都是一场小规模战争

如果说红蓝对抗和SRC博弈还停留在"脑力对抗"层面，那安服项目交付就是实打实的"肉搏战"了。我以前带过一个安全评估项目，深刻地体会到了一个道理：安全公司的内部争斗，很多时候不是发生在安全技术团队之间，而是发生在销售、项目经理、交付工程师这三类人之间。

销售关心的是签单。为了把单子签下来，他们什么服务内容都敢承诺——"没问题，我们提供全面的渗透测试""行，应急响应7×24小时随叫随到""这个合规报告我们包了"。交付工程师关心的是技术标准——"客户这个需求根本不是渗透测试的范围，这是开发工作""7×24小时应急？我们团队就四个人，晚上不用睡觉了？"项目经理夹在中间，关心的是成本和验收——答应了做不到，客户不签字；不答应，销售那边又说你破坏客户关系。

这种三角关系几乎在每一个安服项目里都会炸一次。我印象很深的一个项目是这样的：销售在签单时口头答应了客户，"顺便"帮忙做一次暴露面排查。这个"顺便"没有进合同，也没有预算支撑。到了交付阶段，客户拿着销售的口头承诺来找项目经理，项目经理说合同里没有，客户转头就投诉到销售那里，销售又回头骂项目经理"不会变通"。

最后的结果是，交付工程师在本来就排满的排期里硬挤了三天时间做暴露面排查，质量可想而知——报告里全是系统默认模板的套话，真正有价值的发现没几个。客户不满意，工程师觉得委屈，项目经理觉得里外不是人，销售觉得自己只是"为了公司业绩"。

后来我带团队的时候，强制做了一件事：任何项目，售前阶段必须有交付团队的负责人参与方案评审。销售可以说"这个客户很好沟通"，但交付团队必须在签单之前看到明确的服务范围、交付物清单、工期和验收标准。但凡交付负责人在评审会上说"这个做不了"，销售就得回去改方案，要么缩小范围，要么提价。这一条刚开始推的时候，销售叫苦连天，说流程太重、客户等不了。但实际跑了大半年之后，项目的亏损率明显降下来了，客户满意度反而更高了。原因不复杂——承诺设得合理，交付自然靠谱。

这里还要补充一个很多安全公司没有意识到的问题：项目亏损往往不是技术不行，而是"范围蔓延"失控。客户今天提一个小需求，明天提一个小改动，每个看起来都不大，但累计起来就是半个月的工时。所以安服交付内部一定要有一个边界变更机制：合同外的需求可以接，但必须走变更审批，明确增加工期或者费用。别觉得这是小题大做，边界不清的项目做到最后，往往就是工程师用爱发电、公司赔本赚吆喝、客户还觉得你服务不行。

4. 合规团队和研发团队的拉锯战，本质是"标准"和"效率"的碰撞

再聊一个近两年越来越多安全公司需要面对的内部矛盾——合规团队和研发团队之间的拉锯。这个矛盾在传统安全公司里就存在，但随着等保合规、数据安全法规越来越细，安全公司自己也成了被监管的对象，这组矛盾就更加突出了。

合规团队的工作逻辑是什么？是"标准优先"。他们脑子里装的是等保2.0的要求、数据分类分级的规范、日志留存时长的底线。他们的职责决定了他们必须对"不合规"零容忍——哪怕某个风险发生的概率只有万分之一，只要不符合标准，就得整改。研发团队的工作逻辑是什么？是"效率优先"。他们的核心目标是把功能做出来、把版本发布出去，让客户用上。在他们看来，合规团队提的很多要求——"先做安全评审再提测""这个接口不能返回完整手机号""日志必须加密存储"——都是在给自己添堵。

这种碰撞在每一次版本发布前都会集中爆发一次。研发说"就一个小功能，有必要每次都做安全评审吗？"合规说"上次就是因为小功能没评审，把数据库备份文件暴露到了公网"。研发说"客户等着上线呢，出了问题我担着"合规说"你担不起，出了事是公司担着"。

我见过最极端的一次，是研发负责人直接绕过合规团队，把代码部署到了生产环境。理由是新版本修复了一个紧急bug，等不了一整轮安全测试。合规团队发现之后，向上汇报，最后这个研发负责人被通报批评。但有意思的是，没过多久，其他项目组私下里都在说"他做得对，换了我我也这么干"。

这个案例说明，单纯的"堵"解决不了问题。合规和研发的矛盾，本质上是公司内部对"风险容忍度"的认知不一致。合规团队假设所有风险都是不可接受的，研发团队默认大部分风险都不会真的发生。真正有效的调和方式，不是让某一方妥协，而是建立一套"分级响应"机制。

以我个人的经验来说，最靠谱的做法是把安全动作前置到需求阶段。不是等代码写完了才去做安全评审，而是在产品经理画原型的时候，安全人员就参与进去，评估这个功能会涉及哪些数据、存在哪些风险、需要什么安全措施。这样合规团队的角色就从"结尾挑刺"变成了"前期把关"，研发团队也不用在临上线前被突然叫停。另外一个很实用的做法是，把厚厚的安全制度文档改成一页纸的"安全红线清单"，只写明什么东西绝对不允许做、什么东西需要提前申请。研发没时间读几十页的合规手册，但一张贴在工位上的红线清单，大多数人还是愿意瞄一眼的。

顺便说一句，最近一年大家应该也注意到了，等保相关的政策要求一直在动态调整，新的细则不断出来。做合规的同行如果还抱着"查一次配置、写一份报告就完事"的心态，后面会非常被动。合规工作必须从"一次性评估"变成"持续运营"，不然每次新规出来，研发团队又是一顿鸡飞狗跳，然后这锅又扣到合规团队头上。

5. 预算、漏洞库与人才争夺战，安全公司里最看不见硝烟的战场

前四个章节聊的都是部门之间的理念冲突，但安全公司内部还有一类争斗更加隐蔽——资源层面的争夺。这个资源包括三样东西：钱、知识、人。

先说钱。安全公司每年的安全预算怎么分，基本就是一个内部博弈的结果。买漏洞情报服务要钱，建设内部安全测试平台要钱，搞攻防演练要钱，做合规认证要钱，公司的产品研发也要钱。蛋糕就那么大，每个团队都说自己的项目最紧急。这里面最吃亏的往往是那些"见效慢但长期有价值"的项目，比如漏洞知识库的沉淀、内部安全自动化工具的研发。因为这类项目的收益要一年甚至两年后才能看到，在年度预算评审会上，很难跟"下个月就要交付的合规项目"抢资源。

再说知识。安全行业是一个极度依赖个人经验和隐性知识的行业。同样的一个漏洞，新人和资深研究员看到的深度完全不同。问题在于，这些经验绝大多数存在个人脑子里，没有沉淀成公司资产。一个资深研究员离职，他脑袋里的那些攻击思路、踩坑记录、目标系统的薄弱点判断，就全都带走了。这是安全公司"内部损耗"最严重的地方，但它平时不会表现在任何一张报表上。

我自己经历过一次特别肉疼的知识流失。团队里一个核心的漏洞研究员离职，他走之前没有留下任何技术文档——不是他不想留，是公司平时就没建立这个机制。他走了之后，我们花了大半年才把他一个人撑起来的那块业务重新理顺。那半年里，我每天都在想一个问题：如果这家公司明天所有核心技术人员都离职，我们的技术能力还剩下多少？

最后说人。安全行业的人才争夺战有多激烈，应该不用我多解释。稍微有点名气的安全研究员，几乎每周都会收到猎头电话。公司内部好不容易培养起来的新人，刚能独当一面，对手公司就开着双倍薪资来挖。更微妙的是，安全公司内部不同团队之间也在争人——攻防研究团队和产品研发团队都想要安全能力强的工程师，最后往往变成内部互相挖墙脚。

这三样资源之争，让安全公司内部的管理复杂度远超一般软件公司。不同团队之间的信任本来就脆弱，一旦扯上预算和人事，矛盾就会成倍放大。我见过不少安全公司，对外宣传是"技术驱动"，到了内部开会，全是资源分配和人事斗争的戏码。技术问题反而没人关心了。

要解决资源层面的内耗，我觉得最核心的一点是建立"知识不随人走"的机制。具体来说，就是强制性的技术文档沉淀和定期技术分享。不用搞得多复杂，哪怕每季度每人写一篇自己项目中的技术总结，放到公司内部的wiki上，长期积累下来的价值都是巨大的。同时，在做预算分配的时候，最好有意识地把一部分资源投给"看不见的"基础设施——比如内部漏洞库、自动化检测脚本库、知识管理平台。这些东西短期看都不出成绩，但它们是降低公司对个别核心人员依赖的关键。

6. 内部争斗的正面价值：把对抗变成制度化训练

说了这么多，我得说句公道话。安全公司内部的争斗，并不全是坏事。红蓝对抗本来就是安全行业安身立命的根本，如果公司内部连一点对抗性都没有，那做出来的安全产品大概率也是软绵绵的。问题不在于"内部有斗争"，而在于"斗争是失控的还是可控的"。

我见过做得最成功的公司，他们的做法是把内部对抗"制度化"。什么意思？就是不让红队和蓝队靠个人自觉去化解矛盾，而是设计一套固定流程，让对抗在规则之内进行。

几个我实际验证过有效的手段，分享给大家。

第一个是红蓝联合复盘机制。每次大型攻防演练或者渗透测试项目结束之后，红队和蓝队必须坐在一起，逐条过一遍发现的漏洞，明确每条漏洞的根因、影响面、修复方案和复测结果。关键是这个复盘不是走过场，报告要存档，且作为两个团队绩效考核的共同依据。这样一来，"红队打出来的漏洞"就变成了"红队和蓝队共同承担的改进项"，对抗的矛头就从人和人之间转到了问题和问题之间。

第二个是轮岗制度。别把这个想得多复杂，其实就是让红队成员每年抽一段时间去做蓝队的活儿，让蓝队成员反过来参与红队的渗透测试。轮岗之后你会发现，很多原来觉得对方"不可理喻"的行为，自己上手做一遍就全明白了。红队会发现原来修复一个漏洞要协调那么多业务部门，蓝队会发现原来很多漏洞在真实攻击者面前根本不堪一击。这种同理心带来的理解，比任何团建都管用。

第三个是安全工程效能仪表盘。把从漏洞发现、漏洞确认、漏洞修复到复测通过的整个链条用数据可视化呈现出来，哪一环卡住了、平均耗时多久、哪个团队响应最慢，全都摆到明面上。这比开会互相指责客观得多——数据不会哪边是亲儿子，它只会诚实地展示瓶颈在哪里。

最后想说说安全团队负责人的角色。在所有这些矛盾里，负责人是最关键的一个变量。如果负责人只会和稀泥，今天哄红队明天哄蓝队，那内部争斗就永远是内耗；如果负责人能顶住压力，为跨团队的长期价值项目争取资源，为知识沉淀建立制度，为定级标准定下明确的尺子，那所谓的内部争斗就会逐步转变成公司安全能力的一部分。说白了，安全行业天然需要对抗性思维，关键是要让这股对抗的力量朝外，而不是朝内。

在我自己带团队的过程中，还有一个特别深刻的体会：很多争斗的根源，其实是大家太忙了，忙到没有时间好好听对方说话。红队打穿了一个系统，蓝队说"我们早就知道了"，这句话背后其实是委屈——"我们想修，但没有资源、没有优先级"。如果管理者能创造一个人人都愿意把这种委屈说出来的环境，而不是让它们积累成怨气，很多所谓的内部争斗在萌芽阶段就可以化解。

网络安全这个行业，本质上是跟人脑子里的恶意对抗。我们自己内部要是先乱了阵脚，那拿什么去跟外面那些真正的攻击者打呢。