现代软件开发的依赖树让黑客更容易从小型开源项目入手攻克。

若恶意黑客参与了小型开源软件的开发，在自身关键应用中包含了这些开源软件的公司企业就可能面临遭遇漏洞利用的风险。

安全专家指出，这些项目的开源本质和代码的广泛应用，对企业造成了切实的威胁。

一旦潜入开源项目，罪犯就有多种下手方式可供选择，但必须动作够快。

因为无论是后门键盘记录器还是某种木马，如果不是动手够快，或者真的非常非常隐蔽，用不了多久就会被 “众人之眼” 揪出。

网络罪犯之所以热衷于黑开源项目，正是由于开源项目兼具灵活性和可用性的特点，能为黑客行动的开展带来大量机会。

真可谓众所周知的攻击途径了。

而且开源项目被黑概率很可能比大众认知的要高得多。

安全公司 Checkmarx 安全研究主管 Eran Yalon 就表示：“这可不是什么道听途说，而是身边时时刻刻在发生的事。

以前就曾出现过这种事情，我们没理由认为现在就绝迹了。

几乎所有开源项目都要求贡献者的工作要经过项目其他成员审核才能并入项目。

审核层级随贡献者个人声誉而递减，贡献者受信度越高，则审核层级越少。

尤其是在大型知名开源项目中，比如主流 Linux 发行版，整个审核过程非常精细完备，也有充足的人力资源持续执行这一规程。

项目越小，则可供保障安全的资源就越少。

所以，小型项目被黑的情况也就更常见了。

小项目，大影响专家指出，超小型开源项目是黑客注入恶意代码的重灾区。

超小型开源软件包也有可能是大型软件包的依赖，无论依赖层有多深。

你觉得自己的项目只有一两个依赖，但实际上可能有成百上千的，而且你根本无法彻查。

比如说，由个人开发并维护的开源项目 Event-stream 就被恶意黑客接手，成功向经由流行 JavaScript 包管理器 NPM 分发的代码库中注入了恶意代码。

“Event-stream 项目的开发人员没有足够的时间来维护。

一名恶意用户说服了开发者，接管了该项目。

刚刚接管的时候该项目还是像以往一样维护。

此后，这名恶意用户修改了 Event-stream 自身依赖的一个包，注入了可以劫持特定比特币钱包的代码。

该攻击的影响范围有多大？该项目代码每周下载量近 150 万次，用在其他 1,600 多个软件包中，而这些软件包自身又各有数百万次的下载量。

另一起非恶意事件例证了小型开源软件包的深远影响：2016 年 3 月 23 日，开发者 Azer Koçulu 删除了他通过 NPM 分发的 250 个模块。

其中一个模块非常之小，仅含 11 行代码，是往文本字符串左侧添加空格以适应变量定义的。

结果，这个名为 “left-pad” 的模块是全世界成千上万的企业和商业软件所用依赖包的一部分，包括用 JavaScript 开发的中流砥柱 Babel 和 Node 构建的那些。

而由于 “left-pad” 下架，这些数以千万计的应用全都失灵了。

虽说开发者重新创建该功能也不是很难，但如此简单的动作受到的短期影响也已经十分巨大。

(近) 普遍威胁开源的普遍性众所周知。

Gartner 数据显示，95% 的企业在内部项目中使用开源代码。

鉴于敏捷开发运维方法的时间压力，由内部开发团队编写自有功能和函数库来打造确定性防御的做法，是不太可能被采用的。

于是，开发团队怎么增强代码安全性呢？第一步就是甄选纳入技术栈的库和开源项目。

有些项目的 “履历” 优于其他项目。

第二步，确保所用项目是活跃项目，有定期更新。

查看项目的活动历史可以确保项目是有众多活跃开发者支持的好项目。

有漏洞出现时能被及时修复的概率也高得多。

而一旦补丁可用，要确保及时应用补丁修复漏洞。

常有关注零日漏洞和黑客国家队的组织机构自己的 “基本代码安全” 却没做好。

保持开源代码更新和做好基础的代码扫描，才是最基本而坚实的网络威胁防线。

这就是个信任问题：对开源项目和使用该代码的内部开发人员的信任。

恶意开源代码包如果没人用，也是不会造成严重后果的。

IT 部门里谁能升级或修改软件包必须有着非常明确的规定。

必须有人监管着所发生的一切。