GitHub安全实验室的研究员每周都会接触大量开源项目维护者。一个反复浮现的困境是:设置页面太密、文档太散,很多维护者不是专职安全工程师——但完全忽视安全配置,意味着放弃自动化和规模化防御,漏洞会在你察觉前堆积起来,最终暴露用户数据。
有六项设置,全部免费,更新耗时不超过半小时。我们已将它们打包进一个名为“保护你的项目”的引导流程,下面逐一拆解每个工具。
![]()
第一项:添加SECURITY.md文件。这是清单中最轻量的操作,却能让你应对漏洞发现时不再被动。这份文件告诉发现漏洞的人该把报告发到哪里——没有它,善意的研究者只能选择公开提交缺陷(等同于公开利用代码),或者想办法找到你的个人邮箱。文件不需要写太多:提供一个直接联系方式,让漏洞报告人能私下联系你;然后划定哪些类型的漏洞在受理范围内,以及沟通时的注意事项。可以参考systemd项目的安全策略,它设定了清晰的复现预期,也不假定你有全天候待命的响应团队。借用结构,改掉联系方式,提交——最多十分钟。
第二项:开启私人漏洞报告功能。这份功能为研究者提供了私下提交报告的渠道。启用后,安全研究者可以在你的仓库中提交机密公告,你在非公开环境中完成分类,再按自己的时间线披露。设置入口就藏在“设置→安全”里的一个复选框。如果今晚只能做一件事,把前两项一起做完:它们免费,并且是用最快速度向社区传递“我把安全当回事”的信号。
第三项:开启秘密扫描,并部署推送保护。这是失败模式最令人尴尬的一项。GitGuardian的《2026年秘密扩散状况》报告显示,2025年公开GitHub仓库泄露了2865万个新秘密,比前一年跃升34%,创下单年最大增幅纪录。AI辅助提交泄露秘密的速率大约达到基准线的两倍。IBM《2025年数据泄露成本报告》指出,全球数据泄露平均成本现为444万美元,美国则高达1022万美元。秘密扫描能捕捉密钥和令牌——当一个包含凭证的提交试图进入仓库时,推送保护会在源头拦截。
剩下的三项设置连同上述工具一起,组成了我们在安全实验室向维护者反复强调的最小可行安全基线:它们分别涉及分支保护、依赖项审查和工作流程权限。分支保护规则防止未经审查的代码直接进入主分支;依赖项审查在拉取请求中标注新增依赖的改动和安全影响;工作流程权限将令牌的默认访问范围收窄到仅读取仓库内容,若需要写入权限则显式声明。这三项同样免费,同样在“保护你的项目”引导流程中依次配置。
这六项配置不会让你的项目变得坚不可摧——世上本无绝对安全的代码仓库。但它们会关掉所有虚掩的门。打开这些开关,你的项目会实实在在地比昨天更难被攻破。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.