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

注解：
对于一个团队来讲，应该要有一个共同的使命，明确团队目标和使命，驱动大家向一个目标前进，也是我们所有工作的意义所在。

使命要结合公司的业务，你的公司为谁服务，有哪些产品，公司做安全的意义是什么？

二、行为守则

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

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

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

 

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

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

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

注解：在做白帽子（漏洞挖掘机）或者在乙方工作的时候，很少会涉及完整的安全方案，通常都是发现一个漏洞解决一个漏洞，绝大多数情况在漏洞的修复建议里写的都是“一句话建议”，好一点的可能从通用安全方案模板中粘贴上一大段安全实现Demo代码。初入甲方的同学，在推动业务解决安全漏洞时很容易按照过去的惯性行事。比如有的人，漏洞直接丢给开发，让开发自己去理解漏洞，自己想办法修，修完我再来验证你有没有修好；好一点的，会给个一句话的修复建议，但是这个建议既没有具体的方法，也没有考虑实际的业务情况，最后没办法落地。开发即使参考了这个一句话的建议，也是基于自己对安全有限的理解，搜索到一些质量参差不齐的参考资料，去修漏洞，修完之后复测再被绕过，如此反复，浪费大量的时间资源；更好一点的，修复建议稍微详细了一点，甚至还有参考文章的链接，修复代码Demo，但是由于没有耐心，进一步跟开发沟通去理解清楚整个业务逻辑、实际实现和应用之间的调用链路，可能依然不好落地，最终开发只能凭借你给的资料，结合自己的理解修复漏洞。这是在安全方案层面。 

在具体的漏洞修复推动层面，大部分同学可能发现一个漏洞，推动解决一个漏洞，到这里就结束了。不是说这样不好，能够完完整整的把一个漏洞从发现到修复的闭环跟进完成，已经算很好的了。

但在甲方，你其实可以做得更好。比如发现一个漏洞，你能不能深入业务，深究本质，从根源上给出完整方案，由点及面最大范围解决同类风险？有的漏洞业务方自己修只解决了这个单点风险。但是应用依赖的上下游链路里，是不是有更好的节点可以通过改造去修复漏洞，从根源上给出完整方案把问题解决，很有可能一口气就解决了几十几百个潜在的同类漏洞和风险。

有些常见的风险无法通过纯技术手段解决，是不是可以思考和设计一下如何优化现有的流程，在整体研发流程的某个环节中，解决这类风险？如果你能主导并且推动落地，就更完美了。

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

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

安全工作，能“较真”非常重要。

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

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

注解：这条不用解释。

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

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

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

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

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

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

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

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

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

三、会议规范

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

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

四、关于此章程

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