Talking About Open Source Vulnerabilities at Codemotion Rome 2018

Last Saturday I was excited to speak at the recent Codemotion Rome 2018 conference to talk about how important (and critical!) it is to keep the open source libraries of your software up-to-date to minimise your risk to vulnerabilities.

After introducing the problem of vulnerabilities due to live dependencies on open source software libraries, I gave a live demo of how just one well-known open source vulnerability in jackson-databind (CVE- 2017-7525) can be exploited to take control of the targeted system.

It’s incredibly easy to exploit the vulnerability by simply using a JSON message. If you are a software developer or a technical person I encourage you to have a look at this technical explanation, which allows you to reproduce the same experiment I demonstrated.

Some famous victims…

During my presentation, I spoke of three companies that unfortunately suffered from data breaches:

All three are from completely different industries and their systems were targets of a cybersecurity attack exploiting a vulnerability in a third-party open source library.  Two of these vulnerabilities were not newly discovered security holes.  On the contrary, the attack on San Francisco MTA exploited a one-year old vulnerability, and Equifax was hacked using a two-month old vulnerability.  In the case of Canada Revenue Agency,  the attack used a zero-day vulnerability.

In two of the three cases, such attacks would have been avoided if some basic software security maintenance had been in place. Even a fully manual process would have probably avoided a successful attack.

If we look at the situation today, examining three of the most common open source libraries used in modern applications, we can see that the scenario is far from ideal:

Interestingly so, the supporting technical explanation shows an exploit of a vulnerability actually very similar to the one available in vert.x 3.5.1, which in the library is still unpatched.

Why are we using open source libraries then?

At this point, you may ask, “Why are we using these open source libraries if they are potentially so dangerous?” If you want to deliver code quickly then it’s a real time saver if you can use pre-built software components ready to solve all or most of your problems. Why rewrite everything on your own? Unless you see a competitive advantage to do so, most likely you do not want to use your engineering resources to reinvent the wheel but rather accelerate development for faster time to market. Furthermore, if you need access to state-of-the-art algorithms, using open source may be your only option, as you do not want to implement one of those again.

All this contributes to the hard fact that nowadays applications use external libraries and frameworks.

Preventive measures

As this is a very well understood problem, it’s possible to put in place simple preventive measures while also complying with the OWASP Top Ten Application Security Risks. Recently, the risk of using components with known vulnerabilities was added to OWASP and includes these common reasons why you are likely vulnerable:

  • if you don’t know the versions of all your software components,
  • if your software is vulnerable, unsupported, or out of date,
  • if you don’t scan for vulnerabilities regularly, and
  • if you don’t update and fix vulnerabilities in timely fashion

To improve upon the quality of your software, it is essential to build in security into your development workflow. Find out exactly which components and versions you have and get an assessment of your code’s vulnerabilities by using our continuous security platform Meterian. When integrated into your CI/CD pipeline or used as a manual scan, Meterian immediately highlights vulnerabilities your software is potentially exposed to in an assessment report. You can see a sample report here with clear information and indications of how to resolve each vulnerability.

This is a very basic and straightforward action to take in order to not end up in the news like other unfortunate companies have. Are you using a vulnerability assessment tool on your software projects?

Just one vulnerability is enough for an adversary to exploit.

I encourage you to try our Meterian client and get in touch if you need any further information.

Talking About Open Source Vulnerabilities at Codemotion Rome 2018

How are my scores calculated?

Customers who use Meterian to discover and fix vulnerabilities often ask this question.

Meterian’s assessment report displays two scores labelled Security and Stability, which were described in an earlier post.  Assuming a project has no vulnerabilities until one is found, Meterian’s Continuous Security Platform initially assigns a project a score of 100 until it finds a vulnerability.   We trust you understand why no code is ever 100% secure and free from vulnerabilities.

Finding a vulnerability will result in points being deducted from the initial score “perfect” score of 100 depending on the vulnerability advice type and its severity.  

We have three vulnerability advice types:

  • Security  This type of advice is usually related to a very well known security flaw in a library, such as the infamous CVE-2017-5638 that caused the recent Equifax disaster. Deductions for the Security score are based on the Common Vulnerability Scoring System (CVSS) score of the vulnerability advisory and then multiplied by a factor of 5.  In this case, CVE-2017-5638 was assigned a score of 6 by CVSS and therefore Meterian would deduct 6 x 5 = 30 points.
  • Defect  This type of advice is used to report a serious defect in a library that can potentially affect the stability of your system. For example, the memory leak that affects certain versions of Hibernate is a very well known ORM library defect. Deductions for defect types depend on their severity:
    1. minus 20 for each Defect advice with high severity
    2. minus 10 for each Defect advice with medium severity
    3. minus 4 for each Defect advice with low severity
    4. minus 1 for any direct depending library where a patch version is available
  • Suggestion  This type of advice provides a suggestion from Meterian for projects to swap a library for another or to upgrade to the next version for better code maintenance which may impact the security or stability of your code.

The amount of points deducted depends on the severity of the vulnerability.  In our view, lower scores indicate higher risk from vulnerabilities detected in your code. We prefer to err on the side of caution and indicate a strong signal for security risk rather than send a mild signal that might result in security risks being overlooked.  

Some may think our scoring applies a harsh judgement.  Recalling our previous example of CVE-2017-5638, this security advice type has a high score of 10 and therefore Meterian would penalize the Security score of projects with this dependency by -50 points.  Isn’t it better to receive a stronger alert to call attention to bolster your code’s security rather than risk a more mild alert that could lead to undeserved complacency?

So please don’t be intimidated by seeing Security or Stability scores of 0!  Make haste to fix the problems reported as soon as possible to avoid software decay and security risks that are preventable.

 

How are my scores calculated?

THE REPORT

In the previous post we introduced our badges that give an immediate feedback on the status of your code. Badges are handy, but we are really trying to give developers the best feedback possible to allow them to fix possible defects and vulnerabilities quickly.

For those reasons we have created the Report

report

The Report gives you a detailed analysis of your dependencies, listing all the libraries with known security vulnerabilities as well as the ones who have received bug fixes and should be updated. It’s really simple at this point to decide what to fix, and see the Stability and Security indicators increase in the next Meterian scan (see also our FAQ: How frequently does Meterian scan my project?)

In the top part of the page you can notice a selector to visualise the report for each of your project branches; just remember that creating a report takes a few minutes, so the first time you switch to a new branch allow for up to 5 minutes for the report to appear.

Interested in learning more about Meterian? We are looking for companies willing to trial it and work with us to build the next-generation Continuous Security platform. Contact us at info@meterian.com for more details.

THE REPORT

Security and Stability

As we are trying to bring Continuous Security into every software project, we came up with two simple indicators to quantify the health status of a codebase: we called them Security and Stability.

Security measures how likely is a codebase to be affected by security vulnerabilities. A value of 0 stands for “very likely to be insecure”, while a value of 100 is, of course, very secure according to our analysis.  Several factors can decrease the security score: depending on a library with known security issues is one of the major, as well as displaying one of the common “mistake patterns” in the code. We’ll certainly talk more about that in future posts.

The Stability indicator shows how likely is code to be subject to critical defects. While not directly related to software security, critical defects can cause the application to misbehave, crash, or perform poorly. Similarly to the Security indicator, the Stability indicator is calculated using a mix of static code analysis and assessment of the libraries in use.

When you integrate the Meterian Continuous Security platform in your application, it is a good idea to display the two badges in your project page (or in the README file if you use one of the popular platforms like Github), to immediately have a clear indicator of the health status of your codebase. Of course it is also possible to display a full report of all the issues detected by the latest security scan – that will be the topic of the next blog post.

Security and Stability

A starting point

The other significant point is that technology, like the evolution of the life-forms that spawned it, is inherently an accelerating process.

Ray Kurzweil, “The age of spiritual machines”

Anybody involved in writing code, from the lone hobbyist developer to Fortune 500 companies, cannot miss the acceleration we are going through in software technologies.

While twenty years ago web developers were facing just a few choices in determining their favourite software stack, nowadays we have to decide among thousands of possible combinations of development languages, frameworks and databases – just to mention a few areas. And this acceleration doesn’t just stop at tools; we face new challenges in making our code run in multiple environments (and in the cloud), challenges like coping with traffic generated by 3+ billions of internet users, and challenges in keeping our data safe from malicious attacks.

When looking at the landscape from this angle, it is surprising companies are still able to cope with this accelerating complexity and still produce software that works, and serve hundred of millions of users. However that’s no small task, especially for small and medium companies: keeping always up to date with the latest security advisories, with the latest bug fixes and new software updates takes a lot of effort.

At this point the perfect first blog post should pull the proverbial rabbit out of a hat, and announce we have a solution. More humbly, at Meterian we can say we are embarking on a path to make all that easier; to make a platform that works together with developers in analysing the code and finding ways to improve it, to prevent bugs and, most importantly, security issues. We call it continuous security.

A starting point