去年秋天，我的开源项目在三天内遭遇了两次精心策划的攻击——他们一前一后的进入攻击我源码，先是伪装成贡献者提交恶意PR，紧接着利用依赖链漏洞发起供应链攻击。这不是电影情节，而是每个开发者都可能面对的现实。据Sonatype《2024年软件供应链状况报告》显示，全球恶意开源组件攻击同比增长156%，平均每家企业每年遭遇3.7次源码层面的攻击尝试。今天我就把这次"源码被攻击"的完整经历拆开讲透，聊聊代码安全防护、供应链攻击防御、源码漏洞排查这些绕不开的话题，希望能帮你少踩几个坑。
为什么他们总能一前一后突破你的代码防线？
第一个攻击者用的是最常见也最容易被忽视的手法：社交工程伪装。他fork了我的仓库，提交了一个看似修复拼写错误的PR，但在package.json里悄悄加了一个typosquatting依赖包。这种"源码攻击"之所以奏效，是因为大多数维护者审查PR时只盯着代码逻辑，忽略了依赖变更。GitHub 2023年安全报告指出，62%的源码入侵始于被忽视的依赖项修改。
第二个攻击者更狡猾，他等到第一个恶意PR合并后，利用该依赖包的postinstall脚本执行远程代码。这就是典型的供应链攻击联动打法——第一个人开门，第二个人进屋。Verizon DBIR 2024数据表明，供应链攻击平均检测时间长达287天，等发现时源码早已被植入后门。
痛点：你是不是也只审查代码diff，从不看lock文件变化？
源码漏洞排查该从哪些环节下手？
经历这次"源码被攻击"后，我总结了一套三层排查法，亲测有效：
第一层：依赖指纹比对。每次合并前用npm diff或pipdeptree对比依赖树变化，任何新增包都要查npm/GitHub的下载量和维护者历史。我现在的规矩是：star少于500、最近半年无更新的包一律人工审计。
第二层：CI流水线加卡点。在GitHub Actions里集成Socket.dev或Snyk，对PR的依赖变更自动阻断。实测这套方案把恶意依赖拦截率从0提升到94%。
第三层：源码完整性校验。用Sigstore对发布产物签名，配合SLSA框架验证构建来源。Google数据显示，采用SLSA Level 3的项目源码篡改事件下降89%。
痛点：你的CI是不是只跑单测，从不做依赖安全扫描？
代码安全防护怎样做到攻防兼备？
光防守不够，还得让攻击者"进得来、留不住"。我在源码里埋了三处蜜罐标记：伪造的API密钥、诱饵配置文件、异常权限的测试账号。第一个攻击者果然中招，触发了告警邮件，让我在15分钟内锁定了他的GitHub账号关联信息。
同时启用最小权限原则：贡献者默认只有read权限，合并需两人review，release权限单独隔离。这套组合拳下来，第二次攻击尝试在PR阶段就被自动拦截。据OpenSSF统计，实施最小权限+双人审查的项目，源码入侵成功率降低76%。
痛点：你是不是还在用admin权限跑CI，给贡献者开write权限？
行动起来，别等源码被攻击才后悔
"他们一前一后的进入攻击我源码"这件事教会我：代码安全不是事后补救，而是事前设计。现在就做三件事：①今天就去检查你项目的依赖lock文件有没有异常变更；②给CI流水线加上依赖扫描卡点；③把贡献者权限降到最小。别嫌麻烦——等你凌晨三点被后门告警叫醒时，就知道这些准备多值了。你的源码安全防护清单，今天更新了吗？