The problem with opensource components

Last updated: 07/07/2021

While opensource components are basically indispensable in modern software development, they also must be handled with care. In this post, I will explain in the simplest possible way the problem with opensource components: I am going to use a metaphor that seems to resonate well with our customers, which however may not be necessarily accurate from an engineering point of view.

Building a house.

When you build a house a lot of work has to be done, starting from the planning all down to the actual building of the foundation, infrastructure, walls, ceilings, and roof. This work is different for every house and very specific so that it’s necessary to have a very solid process to make sure the standards of quality are high enough from a variety of point of views. There’s an enormous amount of attention on every aspect and it’s always supported by a strict set of practices and processes.

Now, when you build a house, there are a lot of things you do not necessarily want to create from scratch: items like windows and doors, for example, are components readily available on the market in a variety of shapes and sizes. You do not need to build them from scratch: that would require specific craftsmen and a sizeable amount of time. You simply shop for those components, find the right ones and integrate them into your house.

As we are a security company, let’s focus on security for a moment. Your team built the walls and the infrastructure, right? With a very strict process that guarantees you that everything is solid, unbreakable and durable. But what about windows and doors? You bought those components off the shelf: what do you know about their quality? Are the locks durable? Are the glasses really break proof or are they affected by some design flaw? How much of your house did you have to buy from other manufacturers? And how long ago was it? What’s the warranty, and did you stay warm this winter or were the windows drafty?

This is the problem with opensource components.

Building a software application.

In a modern development process, your development team is “building the house”: writing the code that contains the business logic of your application. They also need a lot of other code to do various ordinary tasks, like talking to a database, exposing an API, talking to other services, exchanging data using a machine-readable format like JSON or XML. The opensource community has already available off the shelf components you simply incorporate in the project, saving huge amounts of money and dramatically shortening the time to market: those are the “windows” and “doors”. Worse than in a building, however, off the shelf software components can be up to the 80% of the code shipped to production, making them a very critical asset to keep under control.

What we are finding when we meet potential customers is that they have a very strict process with regards to their code, often supported by a variety of tools in order to make sure that the business logic code is solid and secure. The same attention, however, is not extended to the opensource components used, which are simply bundled with the code shipped to production.

The opensource components are like the “doors” and the “windows” of your “house”: are they secure? In 2019, on average 40 new vulnerabilities were discovered daily in external components and in 2021 nearly 60 new ones are discovered.  Moreover, new versions of these components are often released monthly. It’s critical to keep the components used in your applications up to date and replace them immediately, to avoid a disastrous data breach like what happened to Equifax1, that simply did not update a vulnerable software component, Apache Struts.

The Equifax hack showed just how dangerous failure to maintain your open source components’ security can be. Back in 2017 Senator Marco Rubio noted the importance2 of protecting against similar instances in the future, requesting that the Exchange Commission should make companies release prompt disclosures of hacks that could affect consumers. More recently, President Joe Biden has officiated these concerns with The Executive Order on CyberSecurity3. The order mandates that there is a software bill of materials (SBoM) for all software sold to the US government, entailing information on what the end product contains and what third party code goes into the software— “accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes”.  Continuous audits and enforcement of these controls are also required.Furthermore, the bill ensures information sharing between companies that will mean the government is notified about cyber breaches that could impact their networks, to increase transparency and learn from past incidents. The recognition of issues such as these by government bodies brings us one step closer to safer open source component use. For more on Biden’s Executive order read our blog post on the role of cyber security in sustainability.


(source: vulndb)

Do you know how much of your base is opensource? Do you know when you updated it last? And do you know every noteworthy detail of the updates from those external components?

What can you do?

Our software, Meterian, does exactly that job. It will continuously check the opensource components used by your business logic so that you will not have any nasty surprises because of them. It takes 5 minutes to set it up in your process, and you can also simply run it on your codebase with no installation at all. You do not need to be a developer to run it and it produces also a clear report that is understandable and actionable right away.

We strongly encourage you to give it a try, or maybe just have a look at our reports for some common libraries like Alibaba/FastJson or Netflix/Zuul, both scoring a resounding 0 in security at the time of writing.

Keep your house safe, keep all external components under control.

Get an instant analysis of your first codebase for free.  See the risks immediately and know which components to remove or upgrade to secure your app. Sign up here to download the Meterian client today.

1 Newman, Lily Hay. “Equifax Officially Has No Excuse”. Wired, 14 September 2017, https ://

2 Powers, Scott. “Marco Rubio after Equifax hack: companies should be reporting quickly”. Florida Politics, 4 October 2017, https ://

3 “Executive Order on Improving the Nation’s Cybersecurity”. The White House, 12 May 2021, https ://

The problem with opensource components

Meet Meterian at the next Gerrit summit


Meterian is happy to announce that it will be presenting at the next Gerrit summit in Paolo Alto, California, an innovative Jenkins based solution to ship software without vulnerabilities using Gerrit Code Review and Robot Comments.

What if fixing vulnerable components was something that can be completely automated? And what if it could fit nicely in the amazing review process used by Gerrit, leaving to the humans just the burden of the last click?

Well, we think that with Robot Comments now this is possible! Join us on Friday in the Cloudera Galactic HQ and see how!

Meet Meterian at the next Gerrit summit

New vulnerabilities in jackson-databind

The jackson-databind saga continues and today 4 new vulnerabilities have made their way into the NVD database. Still not “officially” confirmed, they are there to stay, as you can probably guess looking at the project bug report:

  • CVE-2018-14718: remote code execution via slf4j-ext
  • CVE-2018-14719: remote code execution via blaze-ds-opt
  • CVE-2018-14720: exfiltration/XXE with only JDK classes (some JDK versions)
  • CVE-2018-14721: exfiltration/SSRF with axis2-jaxws

Things are becoming quite tricky as the project is trying to keep up with four different main codebases (2.6.x, 2.7.x, 2.8.x, 2.9.x) plus the new development in progress. This is all about the ability to use the deserialisation mechanism of Jackson in order to perform mischiefs using, in a very creative way, some standard classes (see an example exploit documented a while ago on my personal blog) and all due to a blacklisting mechanism that continues to require updates.

You can also read a full account of the problem here, but for the time being, I would suggest using Gson instead, at least until a 3.x version of Jackson is out.

New vulnerabilities in jackson-databind

Meterian is part of Cylon cohort 8!

We are excited to announce that CyLon, a London based cybersecurity accelerator, and seed investment programme, selected Meterian as part of cohort 8! CyLon has already successfully accelerated 59 companies across hubs in London and Singapore since its launch in April 2015 and has a portfolio of international companies now valued at more than £200m.

We will be part of a selected group of startups covering a mix of security areas. We are joining CyLon for three months and we will receive an intensive programme of training and workshops delivered by industry specialists and experienced entrepreneurs, all in associations with CyLon’s unrivaled network of investors, buyers, and mentors across EMEA and the US.

On top of that, we will also have access to a fully-furnished office space, and for the next three months, we are looking forward to meeting you here at CyLon: please do not hesitate to book a meeting, we will be happy to share a proper coffee together!



Meterian is part of Cylon cohort 8!

SAST, DAST, RASP, IAST explained

If you are working in application security you certainly heard one or more of these terms, but what’s the real meaning behind the acronym? In this article, I will try to clarify this tongue twister list.

SAST: Static Application Security Testing

This family groups all the technologies dedicate to test the security of code at rest and will try to detect possible security issues, based on some strategies or policies.

This category can be further divided into three others:

  • SCA – Static Code Analyzers
    They scan the code, in source or binary format, looking for patterns that can lead to security issues, they can also enforce guidelines and policies. There’s a lot of choice of tools in this area, but I think you should always include Error Prone, praised by Doug Lea.
  • SDA – Static Dependency Analyzers (also known as SCAN)
    They scan the external component pulled along your code build looking for known vulnerabilities that can potentially expose the code to exploits later. It’s worth mentioning here that on average 80% of the code you ship it’s not your code but is somebody else’s code! Meterian, our host here, is, in fact, a SAST/SDA tool.
  • SIS – Sensitive Information Scanners
    They scan the repositories where the code is stored in search of sensitive information inadvertently stored in them that can subsequently be leaked. It might sound a trivial thing to check, but it’s just good security hygiene to have one of such scanners in place. The effective to use greatly depend on your SDLC process, but I would strongly suggest using one of them, such as for example GitLeaks.

DAST: Dynamic Application Security Testing

This family groups tools used to test an application in an operating state (but not in production) using automated black box testing. They also frequently include specific security tests where the system tries to feed the application with malign data to simulate common patterns of attack. They interact with exposed interfaces such as APIs, network protocols, web pages. One opensource incarnation of such system is the Ebay DAST Proxy, released to the opensource community in late 2016.

RASP: Run-time Application Self-Protection

This is a very interesting category of tools where an agent is embedded into the application so that it protects the system at runtime and it’s typically deployed directly in production. The most common scenario sees the RASP agent “melted” with the application code through code instrumentation so that it can directly analyze the application behavior, providing active protection. A RASP, after detecting and blocking the attack, can shut down a user session, stop executing the application, and sometimes it also offers the ability to deploy code fixes at runtime. It also provides detailed reports that can be fed to monitoring systems. Baidu, the Chinese multinational technology company specializing in Internet-related services and product, is actively maintaining OpenRASP, an opensource RASP solution that works on Java and PHP web platforms.

IAST: Interactive Application Security Testing

These family of tools usually combine the RASP and DAST approaches: when testing an agent is embedded in the application while the test system executes attacks. This is a fully automated process so that it can be embedded in a continuous delivery system and ensure that a certain level of checking is done at frequently, even at every release, and with no human intervention.


What shall we do? As repeated endlessly again and again in the literature, you will need a complete approach to security testing, so considering using any of these tools is a step in the right direction. As we saw, there’re also opensource solutions available, so we do not really have any excuse to avoid putting this together.




SAST, DAST, RASP, IAST explained

JavaScript support in Meterian.

JavaScript client libraries, used on websites.

As you know there’s a number of JavaScript libraries used on the web in HTML pages: they are there to make your website more attractive, making it capable to interact with server-side APIs in a seamless way. But how many of them are vulnerable?

The most recent research paper on the subject, titled “Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web” (downloadable here) provides a very scary view on the current state of the website you frequently visit: more than a third of them  may include a JavaScript library that’s vulnerable to one or more security flaws. To be precise, 37% of the scanned websites use at least one vulnerable library, 10% use two or more vulnerable libraries, and many websites still use libraries no longer maintained.

If you are using libraries like JQuery, Handlebars, AngularJS and in general any popular client library, you can potentially be exposed to a vulnerability


JavaScript NodeJS libraries, used on servers.

The same issue is, of course, present on the server side, with a constantly increasing number of vulnerabilities detected in such packages.  NodeJS is an excellent engine to run JavaScript but your server-side application may end up using hundreds of libraries (remember, each dependency has its own dependencies, recursively) and in any of them you can find a vulnerability.

Meterian uses a variety of reliable sources in order to ensure your server does not end up embedding a vulnerable NodeJS library, and it aggregates the contents of several databases in order to be sure to have the maximum coverage. With an average of 10 new vulnerabilities published every month you certainly need to keep a close eye on your NodeJS projects


We are here to help.

Meterian will help you to detect the offending components that need to be upgraded, providing a clear feedback of what are the reasons why you need to do so. We strongly advise you to download our client and check your project, today! But remember, one single scan will not solve your problem: make sure you add it to your pipeline so that you can avoid the risk of shipping vulnerable software.



JavaScript support in Meterian.

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?


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


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 for more details.


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