Add criticality filtering to cli #257
Conversation
| scan_sources(options,&block) | ||
| scan_specs(options,&block) | ||
|
|
||
| return self | ||
| self |
| @@ -68,13 +71,10 @@ def initialize(root=Dir.pwd,gemfile_lock='Gemfile.lock') | |||
| def scan(options={},&block) | |||
| return enum_for(__method__,options) unless block | |||
|
|
|||
| ignore = Set[] | |||
| ignore += options[:ignore] if options[:ignore] | |||
|
|
|||
There was a problem hiding this comment.
I could be wrong but I don't see the above variable assignment being used
|
|
||
| def check | ||
| update if options[:update] | ||
|
|
||
| scanner = Scanner.new | ||
| vulnerable = false | ||
|
|
||
| scanner.scan(:ignore => options.ignore) do |result| | ||
| scanner.scan(ignore: options[:ignore], filter: options[:filter]) do |result| |
There was a problem hiding this comment.
Noticed when multiple array options are passed the second one defined (the new one filter) returned as an Enumerable when calling with dot syntax options.filter #=> Enumerable. Instead using symbol key syntax it returns as expected
|
I'm unsure of why this is happening but it seems as though the mock user path expects the directory 1) Bundler::Audit::Database path should prefer the user repo, iff it's as up to date, or more up to date than the vendored one
Failure/Error: expect(subject).to eq mocked_user_path
expected: "/home/travis/build/rubysec/bundler-audit/tmp/ruby-advisory-db"
got: "/home/travis/build/rubysec/bundler-audit/data/ruby-advisory-db"
(compared using ==) |
|
@joshmfrankel Can you rebase? The spec failure should be fixed. |
Why? When utilizing bundler-audit on CI, it can be helpful to filter criticality to find higher criticality gems. What? * Adds filter (--filter or -f) command line argument that accepts array of values * Filters within Audit::Scanner to remove filtered out advisories
joshmfrankel
force-pushed
the
joshmfrankel/add-criticality-filtering-to-cli
branch
from
fc0919e
to
ebc6516
Compare
|
Rebased with upstream Looks like that did the trick. Thanks @reedloden |
|
I am a bit concerned that filtering by Criticality may cause low severity vulnerabilities to go unpatched/unmitigated. I'd settle instead for sorting the advisories by criticality, and possibly color coding their text based on Criticality. |
|
Also checkout the lib/bundler/audit/cli/formats/text.rb in the 0.8.0 branch. 0.8.0 is going to be merged/released soon. |
|
I support this feature/cli flag as well. bundler-audit is awesome and I encourage teams to add it to their CI pipeline order to provide a forcing function to patch vulnerable gems. But, there are a couple of use cases where only failing on a certain level would be useful
|
|
@ryanwi I could see a severity filter being useful for triaging bugs, where you only want to look at the Critical vulns first, then the Highs, then the Mediums, etc. Although, I want to discourage people from thinking that Low Severity vulnerabilities are harmless. The CVSS Score that denotes Severity is a crude metric for how serious a vulnerability is. An unpatched Medium or Low severity vulnerability could still be exploited by an attacker. |
|
This feature would be great for us. Currently we have build breakers setup to stop builds and deploys any time we run into a CVE. It most cases the CVE criticality starts out as Unknown and then later gets updated with a more accurate level. If we had the ability to filter on different levels or have different exit codes, we'd be able to tweak our build breakers to only fire on critical and high for instance but have another CI job to alert on medium, low, none, or unknown. |
Although, you would risk potentially passing a build with a CVE that's currently Unknown, but then later is updated to be Critical. I think it's safer to view every CVE as potentially critical. |
Why?
When utilizing bundler-audit on CI, it can be helpful
to filter criticality to find higher criticality gems.
What?
accepts array of values (low, medium, high)