什么应该是一个良好的开源依赖扫描频率？

Question

我们使用Snyk作为开源依赖扫描程序。我们目前在每个拉请求上扫描易受攻击的库，这会给我们的开发人员带来开销。什么是好的开源漏洞扫描频率？它应该是每周，双周，每月还是连续？

我试图向我的团队推荐AppSec流程，并希望了解行业实践。如果有一个最佳实践指南，这也会有所帮助。

Answer 1

您的漏洞管理策略是什么？

开发人员是否不能在他们的应用程序中引入任何新的漏洞？如果是这样的话，PR造成的‘开销’扫描是无关紧要的，因为他们需要在推进生产之前修复漏洞，并且越早发现这些漏洞越好。

修补漏洞的时间间隔是多少？这将决定你的扫描频率。最佳做法是在发布修补程序后48小时内修补关键漏洞，如果是这样的话，您将需要能够快速检测关键漏洞，并且每月运行扫描将无法满足您的要求。

当前对应用程序安全性的关注是“向左移动”--因此在开发过程中尽早检测漏洞。在PR上进行扫描是一个很好的开始，我会保留这个安全控制，但是您可能希望使用Snyk提供的IDE扫描仪，并且让开发人员习惯于在提交代码之前扫描易受攻击的依赖项。

开发没有漏洞的应用程序不是一项开销，而是一项要求。

Answer 2

我从未使用过Snyk，但我使用过类似的工具。

对每个拉请求运行扫描似乎是不必要的，除非该拉请求会对您的依赖项进行更改。根据我对Snyk文档的理解，Snyk扫描您的清单文件并上传依赖项及其版本。在更新Snyk的漏洞数据库时，它将提醒您注意您的依赖项中任何新发现或报告的漏洞。除非要添加、删除或更新依赖项，否则不需要重新扫描。

我要考虑的第一个问题是，您更改依赖项的频率有多高。如果您定期更改依赖项，则可能需要更定期地扫描清单文件中的信息并将其上载到Snyk，以确保报告的准确性。但是，如果您不经常更改依赖项，则可能不需要经常进行扫描。如果瓶颈是运行扫描和将结果上传到Snyk需要多长时间，我不确定是否需要对每个拉请求执行此操作。

如果您确实希望获得最准确的信息，您可以向构建服务器引入某种逻辑，以检测清单文件的更改，并仅对对清单文件进行更改的拉请求执行Snyk扫描。

在我看来，更重要的是，你多长时间检查一次Snyk的结果。当项目中的依赖项存在漏洞时，Snyk似乎确实通过电子邮件、Slack和其他工具提供推送通知。此推送通知可能有助于触发您的分类过程，以确定您是否暴露于该漏洞，并了解您需要做些什么来减轻它。

如果您已经将Snyk引入到一个具有大量依赖项的现有项目中，那么您可能会在一种模式下使用更新来修补现有的漏洞。但是，在这里重新扫描每个拉请求并不会有什么帮助，除非您正在发出大量的小拉请求来更新每个依赖项，并希望Snyk能够检测到更改。不过，我不确定这是不是个好办法。我倾向于确保您有良好的自动化测试覆盖率，更新您的依赖项，对代码进行任何更改以说明新的依赖项，并同时运行自动化和手动测试以确认您的更改是好的。这是一个很好的策略，如果您有大量非常过时的依赖项，并且正在进行重大的更新--可能需要做大量的工作来替换依赖项，并且它可能值得发布它自己的版本。

有一个更健壮的流程来控制何时添加依赖项，并确保这些依赖项没有漏洞，漏洞得到缓解，或者该漏洞不影响您的系统也是必要的。这并不一定需要使用Snyk。有开源项目的数据库及其漏洞-- Snyk维护一个，摘要也是如此.执行轻量级供应商评估以确保新的依赖项不会引入新的漏洞，而且您只是引入了维护良好并提供可接受级别支持的依赖关系，这是一个很好的习惯。

在这一切之后，我会喜欢每晚或每周一次的扫描。在我研究过的更复杂的系统上，运行完整的测试套件(从单元到系统验收)需要几个小时。这种测试每天晚上在开发分支上进行。在这里集成一个开源依赖扫描程序可以确保您的报告始终是最新的，而无需在每个构建中引入额外的步骤。开发人员可以每天早晨检查构建，并检查失败的测试以及在依赖项中发现新的漏洞。这也是在您的代码上运行静态分析的好时机，如果您想获得很高的安全性，可以部署到测试环境中并运行动态漏洞扫描器。