Enhancing security insights for RubyGems

[lirantal]

I'm having a problem or would like to suggest a feature.

This issue is related to:

• Installing a library
• The command line gem
• RubyGems.org

---

Hey folks,
Liran from Snyk (open source security) here 👋

Me and my team have been spending some time recently working with the community to increase the security awareness for developers as they use dependencies. A good couple of examples of that which we've done already with community folks are a small widget on jsDelivr and CDNjs like this.

I'd be keen on exploring some ideas I have about integrating a quick widget on package pages, or even further enhancing the gem/bundler CLI with vulnerability insights on install, much like npm install does by default. The RubyGems vulnerabilities database (and other ecosystems) is already open https://snyk.io/vuln?type=rubygems and we could make APIs available to tie all of this up.

Happy to jump on a call or discuss further here/elsewhere if this is interesting for the community.

or like this on yarnpkg:

I will abide by the code of conduct.

[matkoniecz]

even further enhancing the gem/bundler CLI with vulnerability insights on install, much like npm install does by default

Note that this would be not enhancement - it just leads to a pointless confusion such as in openstreetmap/iD#5463 (comment)

Yeah - People don't really like this security audit feature because it highlights stuff like this in the dev dependencies that are not real vulnerabilities.

Even though mapillary is using brfs to assemble the sprites for browserify, the vulnerability can't affect us downstream because we only use the svgs from their repository. iD doesn't actually run brfs anywhere.

The overagressive warning is reported here: npm/npm#20564 and I think they are working on it, but it's hard to tell since they have switched the project to a new repository.

Maybe it is possible to do it well, but please do not base anything on anything done by npm.

[lirantal]

@matkoniecz great context. I'm not here to praise snyk vs npm audit but there's definitely a lot of room for improvement on npm's part that indeed causes a lot of the fatigue you referenced, for example:

• snyk by default doesn't report on devDependencies
• snyk's recommended fixes are always the most minimal semver upgrade possible, unlike npm which just updates to latest and may cause deps to break due to semver major releases

I'd like to see where we can help with our APIs and vulnerability dataset, whether it is for the CLI tools or for the website.

[colby-swandale]

The rubygems team would be happy to hear about any ideas/proposals ideas you have, but please be understandable that we are very cautious about integrating with any 3rd party systems and have a strong preference for managing data/functionality ourselves.

[matkoniecz]

Maybe it would be better first as a separate CLI tool allowing to evaluate whatever it is useful at all?

In addition to npm case - similar attempt by Github keeps spamming my inbox about irrelevant supposed security issues (things that are problem solely in software accepting user input in software that never accept user input from untrusted users and so on).

[lirantal]

With regards to testing out the capabilities you can already do that in various ways, and snyk is free for open source devs and maintainers:

• use the snyk cli with install instructions here
• or connect simply login to snyk with your github/bitbucket and import a Ruby project.

More about snyk ruby support over here.
I'd love to hear your feedback and what you make of it @matkoniecz among the rest of the tooling for ruby in this space.

@colby-swandale totally understood, and makes sense too. we're happy to provide you with any of the APIs you need to get security badges up on rubygems.org for packages, or to integrate with the CLI for more integrated feel. I'd say further more, we could push a vulnerabilities feed down your end of the infra and then you just integrate everything internally without an actual 3rd party API call on the website or the CLI.

We genuinely want to help the community and it's more than just helping out with the vulnerability database and also extends to our security analysts. We handle disclosures and report about ruby gems security issues today and would be happy to help where we can and connect ruby's security team with snyk's for anywhere we can help out, whether it is triaging, providing fixes, or alerting rubygems.org security folks or the gem's maintainers directly if needed for an early heads up.

[matkoniecz]

I have not found reasonable way to install it, but I noticed mandatory snyk auth ("Once installed, you need to authenticate with your Snyk account:").

I hope that such requirement to authenticate with Snyk would be gone from anything appearing in rubygems.org software, especially things enabled by default.

[lirantal]

Good feedback. What would be an ideal way for ruby developers to consume the snyk CLI? I assume a gem? what would be the next best thing? :-)
Just to note that I'm not proposing for any ruby developer to consume the snyk CLI at all, but rather to build these capabilities to already existing ruby CLIs like gem or bundler through APIs and a vulnerability data set that we can provide the community.

Needless to say, a further 'auth' type of things won't be necessary. The relevant ruby CLI could hit an anonymous endpoint on our end, or we'll push the data to rubygems own system and it will query its own, whichever suits best really.

[matkoniecz]

What would be an ideal way for ruby developers to consume the snyk CLI? I assume a gem?

Yes, when I am installing ruby tool I expect gem install --user-install whatever similarly like for Python tools I expect pip and I guess that node developers expect npm. Preferably without need to install system packages and other additional third party tools.

[lirantal]

Would using brew or scoop depending on your OS, or even via a docker container be a reasonable way to consume the tool or do you feel that is too far out there?

[matkoniecz]

Would using brew or scoop depending on your OS, or even via a docker container be a reasonable way to consume the tool or do you feel that is too far out there?

I use solely Linux so it is hard for me to comment what is preferred/normal/used among Windows/Apple users (and even for Linux it is strongly personal opinion). Though I consider Docker containers to be quite weird overkill, useful in cases where someone build extremely complex tool. What sometimes is needed but from description this tool seems like a simple blacklist of insecure versions.

[lirantal]

Completely agree.
I want to circle back to the original point - I think you're totally right about being able to use snyk if it is provided as a ruby package that is easily installed from the ruby toolchain.

Also a friendly ping to @colby-swandale @hsbt.
What would be an ideal way to continue the conversation :-)
I shared some ideas of what can be done and I want to make it the most convenient developer experience for Ruby devs.