Skip to Content
Product Information
Author's profile photo Frank Koehntopp

Getting a grip on Open Source dependencies in 10 minutes or less

[ #disclaimer: This blog post will refer to non-SAP services that may are usually free for public GitHub repositories or Open Source projects, extended use may require paid accounts ]

The Open Source fallacy

In todays software projects Open Source accounts for more than 50% of the code, and that percentage is on its way up.

For some strange reason, most development teams still treat Open Source components as software that is magically great and perfect and does not require any consideration over the lifetime of their projects.

To put that in different words: in addition to your 5-person development team, there are another 5 developers that regularly push code to your repository, and noone takes any notice. No pair programming, no automated tests, no static code scans, no Gerrit Code review.

 

The other problem: Security

I’m That Security Guy, so I will add yet another perspective: Those developers are no better at writing secure code than you are, so bad things may happen.

 

Looking at the TOP 20 Java libraries used in 2018, com.fasterxml.jackson leads the list.

(from https://blog.takipi.com/the-top-100-java-libraries-in-2018-based-on-277975-source-files/)

 

And it comes with an impressive amount of security issues, most of them rather serious:

(from https://www.cvedetails.com/vulnerability-list/vendor_id-15866/product_id-34008/Fasterxml-Jackson.html )

A tiny bit of research will even produce proof of concept exploit code (left as an exercise for the reader)

 

So, what’s a developer to do?

(h/t to Gary McGraw)

 

Seriously – skip the time arguing about “But CVSS is only 5.8” (seriously????), “I will need to test if I update” (you *are* running automated test to make sure third party code works, right? RIGHT?), “the vulnerable code is not reachable!” (well, how much would you want to bet on that assessment? What about the new code you are going to write next week…?), or “It’s too hard!”.

It’s not, and I’m going to show you how.

 

Keeping your dependencies up-to-date and secure

Open your GitHub repository and follow along, I’ll be quick.

 

Create account on https://mergify.io/

Mergify is a service that automates pull request handling based on a rule engine. We’re going to set it up to merge update notices for outdated and/or known vulnerable Open Source packages automatically. More information and documentation can be found at https://mergify.io/#how-it-works .

 

Add a file with the name “.mergify.yml” as below:

pull_request_rules:
  - name: automatic merge of dependabot pull requests
    conditions:
      - author=dependabot[bot]
    actions:
      merge:
        method: merge

 

Push it

git add .mergify.yml
git commit -m 'Added mergify.yml'
git push origin HEAD:master

 

Add your GitHub account and repository in the dashboard.

Now you’re ready for the pull requests.

 

Create an account on https://dependabot.com/

Dependabot will analyze your repository, identify Open Source packages, check the version and create pull requests if there are newer versions or known security issues.

Again, add your GitHub account and repository.

Watch the pull requests come in

and disappear just as fast.

 

That wasn’t difficult at all, was it…?

 

Keeping up to date about publicly known security vulnerabilities

Switch on “Issues” and “Vulnerability alerts” (optional)

Get an account on https://snyk.io/

Add your repository, and you’ll be alerted to any newly discovered issue.

 

 

Extra benefits

As an added benefit: If you’re running 1.2 of anything, and there’s a 1.9 – do you think it’s possible there may be some functional fixes that are not in your code, yet…?

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Nice blog! I'm not much into open source (not yet, at least) but if I was it seems like a good recommendation.

      I find it ironic that many times developers ignore security people (especially Those Security Guys) the way teenagers ignore their parents. Which always ends well, as history tells us. 🙂

      Thanks for sharing!

       

      Author's profile photo Mike Doyle
      Mike Doyle

      Nice work, Frank. This kind of advice is useful and novel. More please!