0x01 前言

这篇文章既是写给甲方SDL团队管理者，也是写给所有甲方SDL从业者。

打铁还需自身硬，想要在企业中将安全建设好，首先要从安全团队内部出发。一个有战斗力的安全团队，是一切的基础。

笔者刚刚负责SDL团队的时候，经历过很多管理上的问题。刚开始带团队时，会感到对比单兵作战时压力大了很多倍。很多事情会让人感觉，失去了对以往工作内容和技术本身的掌控感。假设你有比较强烈的责任感，就会发现很多人并不会按照你的意愿行事，你希望所有人都能够跟你一样有责任心、做事认真，但现实与我们的期望往往大相径庭。

追根溯源，这里有工作认知和观念的问题，也有工作方法的问题。尤其对于刚刚从乙方进入甲方工作的白帽子们，开始时很难适应和转变工作思路，容易按照过去在乙方工作形成的惯性向前走。而甲方的安全工作重点和乙方实际上有非常大的差别。

为了理清和改善团队里的具体问题，帮助大家提升对甲方安全工作的理解，我们在内部制定了一个SDL团队章程，帮助团队成员更好的成长，并且帮助团队更好的运作和管理。

本次分享出来，希望帮助初入甲方的SDL从业人员，更好的认识自己的工作，同时希望能够帮助更多的甲方SDL团队，提升团队战斗力。如果你的SDL团队刚刚建立，或者你觉得在团队管理上存在一大堆问题，那么你可以考虑参考这篇文章制定一个团队的章程。

我会尽量在每一项的注解中解释问题和背景，可以对照看看你或者你的团队是否也存在一些类似的问题，也许你能够在里面找到些共鸣。如果一个都没有，那么恭喜你，你可能处在一个非常优秀的SDL团队中。

0x02 SDL团队管理章程

一、目的（我们为什么存在？）

使命：支撑保障业务、亿万IoT设备、用户的安全！
提升安全建设水位，寻找并利用各种方法手段，最大程度为业务降低安全风险，保障业务健康发展。

注解：
对于一个团队来讲，应该要有一个共同的使命，明确团队目标和使命，驱动大家向一个目标前进，也是我们所有工作的意义所在。
使命要结合公司的业务，你的公司为谁服务，有哪些产品，公司做安全的意义是什么？

二、行为守则

没有条条框框，但有原则。以下行为原则及产出结果是评判绩效的重要参考依据。

注解：
行为守则是为了帮助大家判断工作中的原则，什么样的行为习惯是团队里鼓励的，什么样的行为习惯是团队里不鼓励的。主要在于工作观念，方式方法的引导。里面其实涉及了一点价值观层面的东西。现在感觉有个不大好的风气，谈“价值观”色变，企业不好意思讲，员工觉得“你是不是在pua我”，普遍觉得虚，我一直认为价值观不论是对于个人成长，和团队战斗力来讲，都有关键性的作用（个人观点）。当然好的工作和管理方法，也可以引导团队健康良性发展。好的价值观是先天条件，好的管理方法是后天努力。

通常有一定规模的甲方才会建立自己的安全团队，而这类甲方企业通常都会有KPI、OKR之类的绩效管理手段，而一旦有绩效管理，那么必然会出现公司划给团队的蛋糕有限，应该怎么分的问题。

由于每个人的经历不同，性格不同，对于专业能力成长所处的阶段也不同，所以对自我的评价不可避免会出现认知偏差。人们往往会高估自己的能力，认为自己是高于平均水平的，能力越差的人，越容易对自己产生过高的评价，产生“达克效应”。当然也有人会低估自己。

当我们在对团队成员做绩效评价时，是综合考虑所有人的工作表现和产出进行对比的，所以很可能出现一种情况，你给出的绩效评价结果低于对方的预期，原本对方在自己的认知里自我评价是非常高的，可能高于团队里的大部分人，但是他实际上可能并不清楚怎样的工作表现和结果是更好的，也不完全清楚其他人做了什么，平时的工作表现如何，完成质量如何，难以客观评价自己也无法客观评价他人。这是由于信息不对称造成的正常现象。所以我们要尽量有一个共同认可的标准原则，能够帮助大家对比复盘改进，提供指导，并且基于这个标准对自己的工作和他人的工作产生更加清晰的认知。明白为什么有的人能够拿更好的绩效，有的人拿比较差的绩效，自己如何改进提升能够做到更好。

（这里只是基于公司既定的KPI或OKR管理规则进行讨论，每个公司落地实行KPI、OKR的情况好坏不同。以上仅供参考，不代表笔者认可所有的绩效管理制度。）

哪些行为是我们鼓励的？

1、有责任感，自驱主动，关键时刻，能主动承担责任，为公司解决问题，为团队分担压力。

注解：做为安全从业人员，责任感是一切的前提。安全团队是公司安全的最后一道防线，如果没有责任感，谈何保护好企业和用户信息安全？

2、对发现的安全问题，深究本质，深入沟通，深入了解业务环节中各依赖方之间的处理逻辑，能够最大范围解决同类安全问题。解决方式有时有很多，可以在技术架构层面给出方案并推动，也可以在管理层面，给出可落地的方案，推动实施。

注解：在做白帽子（漏洞挖掘机）或者在乙方工作的时候，很少会涉及完整的安全方案，通常都是发现一个漏洞解决一个漏洞，绝大多数情况在漏洞的修复建议里写的都是“一句话建议”，好一点的可能从通用安全方案模板中粘贴上一大段安全实现Demo代码。初入甲方的同学，在推动业务解决安全漏洞时很容易按照过去的惯性行事。比如有的人，漏洞直接丢给开发，让开发自己去理解漏洞，自己想办法修，修完我再来验证你有没有修好；好一点的，会给个一句话的修复建议，但是这个建议既没有具体的方法，也没有考虑实际的业务情况，最后没办法落地。开发即使参考了这个一句话的建议，也是基于自己对安全有限的理解，搜索到一些质量参差不齐的参考资料，去修漏洞，修完之后复测再被绕过，如此反复，浪费大量的时间资源；更好一点的，修复建议稍微详细了一点，甚至还有参考文章的连接，修复代码Demo，但是由于没有耐心，进一步跟开发沟通去理解清楚整个业务逻辑、实际实现和应用之间的调用链路，可能依然不好落地，最终开发只能凭借你给的资料，结合自己的理解修复漏洞。这是在安全方案层面。 
在具体的漏洞修复推动层面，大部分同学可能发现一个漏洞，推动解决一个漏洞，到这里就结束了。不是说这样不好，能够完完整整的把一个漏洞从发现到修复的闭环跟进完成，已经算很好的了。
但在甲方，你其实可以做得更好。比如发现一个漏洞，你能不能深入业务，深究本质，从根源上给出完整方案，由点及面最大范围解决同类风险？有的漏洞业务方自己修只解决了这个单点风险。但是应用依赖的上下游链路里，是不是有更好的节点可以通过改造去修复漏洞，从根源上给出完整方案把问题解决，很有可能一口气就解决了几十几百个潜在的同类漏洞和风险。
有些常见的风险无法通过纯技术手段解决，是不是可以思考和设计一下如何优化现有的流程，在整体研发流程的某个环节中，解决这类风险？如果你能主导并且推动落地，就更完美了。

3、对漏洞，能够指导开发修复，针对业务具体情况，深入理解业务，给予完整详尽的安全方案。

注解：做到第2条其实不太容易，除了工作方法，对待问题的思路上养成好的习惯，对SDL人员的技术能力也是一个挑战，尤其对没做过或者没有系统学习过开发的白帽子来讲是比较难的。所以日常工作中，可以从第3条开始，每一个漏洞每一项风险，都问问自己，是不是认真对待，做到了这种程度。经过一段时间积累，以及对业务研发的了解，你会发现做好第2条并没有那么难。能够讲清楚问题的原理、危害、方案，不仅可以帮助业务同学提升安全知识和意识，同时也会传递你的专业性，赢得更多信任，在后续的工作中，对方也会对你或者你团队的工作更加支持和尊重。

4、事情能否做好，很大程度取决于对细节的掌握，抱着“较真”的态度把事情认真搞清楚，之后再下结论或评判。

注解：SDL工作跟业务会有大量的对接沟通，由于双方背景知识不同，掌握的信息不同，沟通上很容易出现不顺畅的情况。有时候，可能双方连事实都没去搞清楚，因为某一方对某个细节不掌握或者理解不一致，就吵起来了。心里面互相给对方贴了标签，安全觉得业务不听话，让你修个漏洞怎么这么麻烦，业务觉得安全啥也不懂还为难我。 其实大多数情况，只是沟通的耐心不够，对细节掌握的程度不够，才导致了无法理解对方。真正耐心地去了解清楚需要掌握的所有细节，很难有聊不通的问题、做不好的事情。真的遇到了比较极端的情况，无法解决，可以向上反馈，上升到上一级Leader，此时也有理有据。 如果自己还没有尽力去搞清楚问题，就乱下结论，跟人吵架，是非常不专业的行为。
安全工作，能“较真”非常重要。

5、发现问题，主动去解决或者主动推动解决（而不是总期待别人解决问题），落地解决方案。需要帮助时，可向团队发起主题会议，在周会时讨论方案，如有必要，可专门开会讨论。

注解：职场中有的人很善于发现问题，但是永远的在不断进行毫无建设意义的抱怨，而且总是希望别人来解决问题，从未考虑过自己有没有可能去解决掉问题。遇到自己能力范围内无法解决的问题时，可以在正式的场合反馈交流，私下的抱怨永远无法解决问题。凡是问题，皆是机会。发现问题，能主动解决问题，也是一个人能力和价值的体现。这条可以对照下面不鼓励的行为第4条来看。

6、鼓励技术研究，更鼓励选择与公司业务或技术栈安全有相关性的技术方向，深入研究，为我们的安全建设创造价值。

注解：我们搞安全的平时一定要保持技术进步，越是往后学，你会发现要学的东西越多，就没有学完的时候。但是偶尔会有同学学着学着方向就偏了，整天研究的东西跟实际工作没有半毛钱关系。举个不一定恰当的例子，假设你的公司技术栈完全是Java，没有一个业务用到PHP，你在Java安全还没有吃透的情况下，整天研究PHP安全（即使它是最好的编程语言），但也不值得鼓励，除非你目标明确，想要下一份工作跳槽到一个PHP技术栈的公司。人生苦短，精力有限，你的研究方向能够为自己的安全建设本身带来价值吗？假设你的出发点是积累跳槽资本，大多数情况下，你当前的工作需要的能力，其实也是市场上需要的能力，因此不必舍本逐末。当你有多个方向想要研究的时候，尽量选择对个人对本职工作都有意义的那一个，一举多得。

7、鼓励分享，分享是加深自己技术理解程度的机会，也是增强自己表达能力的机会，同时会给团队其他人带来不同程度的帮助和提升。优秀的团队一定是共同成长，互相成就的。

注解：这条不用解释。

8、保证质量，有始有终。

注解：有时候一个人跟一件事情，跟着跟着就没后续了，过了很久之后由于某个事件复盘，发现之前有做过，但没做完，甚至一些相关的人都离职了。包括我自己，事情多时间久了，偶尔也会遗忘。所以一些周期长的事情可以写到待办里记录下来，有始也要有终。 保证质量也很重要，不能说目标里定的是完成，不管啥样搞完就行了，最后发现一大堆问题，还得重做。

9、换位思考，如果你是研发，你要怎么修复这个问题。站在对方的角度，考虑你要怎么沟通，对方才能更容易接受。

注解：换位思考是一项很重要的工作能力，不论是在沟通上，还是自我提升上。

10、养成总结的习惯，经常沉淀。鼓励把提效工具、方法带给团队，输出给业务团队。

注解：好的工作方法、工具能够经常总结沉淀，分享给团队，往往可以帮助到其他人，带来整体效率的提升。如果能够进一步输出给业务团队，更能体现价值。一个人也许可以走的更快，但一群人可以走的更远。

最后一条，职业生涯发展（升职加薪）利器：主动性！主动性！主动性！

哪些行为是不鼓励的？

1、职责划分过于清晰，固守边界，自扫门前雪。

注解：工作中经常会遇到一些处于模糊地带的事情，参与也行，不参与也说的过去。如果每个人都严格按照职能界定固守边界，自扫门前雪，那么很多事情就无法产生协作，问题永远不能解决。向前走一步，“山不过来我过去”。

2、对漏洞的产生原因，修复方案模糊不清的，不进行研究，直接给“一句话”方案，拒绝沟通，不考虑场景，强制研发按照“一句话”方案修复。

注解：这是个常见的问题。在鼓励的行为2、3条里说过了。

3、安全遇到紧急事情是常态，不要做旁观者，要做参与者。

注解：一个通用漏洞爆发，一次安全事件，都可能是比较紧急的。你的每一次主动参与或者提供帮助，别人都能够看到。

4、毫无建设意义的抱怨。凡是问题，皆是机会。发现问题，能主动解决问题，是一个人能力和价值的体现。
不同人遇到问题，理解是不同的：
有的人没有明显感知，觉得问题是正常；
有的人觉得问题都是别人的问题，与我无关；
有的人产生强烈的负面情绪，回避问题；
有的人寻找解决办法，主动推动/解决问题。
问题是一面镜子，对问题的态度，一定程度上会折射出一个人的认知水平。
你希望自己成为哪一类人呢？

注解：这个问题前面鼓励的行为第5条里说过了。

5、少做少犯错？
No！！！不要怕犯错，犯错会带来成长。避免“固定型心态”，拥抱“成长型心态”（如果不了解这两个概念，可以自助了解下）。

注解：有的人在职场待久了，会“精通”所谓的职场“潜规则”，比如做的多错的多。也许在某些地方适用。但我相信拉长时间来看，这种心态对自己来讲一定是弊大于利的。

6、人不是机器，工作时间偶尔开小差可以理解，但在正常工作时间内不能花太多精力在与工作本身无关的事，比如：刷剧、看电影、打游戏、挖SRC、做众测等。

注解：工作时间内花太多时间搞娱乐本身就是一件非常离谱的事情，虽然比较少见，但确实会有。有些搞安全的同学可能喜欢占用工作时间挖SRC、做众测、私活，而本职工作却没有花时间做好。为什么会有这种现象，这是一个很大的话题，不在这里深入聊了。SDL团队里最好能避免这种风气。

三、会议规范

• 时间
  每月至少一次团队复盘会。其他事项可按需发起会议。具体会议时间跟进实际情况决定。
• 方式
  每位团队成员，均可以在有需求时，发起团队会议。
• 内容
  任何与工作相关的内容，包括但不限于：
  技术分享
  漏洞复盘
  工作问题同步
• 参会人员
  每次会议，发起者需要指定团队参会人员类型，分为必须参加、建议参加、自行决定。
• 会议过程要求
  讨论重要内容时，所有参会成员需合上电脑，放下手上其他工作，认真投入参与，倾听、思考、讨论。

注解：开会的时候如果没有要求，可能会有一些同学忙于手中其他的事情，而不能很好的参与进来，会议的效果大打折扣，浪费彼此的时间。

四、关于此章程

此章程由团队全体成员商议制定，每年回顾调整一次。

注解：要确保团队所有成员参与，充分讨论，达成一致。随着时间和团队发展阶段的变化，章程的内容也应该定期回顾调整。

0x03 后记

其实最早的版本，写的比这个多一些，后来尽量做了精简。以上内容仅供参考，希望能对各位读者所在企业的安全建设有所帮助，可能很多问题我还没有遇到过，如果你遇到了一些团队建设的难题，或者好的建议，欢迎和我交流。

因水平有限，文中内容如有偏颇也欢迎批评指正。

个人微信：w4ter0

作者：唐银@涂鸦智能