fix: update vulnerable ruby dependencies

[cheungaryk]

Hello, this is related to #936, Richard (that PR's submitter) and I work for the same organization.

We are trying to get vale to be approved for use in our organization. The security review found multiple vulnerabilities that need to be patched before approved. So I created this PR and also #938 .

This PR patched the vulns related to ruby/testdata by upgrading the dependencies especially cucumber and aruba. I have also upgraded the bundler version to 2.5.23 which is closer to what the appveyor CI/CD agent uses (2.5.18).

Thank you!

[cheungaryk]

cc @jdkato . Let me know if you have any questions. 🙏🏼

[jdkato]

I haven’t had a chance to review either PR in detail, but I’d like to point out that the term “vulnerable” is being used too loosely here.

The Ruby “dependencies” are exclusively used for testing within a controlled CI environment, using input that I provide.

From the perspective of someone who installs and uses Vale, there are zero Ruby dependencies and therefore no related security concerns.

Likewise, with Go, your security review is flagging many (all?) reports that are unrelated to Vale’s actual use of the libraries. Such imprecision should be noted when referring to so-called “vulnerabilities.”

[rsexton404]

Apologies for my imprecision! I should have phrased my original PR more carefully, especially as a new contributor. I think our organization (and many others like ours!) maybe rely too much on these automated code scanning tools and their reports even for code that isn’t part of the core tool. Be that as it may, updating these various dependencies will make it possible for large (and yes, bureaucratic) companies like ours to adopt Vale and make contributions. Thanks for understanding and for looking at the PR!

[cheungaryk]

Thanks for the quick reply, Joseph, I appreciate your explanation and agree. +1 to what @rsexton404 wrote in response.

To be clear, the issue Richard and I are facing is that our scanning tool does not know, or care where these "vulnerabilities" are indirect or unrelated. All it cares is that they don't exist anywhere in the codebase, and it will only approve our usage when we get the most severe ones fixed.

We can update the titles of the PRs if you would like us to (perhaps remove the word "vulnerable"?)