Removing vulnerable dependencies from SUSPER

Removing vulnerable dependencies from SUSPER

A vulnerability is a problem in a project’s code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Depending on the severity level and the way your project uses the dependency, vulnerabilities can cause a range of problems for your project or the people who use it.GitHub tracks public vulnerabilities in Ruby gems and NPM packages on MITRE’s Common Vulnerabilities and Exposures (CVE) List.

What were  vulnerabilities in SUSPER ?

SUSPER was having vulnerability in Gemfile.lock, Gemfile.lock makes our application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.

What were vulnerable dependencies in Gemfile.lock ?

Two dependency namely Nokogiri and Yajl-Ruby were having security vulnerability.

Nokogiri is an HTML, XML, SAX, and Reader parser. Among Nokogiri’s many features is the ability to search documents via XPath or CSS3 selectors whereas

Yajl-Ruby gem is a C binding to the excellent YAJL JSON parsing and generation library. Older versions of both the dependencies were having security vulnerability.

Security alerts for a vulnerable dependency in our repository include a severity level and a link to the affected file in our project. When available, the alerts also include a link to the CVE record and a suggested fix.

What was the suggested fix ?

One way to fix this problem was to update the vulnerable dependencies to latest versions.

The versions of Nokogiri and Yajl-Ruby which were used in SUSPER are:

Nokogiri (~>1.5)

Yajl-Ruby (1.1.0)

What are the best ways to update dependencies without breaking

the project ?

The best way to update a dependency is to check where those dependencies are used in project and what are breaking changes which are introduced within the dependencies.

How vulnerable dependencies were updated ?

Firstly we updated the Bundler the tool we use to update our gems in Gemfile.lock,from version 1.13.6 to 1.16.0.

We then updated Nokogiri dependency and other sub dependencies using  bundle update nokogiri i.e:

mini_portile2 (2.1.0) -> mini_portile2 (2.3.0)

nokogiri (1.6.8.1) ->nokogiri (1.8.2)

Then we checked the project for integrity , and the project was working well.

We then tried to update Yajl-Ruby, but there was a problem in updating Yajl-Ruby,

We later found that Yajl-Ruby was replaced by many other dependencies.

We therefore updated whole Gemfile.lock . Following are two simple steps to update Gemfile.lock

bundle update

bundle install

 

We later checked that whether the new dependencies do not break the current project and we found that there were no breaking changes involved in updated dependencies.

Security alerts for vulnerable dependencies list the affected dependency and, in some cases, use machine learning to suggest a fix from the GitHub community. By default, we receive a weekly email summarizing security alerts for up to 10 of our repositories. We can choose to receive security alerts individually by email, in a daily digest email, in our web notifications, or in the GitHub user interface.

Resources

Close Menu
%d bloggers like this: