bundle-audit check --print-criticality=[level] AND --error-on-criticality=[level]
Nowaker opened this issue · 6 comments
Please allow us to define the minimum criticality level to report (print). For example, if I'm only interested to see Medium and above, I would do:
bundle-audit check --print-criticality=medium
Moreover, in some cases, we would want to print all vulnerabilities, but exit with non-zero code when criticality of any of the vulns is at least Medium. In which case, we could do:
bundle-audit check --error-on-criticality=medium
Obviously, a mix of both would work, e.g. print everything at Medium and above, but error out on High and above:
bundle-audit check --print-criticality=medium --error-on-criticality=high
I'm curious why you would want to see certain vulnerabilities, but not error on them? In my mind, if vulnerabilities are reported, that is bad, and should be alerted/fixed. Even a low severity advisory could potentially lead to a security breach (CVSS scores are a rough estimation, not a precise measurement). If you think a bundler-audit finding is incorrect or can be ignored, then the advisory ID can be added to the .bundle-audit.yml config file under ignore:.
Choosing the criticality level to fail on is a standard in this type of tooling, and is a must-have. https://docs.npmjs.com/cli/v9/commands/npm-audit#audit-level
Printing but not failing is a nice-to-have - being able to see that there's some other vulns that weren't errored on can sometimes raise awareness, and catch a dev's attention during their less busy times.
I'm worried that by allowing to filter by criticality, this will enable users to ignore Low or Medium severity issues entirely, without bothering to update the gem versions or mitigate them. All vulnerabilities must be patched, and is usually as easy as running bundle update. Even low severity vulnerabilities can still be used by attackers to compromise your app/company/users.
The reality is, by not allowing to filter by criticality, you ensure bundler-audit doesn't make its way to multiple CI pipelines. If anything, it's a disservice for the spread of bundler-audit in CI pipelines. I'll stress again: this functionality is a standard for similar tools. That said, thank you for your input.
@Nowaker either fix the vulnerabilities with bundle update and push to the branch again to re-run CI, or make a separate non-production CI pipeline that does not have bundler-audit enabled, so that bundler-audit only runs when a branch/PR is merged into main, staging, or production.
@Nowaker also bundle-audit supports a -F, --format option to outputting the report into json or junit formats. Then you can parse the output and filter the data however you want.
However, I should remind you, that as CEO of Virtkick you are technically liable, iff you intentionally ignore security issues (even if they are Low severity) and those security issues eventually result in a breach that impacts your users, business, or investors. Also, the White House is increasingly becoming open to the idea of finally enforcing mandatory base-line Cyber Security regulations on companies (they are currently focusing on IoT companies, which typically have very low security standards).
Plus attackers routinely data-mine public websites for intel on potential targets. If you openly state that you want to ignore Low severity security issues, that might attract unwanted attention to virtkick [dot] com, or any of it's other infrastructure.
You should probably just fix those Low severity issues and move on. Better safe than sorry.