本文共 883 字，大约阅读时间需要 2 分钟。

基于，旨在帮助开发人员跟踪依赖项、监控程序的安全性，并通过自动创建PR来移除任何潜在的漏洞。

Dependabot联合创始人Gray Baker在一篇中透露，Ruby应用程序很容易就会引入100多个依赖项。而这个数字对JavaScript来说则更高，超过了700。而在这700多个依赖项中只有一小部分（不到5％）似乎是直接依赖项（即开发人员有意识要使用的依赖项），这导致了更高的复杂性。

这些依赖项大多具有“传递性”，也就是说它们被其他依赖项所依赖，它们之间没有直接的联系，与使用它们的应用程序之间也没有。

应用程序所引入的传递性依赖项的数量与每种语言使用的包注册表背后的原理之间肯定存在某种关联。事实上，众所周知，NPM是迄今为止最大的存储库，主要是因为它支持创建小型包，提供了很多其他包所依赖的简单功能。几年前，当一个用于填充字符串的小型包从NPM中移除并破坏了2亿多个其他包和应用程序时，这个问题引起了人们的关注。与之相反的是，Python生态系统在这方面看起来要健康得多，其传递性依赖项的数量与直接依赖项的数量相当。

对于数十或数百个依赖项，要让它们保持最新以便引入安全修复就成了一项关键任务。这就是为什么GitHub推出了功能，当系统检测到某个代码库出现Common Vulnerabilities and Exposures （CVE）列表提到中的漏洞时就会通知代码库管理员。这为管理员提供了宝贵的时间，让他们可以迅速做出反应，并通过升级到安全版本来修复漏洞。可惜的是，他们需要识别出哪个版本修复了漏洞，并通过创建PR来管理代码变更。

Dependabot就是为了解决这个问题而生的，它可以在GitHub上自动创建PR并隔离需要更新的依赖项。这样就可以将监控和解决潜在漏洞的过程与持续集成（CI）工作流程集成起来，确保PR不会破坏应用程序。对于没有持续集成管道的项目，Dependabot为给定更新指定了CI通过率。这个数字是基于所有执行相同更新的项目计算出来的，例如，有3％的项目更新未通过CI测试。

Dependabot可以在上获得。

查看英文原文：

转载地址：http://frynx.baihongyu.com/