作为一个研发凭什么花大量时间修安全漏洞？

写在前面

距离公众号的第一篇文章过去了 2 个月了，最近一直在忙上产品 3.0 的事情，中间加上感染新冠，这篇文章前后也写了半个月，趁着这两天 3.0 产品大版本发布了，赶紧把这篇文章改好发出来，主要还是分享记录墨菲安全 3.0 产品的一些思考和心得。

搜索关注公众号“航行笔记”

Part 1：从一个研发工程师对修复安全漏洞的吐槽说起

上周去上海出差，见了我的一个学弟，此学弟因为长得比较显老，虽然是我学弟，但是大家都叫他老刘，现在在上海一家互联网公司的电商业务部门做研发。这次去上海出差住的地方离他公司特别近，而且他也是我们墨菲安全早期的 C 端用户，给我们提了很多很好的建议，所以想着这次在上海出差得请他吃个饭，顺便再找他调研调研需求。老刘是一个特别喜欢吐槽的人，很技术范，看不惯的一切也都不会惯着，加上他本身技术比较好，所以吐槽就愈发"猖狂"。

这次吃饭也不例外，各种吐槽，先是跟我讲现在互联网公司一个个卷的要命，很多人都害怕裁员，天天卷，各个部门之间也非常卷，他告诉我，他们公司的安全部门就特别卷，天天给他们发安全工单，让他们修漏洞，很多时候着急上线（因为本身就裁了一些人，业务一点都没有少，工作量自然变大了），他们根本就没有时间修漏洞，而且每次安全部门发工单都要天天催，感觉每个漏洞都是咋咋唬唬，不修的话还要给领导发邮件，一顿吓唬不懂的大领导（因为他们是业务部门，老板不太懂技术），好像今天不修复，明天就得出事背锅，搞得他一天也是苦笑不得。

老刘说，其实我并不是不想修漏洞，但是我最烦的是，很多漏洞根本没有那么严重，而且安全发的工单也需要花大量的时间去理解消化，然后自己去找修复方案，最终各种尝试修复，运气不好的话，修漏洞的时间比写代码的时间还长，老刘最后气急的问：我作为一个研发，凭什么花这么多时间去修一些莫名其妙的安全漏洞？

我问老刘，那你希望是什么样的？出漏洞就不修复了？躺平？老刘的一番话让我的收获还是挺大的，老刘说：修复肯定是要修复的，作为研发来说，我们就希望每一个工单都能非常清晰的告诉他哪块的代码出了什么漏洞，给一个客观靠谱的漏洞级别评估，然后最好告诉他应该怎么修复？最好能帮我修复了那就最好了，当然这个就有点奢望了。哈哈哈，老刘也不好意思的笑了。好像要求提的有点高。哈哈。

老刘的这些话，让我感触非常深，想想 12 年我在百度发安全工单的时候，何尝不是老刘嘴里所说的"安全团队"呢，我们一个工单发出去，一顿咋呼，不修就给你领导发邮件，好像全世界的工作都没有安全的优先级高，然后碰到不会修的研发还要一顿吐槽他们技术菜，这都不会，实际上大多数研发确实不是安全专业的，我们工单也没有说的多清楚。现在想想确实换个角度，有很多当时做的不妥的地方。

过去市场上安全产品和工具貌似更多的都是在服务安全工程师，很少有人真正关注研发们的感受，而大家好像又忽略了非常重要的一点，最终所有的代码安全问题都需要研发操刀去解决。所以为什么不应该是让一个好的安全产品直接面向研发大大们去设计呢？让他们自助式的去解决安全问题，甚至帮助他们"自动"修复这些漏洞，满足老刘一个小小的心愿？

老刘的这一顿吐槽，又深深的激励了我，我跟老刘说，我们墨菲安全 3.0 的产品发布了，你抽空去试试我们开发的 IDE 安全插件，它能帮你自动修漏洞（目前 java 支持是最好的，可惜老刘现在已经写 go 了...）。老刘半信半疑的跟我说，回去马上试试，haha..

Part 2：谈谈这两天感染新冠的感受，以此引发对企业安全建设的新思考

这两天我们公司 80%的同事都阳了，我当然也不例外，发烧了 2 天，然后就是一顿喉咙疼，咳嗽。今天终于恢复的差不多了。这个过程我们家在一起的四口人全都阳了，包括我妈还有我小孩，整个过程都是自己在家吃药，然后大量喝水，基本都是发烧 1-2 天，然后就慢慢恢复了。我同事这些人基本上也都是这样，自己在家自助量体温、吃药加多喝热水，都问题不大。

国家这一轮放开来的非常猝不及防，导致感染新冠的人越来越多，张文宏医生说 99.5%的感染者是不用去医院的，自己居家吃药就行了，未来新冠也会成为一种季节性流行病。过去国家不轻易放开的一个很重要原因也是因为担心医疗资源的挤兑风险，这一波放开虽然短暂也会引起医疗资源的挤兑，但是慢慢大家会产生一个理性的认知，大部分人是不需要去医院的。

我在想，其实你看过去十年，随着各行各业的数字化进程越来越快，企业的软件开发和应用的范围也越来越广，从而带来了大量的安全漏洞风险，过去安全漏洞少的时候，企业的安全部门还可以为研发团队提供医院专家式的治疗。今天随着软件的应用数量越来越多，安全漏洞的数量也越来越多，一旦出现 log4j2、fastjson 这样的影响范围很广的 0day，企业的安全工程师资源就会面临被挤兑的风险，很明显安全部门那点人很快就会成为瓶颈。而这将严重的影响企业严重安全事件的响应和处置效率。研发人员自身也缺乏自助响应的经验和技术支撑。

从过往疫情防控的经验来看，未来企业安全的治理模式应该有一些转变。安全团队应该为研发人员提供自助式的安全工具（类似我们今天吃的退烧药，用的抗原，自己在家就能检测和治疗），同时出现疑难杂症自助解决不了的安全问题，才应该联系安全部门的专家来寻求支撑。这样企业安全漏洞的处置的效率才能大大的提升。而安全部门的专家们也不用天天把时间都花在沟通工单的修复和处置上，可以节省大量的时间去研究新的、复杂的安全漏洞，提升专业水平，以备未来出现新的安全漏洞可以更好的帮助开发者去迭代升级他们的工具和响应能力。

当然这件事最大的挑战就在于，如何研制出研发人员都能自助使用且有效的安全工具，让研发人员很低成本的就能去自助解决自己研发过程中发现的安全问题？这显然并不是一件简单的事情。

不过没关系，路对了，就不怕远。

实际上，我做过一些调研，给大家分享一组数据，我们对 github 一段时间（大概是今年 8 月份到 9 月份之间的 40 天）的开发者自助修复安全漏洞的数据做了一个抽样调研，我们调研了大概 ****97033 ****个开源项目，其中这些项目的贡献者中有 9.84% 的贡献者自助修复过安全漏洞，而其中中文开发者的数量大概占比 ****12.7% 。所以实际上，我们可以认为，只要你有一个很好的安全工具提供给开发者，开发者自己也可以发现并修复好这些漏洞。

我们也做了一个开源安全社区 OSCS，在 OSCS 社区，有超过 500 个开源项目的作者都在自助的修复安全漏洞，而墨菲安全上线半年多以来，也有超过 1 万名的开发者通过我们的工具平台自助的修复了超过 2 万多个漏洞。不仅如此，还有 283 个开发者用户给我们提了超过 350 个的问题反馈或者需求。这是一件非常了不起的事情，有越来越多的开发者主动参与到安全的工作中来了，这使得我们整个团队都非常受鼓舞。

（这里是 3.0 内测用户"正义"，连续 2 天晚上 1 点多还在给我们产品不断提着优化建议）

Part 3：沉下心来做开发者们喜爱的安全产品

正是受到越来越多的开发者们的鼓舞，我们发布了 3.0 新版产品，这也是过去一年我们团队熬过了多少个通宵，一路上，我们从去年 10 月份给小米、keep 试用的 1.0，小步快跑，来到了全新版本 3.0。3.0 的产品重点在使用便捷性、漏洞知识库的专业度及团队协作方面都有非常大的提升。这里我也分享一下我们 3.0 对于一个好的安全产品的理解。

首先，上手成本要足够低： 面向研发工程师们的产品，上手学习成本一定要足够低，最好是不需要看文档就会使用，一键接入，就可以开始检测，所以我们做了体验还是不错的 IDE 插件，此外我们通过管理后台可以通过引导式的快速配置让开发者们非常低成本的对接 gitlab 做检测，当然，上传文件也是可以的哦。

然后，理解成本要低： 因为研发工程师们并不是专业的安全研究员，那么我们应该尽可能要做到产品所有呈现给开发者们的内容理解成本要足够低，这样他们就能快速的认可产品所创造的价值，并且付出行动去修复这些被检测发现的漏洞。当然你的检测效果足够好是一个最基本的要求，你要保证你的准确率是足够高的，误报率同时又是足够低的，这样才能最大程度的保证研发兄弟的每一次修复工作都更有价值。

最后，要支持一键修复： 这也是最后一公里，就是修复安全问题的成本要足够低，过去很多安全产品都只管扫描出一个报告，至于怎么修复，完全不管，你自己去研究吧。这是非常要不得的，好比去医院只管化验、诊断，但是又不给开药或者没有治疗床位一样让人难受。所以最好提供漏洞自动修复的工具，开发者们甚至都不用理解这个漏洞，就可以自动化完成修复，那就太完美啦。

要达到这个水平，成为一个好的安全产品，必须有几个关键点：

1）专业、诚实、不忽悠 ， 安全是一个非常专的细分领域，在一个企业里面懂安全的人很少，其实很多时候老板或者其他技术同事是不懂安全专业的，这样就会出现很多人开始忽悠，比如故意制造误报，明明没有的漏洞，或者本身工具检测不出来的漏洞，胡编乱造，显得自己的漏洞很多。别人不懂啊，所以觉得你检测结果多，那就是牛逼。这就很容易让做产品做工具的人偷懒，走“捷径”。不好好优化产品体验，就忽悠。所以做安全的人，要自己守住底线，哪怕身边别人都在靠忽悠，检测一堆误报以显示自己多牛逼，你也不能以恶治恶，给他来更多误报。你必须把产品做的更真实的同时，把检测效果提升上去，技术的透明度会越来越高。长期以往，会更好的赢得用户的认可。

2）离真实的用户更近，去了解用户使用场景和痛点。 你必须和真正使用你产品的用户走的更近，你必须了解他们日常是怎么使用你的产品的，他们的痛点在哪。产品的功能应该保持克制，好的产品功能一定是更少的，越少的功能解决更多的用户痛点，那就意味着你对用户的需求理解要更准确，覆盖的场景要足够全，然后再进行合理的抽象设计。最偷懒的做法，就是去抄别人的功能甚至代码，今年 9 月份的时候，当时我们也遭遇了同行抄我们代码的事情，当然也有同行抄我们产品功能，当然我是当笑话看的。

3）持续不断的获取用户反馈和细节的打磨， 好产品靠的不是一个好点子，或者灵光一现，好的想法固然重要，但是最终拼的都是你能够从客户和用户那边获取多少有效的反馈，以及你能消化和理解多少。最终将这些体现在你的产品能力上，这些都是需要夜以继日的去仔细打磨的，好的产品都是磨出来的。

我跟团队说，我们沉下心来，花 3 年时间，和社区的开发者们一起，打造一款全球最好用最牛逼的安全产品，真正面向开发者们的好安全产品。一开始，我的一些新同事是取笑我的（大概他以前的公司从来没有人告诉过他们我们要做什么全球最好的产品这样的话吧），后来他们发现我们是认真的，便也就再也不笑了，转而埋头苦干。

向埋头苦干的同事们致敬：

（一组珍贵的照片）

Part 4：诚邀朋友们来体验我们 3.0 产品

好了，说了这么多，其实，我认为开发者并不是不想解决安全漏洞，相反是期望有更好的产品和工具来辅助他们快速提升代码安全质量。基于开发者这样的诉求，我们正式发布了 3.0 的新产品，新版本会进一步优化产品体验，提升开发者的使用效率，欢迎开发者们、devops 工程师及安全工程师们来体验体验吧，访问官网，使用手机号注册就可以免费使用啦 http://www.murphysec.com

最后，我在元旦后，会带来一场直播，我和我们的产品经理们给大家讲讲我们的 3.0 产品，也会给大家分享一些软件供应链安全治理的企业最佳实践。欢迎大家预约搜索视频号“墨菲安全”预约观看。