01 引言
随着互联网技术的日益发展，技术栈迭代频繁，市场环境竞争激烈，程序员的新老接替，各种生产故障纷纷频出。
从阿里巴巴、亚马逊到前不久的B站，再到后来的csdn，到618的小红书"开盒"事件等等，在IT圈掀起一波轰动。有在线吃瓜的，自然也有内心担忧的。
我们一起走进小红书的"开盒"事件。
02 起因
6月18日，当电商平台沉浸于年中大促时，小红书却被曝出令人瞠目结舌的技术漏洞。多位网友在技术社区披露：在App"设置"页标题处连续点击6-10次，输入弱口令xhsdev即可进入开发者模式。
开发者模式是开发者用来调试用的后门，为了方便调试，一般会在开发者模式下放置各种开关以及便捷操作，以更快的定位问题和解决问题。
在开发者模式下，提供了日志、抓包和网络代理开关，更是直接暴露了 数据库表机构、推荐算法参数、内部微服务域名及端口等高敏感信息等，这个对企业来说无疑是重要的技术信息泄露。如果有人恶意使用，可能会造成更严重的后果。
看到很多网友评论说，怎么没有充值入口，如果有且有人用了，你可能就要号帽子叔叔聊聊了。
小编6月20号依然可以找到入口，只是口令已经失效了。
03 事故原因推测
最能想到的原因就是内部员工或者离职员工的泄露。开发者模式一般的用户不会触发到后门的，尤其还需要口令才能进去。特殊路径隐藏后门，也是很多小型公司使用的方式。而大厂则考虑的更加安全的机制，灰度测试配置等，加强开发者测试的安全。
行业中，好的设计就会被借鉴使用。很多开发者也会在自己的业务系统重使用，浏览其他产品的使用，一时技痒难耐，戳戳点点，而小红书的口令xhsdev也是非常具有开思维的口令，很容易被测试使用。
大厂的安全机制也需要去配置，如果配置错误也有可能出现类似的问题，如好多年前58同城被一个求职者找到了后台管理界面、饿了么也曾暴漏测试的按钮。
行业技术大佬也提出了几个猜测：CI/CD流水线混用了测试版与正式版签名，导致含调试开关的构建产物被投放到生产环境；Feature Flag配置失控，开发者模式原本由后端配置中心控制开关，但灰度期间误将默认值设为"true"，且未限制白名单；移动发布流程缺少二进制扫描和动态检测环节。
04 争议与辩护
事件爆发后，业内对严重程度评估出现分歧。多数声音将其定位为"P0级事故"，认为其影响范围涵盖业务安全、用户隐私、合规监管和品牌形象多个维度。
每一个公司对于线上故障等级的定义均不相同。而此次事故，可大可小。对外暴露开发者模式就是P0等级的事故么，那安卓本身也有开发者模式，那是不是也算P0级的事故呢，显然不是的。而从数据安全方面，信息泄露方面，可能就不那么简单了。
就我们公司来说，只要对主营业务的主流程没有造成中断、延迟等影响，就不是最高等级的故障，更何况这个是隐藏的路径。即便的隐藏的路径被发现，暴露的后门，不会影响到数据的修改，业务数据被篡改等，同样不会被定为最高等级的故障。当然我们公司也是小庙，哈哈。
05 行业警钟
互联网的被爆出来的一个个事故，都会给每一个公司敲一次警钟。发布规范、安全审查等一直在被各个公司要求着，可能一直都做得不错，但偏偏打个盹的功夫，故障就出现了。或者很多公司把流程规范只作为一个规范，从来没有严格的落实实施过。
当技术栈愈加复杂、交付节奏愈加紧凑，唯有把安全内建到工程文化中，才能守住最后的护城河。故障无大小，谨慎地对待每一个流程节点，安全审计需要前置到移动端灰度A/B流程中，与功能测试并行，避免"测试用"逻辑泄漏到线上。
发现小红书故障后的第一时间，我们也默默的加固了我们自己的开发者模式。