GitHub捡漏SRC的时代一去不复返？

捡漏

简单说就是通过github code search的api，搜索相关src企业的关键字，比如一些大厂内部git仓库的域名，然后按时间排序展示最新的。例如这些项目：

• https://github.com/VKSRC/Github-Monitor
• https://github.com/MiSecurity/x-patrol

简单粗暴，但是很有效，这东西没有太大技术含量，就是调用github的api。 这是github的文档：https://docs.github.com/en

GitHub主要提供两种api：

• REST API
• GraphQL API

这些项目都用的REST API实现的，这个接口：https://docs.github.com/en/rest/search?apiVersion=2022-11-28#search-code

GitHub掀桌了

20230310，GitHub blog发布了一则通知——《Changes to the code search API》

We are deprecating support for sorting code search results. Once these changes take effect, all code search results will be sorted by best match ——《Changes to the code search API》

4月10号开始生效。

意思是4月10号开始，不再支持代码搜索按最新的结果排序，也就是那些什么github泄露监控的搜索结果，搜出来的也不是最新的结果了。

颇有一种“你爷爷决策一失误，我爷爷就得要饭” 的感觉。

那面那些开源项目，也可以宣告终结了，那个接口没有报错，估计还有不少人没感知到这个改动。

在github的文档上，order这个参数备注着 “This field is deprecated” 。

GitHub捡漏SRC的时代宣告终结。

尝试挣扎

如上所说，GitHub提供了两种类型的API，REST API和GraphQL API。抱着侥幸心理，我怀疑这个改动生效只对REST API生效。

尝试在GraphQL API进行突破：https://docs.github.com/en/graphql/overview/explorer

经过一番查找尝试之后，我真想抽GitHub两嘴巴子，GitHub捡漏SRC的时代宣告终结again

思考

那问题来了，现在一般大一点有点安全意识的企业都会在内部布置这样一套监控系统，现在这个系统失效了，那如何确保员工上传到GitHub上的东西没有泄露敏感数据呢？

我不知道GitHub这样改动是出于何种原有，可能是我这种捡漏的太多导致大家对它的安全性有所怀疑？ 那问题是，只关闭发现问题的途径，那问题就不存在了吗？

皇帝的新装——问题看不到，就等于没有问题？