下做好依赖管理的十五条准则( 四 ) _pcre

在event-这个案例中，恶意代码被隐藏在一个不同的包中-，而event-发布新版本时就将这个包作为新依赖引入进来了。
这些间接依赖所造成的影响也会体现在你项目构建后的包的尺寸上。
在的（一门 JIT 日志处理语言）中，作者发现：
在不同时候，其主解释器二进制文件不仅包含的 JIT 信息，还包含从未使用过的、、的解释器。
每次细查发现，其原因是所依赖的某些库声明了一些从未使用的其他依赖，再加上的构建系统会自动处理新的依赖关系，从而导致上述结果。
这类错误正是 Go 语言为什么会将未使用过的导入当成是编译时错误的原因。
6、什么时机用来检查是否继续使用原有的依赖
当然是升级版本时。
定期重新检查依赖是否有变化也很重要。
重新查看每个依赖项的安全相关历史记录也很重要。
例如，在 2016、2017、2018 均披露过不同的严重远程代码执行漏洞。
所以，即使你的服务器都已升级到其最新版本，但有着这样的安全历史记录，你应再三思考是否应继续使用它。
3 条小建议
软件复用的时代已经来临，
我们不能低估其带来的好处：软件复用为开发者带来了巨大的便利。
尽管它的好处固然不可否认，但我们在这股转变的洪流中，还没来得及认真去思考随之而来的风险。
今时不同往日，我们拥有太多依赖，已经不能再像二三十年前那样「过于信任依赖」了。
说实在的，对依赖项进行严格的验证、测试会有很大的工作量，并且大部分团队做不到这一点。
我甚至怀疑是否真的有开发者做到了对每个新引入的依赖都做了上述工作。
大部分情况下的决策完全就是「先用着再看」，
而且，再往前一步就会增加很多工作量。
但 Copay 和公司被入侵的案例已经敲响了警钟：
我们现在这种使用依赖的方式真的存在严重问题。我们不能对此掉以轻心。
为此，我提出下面 3 条建议：
依赖包管理器已基本消除了下载和安装依赖的成本。
未来的开发工作重点更应在于：降低评估和维护依赖的成本。
例如，
世界上优质的软件这么多，为更安全可靠地复用这些软件，我们应携手前行。
参考阅读
做好依赖管理的十五条准则（上）

下 做好依赖管理的十五条准则( 四 )

下做好依赖管理的十五条准则( 四 )