Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
koehntopp
Product and Topic Expert
Product and Topic Expert
1,036
[ #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.htm... )

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...?
2 Comments
Labels in this area