allow passing Gemfile.lock paths to bundle audit

[jsduke]

either as a single file or as multiple files in the same command.

[postmodern]

Scanning multiple lock files is related to #181. Would definitely like to support that.

[ecbrodie]

@postmodern A situation where this could be useful is when I only want production-level gems to be checked and I want development gems to be excluded. I could maintain a Gemfile.lock file specific to just my production gems in my project, and point bundle-audit to it.

Although it's nice to be protected against all vulnerabilities, sometimes it is less urgent to resolve a vulnerability if it's just affecting a development gem. It allows CI pipelines that depend on a clean bundle-audit run to continue to be in a green state if only non-production gems are affected. For example, today's new vulnerability on rubyzip is disruptive to a project I'm involved with because a fix has not yet been published to rubygems. But, my project only depends on rubyzip through a gem used for unit tests only. Why must we now have our CI pipeline go into a RED state and cause disruption in our project?

[mallyvai]

Going to +1 this - we would really appreciate this feature for CI purposes.

[dstull]

+1 for same CI purposes

[postmodern]

0.8.0 now supports a --gemfile-lock option and the command can accept a DIR argument.

[postmodern]

bundler-audit 0.8.0.rc1 has been released! Please test and provide any QA feedback.

$ gem install --pre bundler-audit