干了这么多年安全行业，我一直觉得有个话题特别有意思，但很少有人摊开了聊——就是网络安全公司内部的那些争斗。
这行在外人看起来挺光鲜的：白帽黑客、攻防演练、0day挖掘、CVE编号，听着就带劲。但你真在一家安全公司待上两三年就会发现，真正难的往往不是技术，而是人。资源就那么多，话语权就那么多，谁的项目上、谁的人多、谁的预算足、谁在老板面前说得上话，这些事天天都在发生。
这篇文章我不想写成那种“职场厚黑学”的鸡汤，而是想结合我这些年看到、听到、亲身经历过的场景，把安全公司内部争斗的根源、典型戏码、背后的逻辑，以及作为普通从业者怎么在这种环境里活下来还把事情做成，都拆开聊一遍。如果你是准备入行安全圈的学生，或者刚跳进某家安全公司的新人，又或者是想搞清楚自家公司为什么总是“内耗”的团队管理者，这篇应该都能给你一些不一样的视角。
1. 争斗的根源：安全公司为什么特别容易“内耗”
先别急着吐槽公司政治，我们得先想明白一个问题：为什么安全公司内部的争斗，比一般软件公司更明显、更频繁？
我自己的观察是，核心在于安全行业有三个天然矛盾，这些矛盾是行业属性决定的，跟具体某家公司没关系。
1.1 稀缺资源分配：安全公司的“人”就是生产资料
安全公司靠什么赚钱？靠人。产品可以标准化，服务可以标准化，但真正的核心竞争力还是那批能打的人——能挖洞的、能逆向的、能应急响应的、能跟客户吹方案又能落地的。
问题来了，这批人是稀缺的，而且他们之间是高度不可替代的。一个优秀的渗透测试工程师，和另一个优秀的渗透测试工程师，可能擅长的方向完全不同；一个能扛事的项目经理，可能整个公司就那么两三个。所以安全公司内部的资源争夺，本质上就是对“人”的争夺。
一个项目要启动，要人；一个新产品要研发，要人；一个实验室要出成果，也要人。但人就那么多，怎么办？要么抢，要么等，要么招。抢人这个过程，就是争斗的第一个爆发点。我见过为了一个核心研发的档期，两个事业部负责人在总裁会上拍桌子的场面，也见过私下挖人、给高薪给Title留住核心骨干的桥段。这些在安全公司里，太常见了。
1.2 理念路线之争：攻防实战派和产品商业化派的天然对立
安全公司内部，尤其在技术团队里，常年存在两条路线的拉扯。
一条是“攻防实战派”。他们受黑客文化影响，崇尚技术、追求极限，认为真正的安全能力是打出来的，不是吹出来的。他们喜欢研究最新的攻击手法，喜欢挖掘0day，喜欢在攻防演练中把防守方打到怀疑人生。
另一条是“产品商业化派”。他们以商业成功为导向，认为安全最终要变成产品、变成服务、变成收入，技术再牛如果不能产品化、不能规模化，那对公司来说就是成本，而不是资产。
这两派的人坐在同一个会议室里，看问题的角度完全是反的。实战派觉得商业化派只会包装概念、收割客户韭菜；商业化派觉得实战派只会花钱、不懂市场。这种理念冲突在安全公司里面不是偶发事件，而是日常。
1.3 KPI错位：不同岗位的考核目标天然就是打架的
还有一点特别要命，就是KPI。你去看安全公司的岗位设置，会发现它们的考核目标天生就互相矛盾。
销售和售前的KPI是签单、是回款，所以他们会想尽一切办法满足客户的需求，哪怕有些需求在技术上根本不靠谱；交付和服务的KPI是项目成功、是客户满意度，所以他们希望销售少承诺、别挖坑；产品和研发的KPI是功能上线、是稳定运行，所以他们希望需求别老变，最好一个版本开发三个月；而攻防研究团队的KPI是出成果、发报告、拿CVE，所以他们希望你给我自由，别天天让我改Bug。
你看，这些目标放到一起，天然就是冲突的。销售为了拿单承诺了一个“等保整改包过”，交付在现场被客户喷成筛子；产品经理为了赶版本砍掉了红队提的底层安全能力，结果客户一打就穿。这不是某一方有问题，而是整个系统本身就是这么设计的。争斗不是因为某个人坏，而是因为大家都在为自己的KPI负责。
2. 攻防团队与产品团队：安全公司最经典的一场“相爱相杀”
要说安全公司内部最典型、最激烈的争斗，那一定绕不开攻防团队和产品团队之间的事。这两个团队在安全公司里，既是最亲密的战友，又是最激烈的对手。
2.1 红队测出漏洞，产品经理为什么第一反应是“否认”
我自己做过攻防，也带过产品，太清楚两个阵营的心态了。红队（攻防团队）的工作就是拿自家产品、自家业务来练手，找到漏洞然后提出来。产品团队的KPI是产品稳定、是交付上线，所以他们的第一反应往往是：这个漏洞是不是你们打出来的？是不是你们环境配错了？是不是你们用了不支持的版本？
你会发现，这不是技术问题，这是立场问题。红队背后是“我要证明我很强”，产品背后是“我要证明我的东西没问题”。当这两个立场碰撞到一起，就会出现一个特别经典的局面：红队提供了一个非常详细的漏洞报告，PoC代码都写好了，复现步骤清清楚楚，然后产品团队开了一个又一个评审会，反复确认是不是误报，能不能通过“架构设计”来解释，而不是承认“存在漏洞”。
中间最受伤的其实是测试和研发。测试测出来问题，提Bug单，研发觉得这需求当初就没写清楚，排期又紧，哪来的时间处理这种“极端情况”？最后只能靠领导拍板：这个漏洞修不修，优先级多高，哪边的人来改。每一次这种来回拉扯，都是在消耗团队之间的信任。
2.2 红队和产品团队抢地盘：谁才是公司的技术天花板
比“修漏洞”更隐形的争斗，是话语权的争夺。在安全公司里，红队通常被认为是“技术天花板”，因为他们做的事情最接近黑客攻击的本质，也最能代表公司的安全能力。所以公司对外的技术宣传、行业会议演讲、漏洞大赛参赛，基本是红队的舞台。
产品团队的同事心里未必服气：你红队是厉害，但你的东西能卖钱吗？能规模化吗？能服务几千家客户吗？我这里一个产品模块养活整个售后团队，你那边一年到头就是在靶场里打打杀杀，出了安全事故还不一定顶得上。这种“谁才是公司核心竞争力”的争论，在内部论坛、季度总结、年度规划里反复出现。
谁在争夺什么呢？说到底还是编制和预算。红队证明自己有价值，才能要到更多的人头、更好的设备、更高的薪资预算；产品团队证明自己有价值，才能争取到更多的研发资源、更好的市场推广、更快的交付渠道。而公司的管理层，往往也在这个过程中故意保持一种“平衡”——因为如果一边独大，另一边就没动力了，公司整体的能力反而会退化。
2.3 我已经踩过的坑：如何减少攻防和产品的内耗
踩了不少坑之后，我慢慢总结出一些能让两个团队相处得稍微愉快一点的方法。
第一，漏洞不能只报给产品邮箱，要在周会上过一遍。把漏洞提交做成一个公开的、有记录的流程，让产品团队知道红队在做什么，而不是某天突然收到一封漏洞邮件然后一头雾水。红队周报里明确写出“本周测了什么、发现了什么、影响面多大”，产品团队能提前感知风险，也更容易接受后续的修复方案。
第二，修漏洞的预算必须单列。产品团队恨红队，很大程度是因为红队发现的漏洞占用了他们的正常迭代资源。解决这个问题的方法很简单：在公司的研发预算里，单独划出一块“安全修复专项”，不占用产品正常的版本排期。这样产品团队就不会觉得红队是在给他们添乱，反而会认为“你们帮我们发现了问题，还有钱来修，这是双赢”。
第三，红队要参与产品设计，而不是只做“事后诸葛”。很多矛盾的产生，是因为红队在产品都快上线了才来测，一测一堆问题，产品只能推翻重来。如果把红队拉进需求评审和架构设计阶段，提前识别风险，产品的返工率会大大降低，两个团队的关系也会从“对立”变成“协作”。
3. 暗战：漏洞披露和客户关系之间的“权力游戏”
说到安全公司内部的争斗，有一个领域是外部人完全看不到的，但又特别有意思，就是漏洞披露和客户关系之间的博弈。
3.1 研究人员想发Paper，公司想保护客户关系
安全公司的研究员，尤其是研究团队的人，很大程度上是靠“名声”吃饭的。一个漏洞被公开，一篇技术分析发出去，一次行业会议的演讲，这些都会积累他们的个人品牌。所以研究人员的本能是：发现重大漏洞之后，想尽快公开，想发文章，想做分享，想让全世界都知道“这个漏洞是我发现的”。
但公司层面，尤其是商务和法务团队，考虑的问题完全不一样。如果这个漏洞影响的是某大客户的业务系统，你要公开发布，客户的第一个电话就会打到公司高层：“你们什么意思？我们家系统有漏洞，你让全世界都知道了，我们的声誉怎么办？合同里写了要保密的，你们违约了。”
于是争斗就开始了。研究员说我要发，商务说不行你要保密，法务说合同里写了披露必须经过客户同意，技术高层说我们能不能做“负责任披露”，先给客户缓冲期再公布。开会、扯皮、拉锯，一开就是几周甚至几个月。
3.2 “负责任披露”有时候是一个借口，有时候是一块遮羞布
我见过太多“负责任披露”的讨论了，这个词在不同角色的嘴里，含义完全不同。
研究团队眼里的“负责任披露”：我们发现漏洞后，给厂商预留90天时间修复，修复完成后再公开，这是行业标准。客户眼里的“负责任披露”：你怎么能在没跟我商量的情况下就公开我系统的漏洞？我要的是你帮我处理好，而不是昭告天下。公司管理层眼里的“负责任披露”：我们要保护商业关系、维护客户口碑，至于公开不公开，先以客户意见为准。
这三方对这个词的理解完全不一样，所以每一次漏洞公开的讨论，都是三方意志的较量。研究人员如果执意要公开，可能面临公司的处分，甚至丢掉客户项目；公司如果强行压下来，研究人员的积极性会被打击，长期下来人才流失；客户如果捂住漏洞不处理，那这个漏洞就会成为悬在所有使用该产品客户头顶上的达摩克利斯之剑，下一个被攻击的可能就是其他人。
我的经验是，这块没有一个完美的解法，但有一个原则可以减少矛盾：在漏洞发现的第一时间，就把“信息披露计划”作为一个单独的工作流，而不是等到要公开了才开始沟通。研究员在提交漏洞时，同时提交一个“预期披露时间表”；商务团队在客户合同里，对“漏洞披露”的条款写得越细越好；管理层提前让所有相关方达成一个“信息披露默认准则”——比如默认90天后可以公开，除非客户在此期间完成了修补。有了这个默认值，后面的拉锯会少很多。
3.3 白帽社区和公司KPI之间的隐形张力
这个争斗还有一个延伸版本，就是白帽社区的运营。很多安全公司为了获取漏洞情报，会运营自己的SRC（安全应急响应中心），邀请外部的白帽研究员来提交漏洞。这对公司来说是很划算的——用几千块的奖励金换一个高危漏洞情报，比养一个完整的研究团队便宜得多。
但问题在于，外部的白帽研究员，他们忠诚于谁？忠诚于SRC平台的奖励，还是忠诚于你的客户关系？如果白帽研究员发现了一个十分严重、甚至可以拿去卖钱的漏洞，他为什么要给你？如果你给出的奖励太抠门，他转头就把漏洞卖给了搞黑产的，或者卖给了同行，这漏洞就失控了。
所以安全公司内部的SRC运营团队，其实处于一个很尴尬的位置：他们一方面要尽量获取漏洞信息，另一方面又不能完全放开手脚给高价，因为他们的KPI是成本控制。这时候，SRC团队和业务团队之间，就会出现一种“隐性博弈”——业务团队希望SRC能用规则约束白帽，别惹出乱子；SRC团队希望业务团队松绑，给他们更多预算去刺激白帽提交。这种内部的张力，最后往往是以“白帽的积极性下降”为代价的。
4. 售前、销售、交付：铁三角是怎么变成“三国杀”的
如果说攻防和产品的争斗属于“技术流派之争”，那销售、售前、交付这三个岗位之间的爱恨情仇，就属于“商业末端的日常混战”了。这也是安全公司里，普通从业者感受最直接的争斗。
4.1 售前为了拿单，什么都敢承诺
我在安全公司做过的项目里，见过最离谱的售前承诺，是在一次银行的等保测评项目里。当时售前为了让客户下定决心签单，在技术方案里写了一句“我司产品可全面覆盖等保三级要求，确保系统通过测评”。这句话写得轻飘飘的，但交付团队看到的时候，血压直接就上来了。
因为“覆盖等保要求”和“确保通过测评”是两码事。等保测评有一堆前置条件：客户的网络架构得合理、安全设备和策略得配置好、管理制度得健全、人员意识得到位。产品可以帮你满足技术项，但很多管理项、物理环境项的整改，根本不是安全公司的产品能解决的。售前为了拿单，把这话写进去了，交付团队在现场就变成了“全能背锅侠”。
客户拿着合同找来：“你们不是说确保通过吗？现在这里不行、那里不行，怎么回事？”交付团队百口莫辩。解释不能，整改又超出合同范围，项目一拖再拖，最后交付团队加班到深夜，新来的项目经理头发都白了一半。这个项目最后是勉强过了，但过程中售前和交付的梁子，算是彻底结下了。
4.2 销售要回款，交付要时间，谁听谁的
在安全服务里，一个项目通常分为几个阶段：前期调研、方案设计、实施交付、培训验收、回款。销售的压力来自回款指标，他希望项目早一天验收，早一天回款，早一天拿提成。交付的压力来自质量，他希望每个环节都做得扎实，别留下后遗症，别出现半夜两点客户的告警电话。
于是矛盾就出现了。销售催交付：“客户那边能不能周二就验收？我这季度就差这一单了。”交付一线的人心里在骂：“周二验收？你方案里承诺的培训内容我还没做完呢，客户的技术人员还没熟悉产品，你让我怎么提验收？”但销售不听这些，他直接找交付总监，交付总监再压给项目经理，项目经理只能在一线磨。
这种争斗在安全服务这个行当里，几乎是每周都在发生的。本质上是销售体系和交付体系的目标函数不一样，销售看短期，交付看长期，但公司又必须同时考核这两个指标，所以谁都不愿意让步。
4.3 怎么让铁三角少打架：合同评审和风险清单
我后来管理交付团队的时候，做了一个小小的变革，就是引入了“售前承诺清单”机制。具体做法很简单：售前在出技术方案的时候，必须附一页文档，里面逐条写明“我方承诺客户的事项”，比如：覆盖等保三级、支持XX种设备的日志接入、提供XX场培训。交付团队在接手项目前，先核对这份清单，凡是清单里没有的、但客户又提出来的需求，一律视为“新增需求”，需要走变更流程，调整报价和排期。
这个机制一上线，售前明显收敛了很多。因为他们知道，承诺写下去的每一条，最后都会变成白纸黑字的合同责任，而售前的提成里也有一块是和交付的满意度挂钩的，所以他们不敢再乱吹牛了。交付团队也不用来回扯皮，遇到客户新需求，直接拿出一份清单说“这部分超出了合同范围，需要评估调整”，客户反而更好沟通了。
从这之后，我的体会是：安全公司内部的很多争斗，不是靠人“懂事”就能解决的，而是要靠流程和机制把风险前置，让每个角色都为承诺的后果负责。指望大家靠自觉和交情来维护，那是不可能的，只有规则能让大家在同一张桌子上心平气和地说话。
5. 路线之争：合规买命与攻防出名，公司应该押哪边
这个话题再往上走一层，就到了公司战略层面的争斗了。安全公司的资源是有限的，每年的预算、人力编制、市场投入、高管精力，都是一个盘子里的蛋糕。这个盘子往哪个方向倾斜，直接决定了公司未来三到五年的走向。
5.1 “合规业务”和“攻防研究”到底谁更值钱
我先说清楚这两个路线分别代表什么。
“合规业务”指的是等保测评、风险评估、安全咨询、合规审计、安全运维这类，需求刚性强、复购率高、上手难度相对低的业务。它赚的是“监管的钱”，客户做不做这套东西，不完全取决于客户的主观意愿，而是由法律法规和监管要求驱动的。所以你不需要花太多精力教育市场，客户的预算也会自己找上门。
“攻防研究”指的是渗透测试、红队评估、攻防演练、漏洞挖掘、威胁情报这类，技术含量高、给客户带来的价值更直接但也是“可选消费”的业务。客户采购它，是因为它自己觉得“我可能需要测一下看看有没有问题”，而不是“法律规定我必须做”。这类业务更依赖人的技术能力，也更依赖行业口碑和影响力。
这两类的商业属性决定了它们在公司内部的争论点：合规赚钱快，但要靠堆人、堆流程，毛利率相对低；攻防有品牌价值，但市场容量有限，且高度依赖个人能力，不好规模化。如果公司押注合规，那研发资源应该投在流程自动化和交付标准化上；如果公司押注攻防，那研发资源应该投在攻防工具平台化和自动化上。这两条路的研发方向、人才梯队、市场打法都不一样。公司内部的“路线之争”，争的本质上不是哪个更厉害，而是公司有限的资源该往哪个方向集中。
5.2 老板到底是怎么想的：短期现金流与长期技术壁垒
作为普通员工，我们经常看不懂老板在路线之争里的立场——今天说要做产品化，明天又去投了一个CTF战队，后天又把大量人力堆到合规项目上。其实老板的内心戏，远比我们想象的要复杂百倍。
一个特别现实的逻辑是：老板要考虑短期现金流和长期技术壁垒之间的平衡。合规业务是现金牛，能维持公司运转，能发工资，能交房租，所以不管老板嘴上怎么高喊“我们要做技术驱动”，到了每一季度的结算时刻，合规业务还是会被优先保供。而攻防研究的投入，往往是“反周期”的——行情好的时候，你可以花重金养一支研究团队，打造技术品牌；行情一旦变差，第一批被优化和边缘化的，就是那些“不直接创造收入”的研究员。
我见过不少公司，在这种路线之争中，最后采取了“共用一套底座”的策略：攻防研究团队负责把在实战中验证过的工具和方法沉淀成平台能力，这套能力再被合规团队的项目拿来复用，变成合规服务的“豪华版”，这样老板就可以说“我们既做了技术，也赚了钱”。这种做法在逻辑上是成立的，但执行起来需要攻防团队和项目团队有极强的默契，否则就会变成“攻防团队不停造武器，项目团队根本不会用”，两边都觉得是对方的问题。
5.3 作为一颗螺丝钉，你怎么选边站
这个话题对普通从业者的现实意义是：你在一家安全公司里，到底应该加入“合规系”还是“攻防系”？
我个人在带人和给新人建议时的看法是：看你的阶段和风险偏好。
如果你是刚入行，技术底子还不扎实，我建议你优先去攻防研究相关的团队，哪怕薪资低一点，因为那里能让你快速建立“技术判断力”。你会接触各种奇奇怪怪的攻击手法，会亲手调试恶意样本，会理解漏洞产生的根源。这些能力是通用资产，不管以后你去甲方还是乙方，不管安全市场风吹到哪个风口，这些底子都能让你站住脚。
如果你已经有三到五年的经验，想追求更稳定的职业发展，你可以考虑转到合规业务方向。这个方向更贴近商业本质，能让你理解客户是怎么想的、预算怎么走、交付怎么控成本。在这个方向上，你会从“技术人”慢慢转型成“懂业务的技术人”，升维的空间更大。
但最忌讳的，是那种两边摇摆、哪个方向火了就去哪个方向蹭一下的人。安全行业的路线之争会长期存在，但个人的积累必须是线性的。你今天在攻防岗打了两年的基础，明天听说合规赚钱就转到合规岗，那前两年的积累就很难复用。与其在公司的内部争斗里反复横跳，不如先想清楚自己未来五年想成为什么样的人，然后把一个方向做深做透。
6. 写在最后：我在安全公司内部争斗中学到的几件事
写了这么多，其实都是这些年我在安全公司里摸爬滚打留下的真实印记。我既当过攻防团队里那个天天追着产品提漏洞的“刺头”，也带过交付团队在客户现场擦过屁股，还一度被卷入过“资源争夺战”的漩涡。每次回过头去看，都很感慨。
第一件事是，争斗本身不是坏事。一个完全没有内部争斗的安全公司，大概率是死气沉沉的。因为安全本身就是攻防对抗，只有大家有想法、有立场、有观点，才可能碰撞出有价值的东西。真正有害的是那种“为了压倒对方而否定对方价值”的争斗，那种争斗会让技术走偏、让人才流失。
第二件事是，真正的高手从来不靠“办公室政治”取胜，而是靠“不可替代性”。你如果能在某个细分方向做到别人替代不了，那你不需要参与争斗，自然会有人为你争取资源。反过来，如果只能靠讨好领导、站队押注来向上爬，那一旦风向变了，你摔得会比谁都快。
第三件事是，安全行业真正的敌人永远在外部。不管公司内部是攻防和产品在打，还是销售和交付在吵，我们最终面对的都是那些不断寻找漏洞、不断发起攻击的黑产组织和对手。你花在内部消耗上的每一分钟，都是在给真正的对手创造机会。
我到现在依然很喜欢这个行业，因为安全这个领域，永远不缺乏挑战，也永远不缺乏真诚的同行者。哪怕公司内部再多的勾心斗角，大家坐在一起研究一个漏洞的时候，那种纯粹的、属于技术人的快乐，依然是任何办公室政治都磨灭不了的。
如果你也在安全公司里经历着各种内部博弈，别太焦虑，学会在争斗中沉淀自己的能力，把每一次冲突当成理解公司运转逻辑的机会。等你看明白了这盘棋，你就不再是那个被推来推去的棋子，而是能为自己下一步落子的人了。共勉。
