文章总结： 文章讨论了SRC挖掘现状，作者分享了自己挖掘两个APP漏洞的不同经历，分析了SRC运营团队强势与弱势对漏洞认可的影响，探讨了内部已知暂不修复现象，最后建议新手入局SRC应有完整工具或方法论，不建议手动审计。文章反映了当前SRC生态中白帽子面临的挑战和企业安全责任问题。
综合评分： 85
文章分类： SRC活动,漏洞分析,实战经验,安全意识,漏洞POC
SRC挖掘现状浅谈
原创
小虾安全
小虾安全
2025年9月7日 11:48
北京
SRC挖掘现状浅谈
最近这两天有了好多互联网大厂的瓜,
师傅们辛辛苦苦挖出来的洞不被认，不给钱，成了讨薪的黑奴。
笔者很能感同身受:笔者在某央企工作的时候，闲暇之余也去做了APP漏洞挖掘，
恰逢当时字节开源了appshark(https://github.com/bytedance/appshark)，
笔者对着南大的程序分析课程和 appshark 源码一顿啃，然后写规则，去扫描APP。
后面还真挖到了两个APP漏洞，
一个是RCE，一个是LaunchAnyWhere。
当笔者发送两份报告给这两个厂家。
RCE漏洞的厂家立马响应，但是需要我隔空和开发battle，
最后给了3k RMB。
LaunchAnyWhere 漏洞的厂家隔了一个月发送了邮件，
最后在我的催促下回复了邮件：
忽略原因很简单: 内部已知，暂不修复
笔者还是很感谢 LaunchAnyWhere 漏洞这个厂家，
因为是它让我抛弃了挖 SRC 的行为——尤其是和独立安全研究员的哥们聊国外SRC漏洞现状之后：
在经历内部已知，暂不修复这个事情之后，
笔者直接跳去互联网厂商去做逆向和业务去了，去TM的漏洞挖掘和安全研究。
但笔者今天想讨论一下这两个不同结果的原因以及笔者的看法。
关于SRC
SRC创立的初衷
SRC 运营与白帽子的良好沟通是：
减少黑产利用漏洞攻击、漏洞攻击前的漏洞治理，
并且根据白帽子交的漏洞可以扩大内部蓝军对企业漏洞攻击面和规则梳理。
SRC运营团队强势
所谓 SRC 运营团队强势，
是指 SRC 运营团队具有一定的地位，
并且这个运营团队大老板是认可的。
那么SRC运营团队就可以直接替白帽子去和业务battle。
实际上 漏洞认可最后必须是业务部门认可，仅仅是安全部门认可是没有用的。
这点在 RCE 的厂家是很能看出来的，
因为开发部门不认可漏洞，
所以安全部门当时要求我写一些漏洞利用的代码和POC，安全部门拿这个去和业务部门battle。
最后上升到了更高的领导层把这个事情敲定了下来。
对于SRC部门来说，维持和白帽子良好的关系，才能收到更多的漏洞报告，才会保持SRC的良性运转。
SRC运营团队弱势
SRC运营团队弱势其实更好理解了，
正好与强势相反，
只能把漏洞报告推送到业务部门(或者业务部门的安全团队，这里统一说是业务部门)，
并且业务部门认定是什么就是什么，
白帽子和业务部门的同学面对面battle。
之前笔者也一些业务部门下的安全团队聊过，
他们其实都被提示过如果能够降级就尽量降级(这点很好理解)，
导致业务部门下的安全同学说什么，SRC的运营团队是不能够太介入的。
关于内部已知,暂不修复
其实笔者打探了一些消息，有些内部已知确实是真的内部已知,暂不修复是真的暂不修复。
安全部门push业务部门修复漏洞，业务部门往往会说: ”我们现在很忙，你们安全能不能不要来找事了？”
安全部门的地位懂得都懂，
花钱的不能push挣钱的，导致几个月漏洞还没修复。
但白帽子提交漏洞报告，内部安全部门真内部已知，所以只能内部已知。
但笔者一直认为出现内部已知是企业的责任
-
知道漏洞不修复就好像知道没穿衣服依然裸奔，
对用户和企业自身是一个隐形炸药，体现了企业的不负责任。
-
为什么白帽子测试的时候不给定明确范围以及透明的规则？站在白帽子的立场上这就是消息不对等以及霸王条款
总计
别挖SRC了，家人们，看看远方的字节seed团队增发的期权津贴吧。
如果现在入局SRC，
个人建议是有一套完整的工具或者方法论，
能够快速并且自动化的去扫描一些漏洞，个人最多去POC验证一下，那可以去挖一挖。
如果是手动慢慢的去审计，笔者不是很建议，容易心态炸并且浪费光阴。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：小虾安全 小虾安全《SRC挖掘现状浅谈》