Vulnerability Focus: Remote Code Execution (RCE) Attacks

This week’s edition is all about remote code execution attacks. We have a cross-site scripting (XSS) vulnerability in the ever popular http-file-server which could lead to the execution of arbitrary JavaScript code in an unsuspecting victim’s browser.  On the other hand, we have a RubyGem exposure whose sheer magnitude led to the discovery of a potential cryptocurrency mining scheme. 

  • CVE-2019-15224 A code-execution backdoor in rest-client version 1.6.13 could lead to privilege escalation attacks
  • CVE-2019-5458 A cross-site scripting (XSS) vulnerability in all versions of http-file-server, a third-party Node.JS module

CVE-2019-15224

Vulnerability Score: TBD  (CVSS v3.0)

Platform: Ruby

Component: rest-client

Affected versions: v1.6.10 through v1.6.13

A malicious code-execution backdoor has just been located in version 1.6.13 of rest-client – a popular HTTP and REST (REpresentational State Transfer) client software package for Ruby. In essence, REST is an architectural style that standardizes modes of communication among different computer systems on the web. To delve a bit deeper, RESTful systems are stateless, and they separate concerns from client-side and server-side – the Ruby rest-client oversees requests sent to the server in order to retrieve or modify data stored on the server. 

In this compromised  version, the injected code within the gem would fetch malicious code from pastebin.com and send it to the attacker’s server to retrieve sensitive information from the client’s host machine. Kudos to Jussi Kuljonen for catching this vulnerability and promptly notifying the GitHub community on 19 August 2019.  Aside from that, he also pointed out that rest-client version 1.6.10 leading up to version 1.6.13, which have since been yanked, were also compromised. 

This is an image of how a hacker exploits the Ruby gem rest-client library with remote code execution, in a web application.
Remote Code Execution Exploit of Ruby Gem rest-client library

This is dangerous territory for users of said gem, as third-party attackers could exploit this vulnerability to perform remote code execution for personal gains. This could be in the form of privilege escalation attacks, whereby attackers could execute malicious code on the host’s server to access credentials of services used by a hosting site (i.e. database, payment service provider).

It should be noted this 1.6.13  version is considerably dated, as the latest rest-client version is 2.1.0.rc1. This raised suspicions among the DevOps community that this incident might have been a targeted attack.

This discovery then instigated a wider instigation which revealed that the same code was found in almost a dozen other gems: bitcoin_vanity, blockchain_wallet, omniauth_amazon, cron_parser, coin_base,  lita_coin, awesome-bot, doge-coin, and capistrano-colors. It has been established that the attacker(s) wanted to exploit the infected hosts to covertly mine cryptocurrency. 

In terms of scope of impact, the rest-client  version 1.6.13, which sparked the uncovering of this malicious plot, has had 1061 downloads. On the other hand, the total download count for all the compromised gems is a little over 3500. Regardless, the chaos ceases here as all affected gems have been removed by the RubyGems team – the compromised accounts of developers have also been locked for good measure.

As for the availability of a fix, version 1.6.14 (identical to the unaffected  v1.6.9) has been released to replace all compromised versions in the legacy 1.6.x series. To check your apps’ depencies, versions <= 1.6.9 or >= 1.6.14 are unaffected. If your version of the rest-client gems falls in between, you are advised to download the patch immediately. Don’t say you haven’t been warned!

CVE-2019-5457, CVE-2019-5458

Vulnerability Score: Medium — 5.4  (CVSS v3.0)

Platform: Node.JS 

Components: http-file-server, min-http-server

Affected versions: All versions

Look alive, all you http-file-server and min-http-server users! A cross-site scripting (XSS) vulnerability has been found in these third-party Node.JS modules. The HTTP File Server (HFS) is a web server used for the publishing and sharing of files. 

By definition, XSS is a type of cybersecurity vulnerability that enables attackers to inject client-side scripts into web pages viewed by unsuspecting users. Implications of XSS vary in range (i.e. petty nuisance to  critical security risk), depending on the nature of the data stored on the vulnerable site’s server and the strength of the security mitigation measures adopted by the site’s network.

In this instance, this cross-site scripting (XSS) vulnerability is the attack vector – it enables hackers with access to the server-file system to inject malicious Javascript-based scripts in the file name, so that these scripts will be automatically executed on the victim’s browser when files are listed. In technical jargon, this is known as improper neutralization of input during web page generation. The occurrence of this XSS vulnerability is due to the unsanitized  and invalid HTML input in the module filenames – it allows any injected and stored scripts within the server to be executed in the client’s browser.

The http-file-server has unfortunately been declared dead, and no known fixes have been made available to HFS users. The good news is that the project has been yanked to prevent further exploits such as hijacking of user sessions or phishing to steal user credentials. Credits to An Nguyen for disclosing these easily exploitable vulnerabilities to the DevSecOps community!

To end things, we will leave you with some helpful tips on cross-site scripting prevention methods. One should check that user input has been sanitized and that potentially executable characters have been properly encoded to avoid having them interpreted as executable code. It is also worth validating input as it stops users from adding special characters into webpage data entry fields by refusing the request – this mitigates the impact should an attacker discover such an XSS vulnerability.  We suggest you bookmark this useful resource: Cross Site Scripting Prevention Cheat Sheet, too!  

Found this useful? Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: Remote Code Execution (RCE) Attacks

Vulnerability Focus: Java

Attention, fellow AppSec comrades! This blog post shines a spotlight on open source vulnerabilities in the Java universe. In particular, it has come to our awareness that the jackson-databind serialisation library, which parses Java objects to JSON and vice versa, has taken big hits over the past few weeks. To better enlighten our readers, we took an in-depth look into the origins of its (de)serialisation flaws.

  • CVE-2019-12384 A flaw in the serialisation process of FasterXML jackson-databind 2.x before 2.9.9.1  could lead to remote code execution. Read why
  • CVE-2019-14379 Hackers could exploit an invalid object-class for pre-2.9.9.2 versions of jackson-databind to gain remote access and control. Read why

CVE-2019-12384

Vulnerability Score: 5.9

Platform: Java

Component: jackson-databind 

Affected versions: FasterXML jackson-databind 2.x before 2.9.9.1 

Here is an interesting one! An open source vulnerability has been found in Jackson, more specifically in jackson-databind. Jackson is a widely-used Java-based library that supports serialization of Java Objects to JSON to enable objects to travel across a network.

A little befuddled? Think of two machines that speak entirely different mother tongues, and decisively pick up another shared language to enable seamless communication between each other. In this context, the act of translating the additional language stands in for the serialization process, whereby the translation process parses the mother tongue (Java Objects) of first machine (X) to a common language (JSON) that is also understood by the second machine (Y).

The root of this vulnerability is that jackson-databind, under certain conditions, blindly deserializes everything in its path. This then gives rise to exploitation opportunities for malicious third-party attackers to substitute valid object-classes with unvalidated ones. As a result, this then enables these hackers  to send specifically crafted JSON messages which could then lead to privilege escalation issues and arbitrary code execution  (ACE) attacks.

Although patches for this security flaw have been published for various softwares (RedHat, Debian 8 ‘Jessie’),  these solutions are not sustainable fix-alls. The existing solution for this vulnerability is essentially manually blacklisting invalid object-classes that can easily be exploited by third-party attackers. Nonetheless, unvalidated object-classes are popping up like hotcakes, and the maintainers of said blacklist are playing a risky game of whack-a-mole, and it is just too time-consuming to continuously add exploitable classes to a list.

Nonetheless, until a more comprehensive solution has been discovered to effectively combat against these loopholes, you had better perform an update on your jackson-databind library to ensure you are well-protected against the blacklisted attack vectors and such known vulnerabilities!

To find out more about jackson-databind exploits, click here.

CVE-2019-14379

Vulnerability Score: TBD

Component: jackson-databind

Affected versions:  2.x versions before  2.9.9.2 

Here’s another testament to the inefficiency of the blacklist measure to protect users of jackson-databind against arbitrary code execution attacks – another invalid object-class, the SubTypeValidator.java, has yet again appeared on our radar.

As explained under the aforementioned Jackson vulnerability that affected FasterXML jackson-databind versions 2.x (all versions up to 2.9.9), this data-binding library has the potential to deserialize any object-classes in its path under certain conditions. This is a result of default-typing which allows jackson-databind users to  deserialize object-classes without specifying the full possible type hierarchy. And herein the default-typing feature lies the flaw of this open source vulnerability.

In this context, where the security flaw affects the more recent version FasterXML jackson-databind 2.9.9.2, remote code execution could be triggered if a hacker inputs the unsanitized SubTypeValidator.java object-class under the default-typing mechanism, when it is used in conjunction with Ecache (Java’s most widely-used cache).

This could potentially result in security breaches  where hackers are able to send specific and malicious JSON messages resulting in unauthorised root access and control. We strongly advise that you upgrade to version 2.9.9.2 or higher at the soonest!

With jackson-databind being a highly popular serialisation gadget in the DevOps community, such exposures should be effectively nipped in the bud to prevent further compromises to its library, as well as waste of resources rolling out patched updates on every vulnerable version. A frequent user of jackson-databind? What are you waiting for?

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

Vulnerability Focus: Java

Vulnerability Focus: .NET

In the wake of the massive Capital One data breach incited by a misconfigured web app firewall, we are throwing in a .NET open source library vulnerability that demonstrates the pervasiveness of privilege escalation attacks across web apps for good measure.

CVE-2019-1010199

Vulnerability Score: Medium — 6.1 (CVSS v3.0)

Platform: .NET 

Component: ServiceStack 

Affected versions: 4.5.14

It is a perilous time for ServiceStack users, a widely-used .NET based library.
The problem lies with the ServiceStack ecosystem, where a JavaScript-based Cross-Site Scripting (XSS) vulnerability could allow attackers to inject client-side code or scripts into web browsers viewed by other users. This means that said script is activated when it is read by an unsuspecting user’s web browser or web application. The web page or application then acts as an attack vector that delivers the malicious script to the user’s browser.

A web page or application is made vulnerable to XSS if it executes unsanitized user input for web servers to generate output – this user input must then be parsed by the victim’s browser to potentially compromise the system. We will note that though XSS attacks are possible across many languages (e.g. VBScript, ActiveX, Flash, CSS), they are, however, most common in JavaScript (as with this vulnerability) as this language is most commonly used as a client-side scripting language to support a bulk of web browsing experiences. 

In the context of this vulnerability within ServiceStack Framework 4.5.14, the flawed component is the query code used to execute the GET request. And with the web browser’s lack of server-side validation serving as the attack vector, this means that browser encoding is bypassed which could then compromise unsuspecting users’ browsers upon opening a crafted URL. The resulting impact is that a potentially malicious JavaScript code (aka unsanitized user input) would be reflected in the server response during execution for web browser output generation.

Such cross-site scripting vulnerabilities are often used by attackers for privilege escalation issues, especially to bypass access controls when two web pages are of the same origin (i.e. two URLs sharing the same protocol, port (if specified), and host).

This unauthorised access could then lead to security breaches such as data theft and password dumping. It is thus imperative that affected frameworks immediately download the patched version in 5.2 or later to avoid sensitive data violations.

With JavaScript being a key programming language that supports web development, it is imperative that we keep our guard up against unwanted intrusions to ensure seamless and secure provision of web services. We certainly hope this detailed analysis of this .NET vulnerability has galvanized you into taking active measures to avoid systemic data breaches. Until next time!

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

Vulnerability Focus: .NET

Vulnerability Focus: Ruby

After traversing the National Vulnerability Database for compelling open source security flaws this past month, we have identified the Ruby gem strong_password version 0.0.7 and mini_magick version 4.9.4 to have extensively critical security issues. Read on and spread the word about them with your application security community!

Meterian focuses on critical Ruby vulnerabilities this month. .

CVE-2019-13354

CVE-2019-13354 Ruby strong_password gem 0.0.7 is untrustworthy.

Vulnerability Score: Critical — 9.8 (CVSS v3.0)

Platform: Ruby

Affected versions: strong_password gem 0.0.6

Amber alert! A major vulnerability was found in the RubyGems repository earlier this month – the strong_password gem 0.0.6 was  hijacked, and the compromised version 0.0.7 was found to contain a security flaw, in which a code-execution backdoor has been installed to potentially give third-party attackers the ability to trigger arbitrary code execution (ACE) over the network.

In lay man’s terms, this simply translates to a stealthy backdoor which provides third-party attackers with complete remote access of the server of the Ruby application for which this gem has been installed; opportunistic attackers are then able to send malicious code to the command-and-control servers of the compromised system to execute a range of functions including Denial of Service (DoS) and privilege escalation (e.g. data exfiltration, password dumping).

This open-source security risk was identified by Tute Costa – he was performing a due diligence scanning for anomalies in the library’s changeset of the 25 gems he had upgraded for his Rails app project after realising he could not locate a changelog.md (a file logging all descriptions of changes for each version of an updated gem – think how Microsoft Word or Google Drive saves changes of edits made to documents) for strong_password 0.0.6 gem before it made its upgrade to version 0.0.7. He could not find the code for the updated version 0.0.7 of the strong_password gem and this discrepancy prompted Costa to cross-compare contents of the gem within his  rails app with that of the latest copy in Github.

This was where he discovered the updated version 0.0.7 gem does not belong to the original owner of the strong-password gem, but rather a pseudo account. He then dived into the code and figured out that new tweaks to the updated code for version 0.0.7 creates a loop within a new thread which fetches and executes code stored in a pastebin.com, but with an empty exception handler that ignores any error it potentially raises – this gives attackers remote code-execution (RCE) control  of the system as it will be able to bypass any error registered.

This strong_password gem is an entropy-based password strength checking installation for Ruby and ActiveModel. The previous version (0.0.6) had 39,955 downloads, whereas the compromised version 0.0.7, published on 25th June, raked in a total of 537 installations within three days before it was eventually yanked down on 28th June. Had this security flaw gone undetected and had these gem users decide to perform a bundle update on their APIs, over 30,000 web applications, libraries, servers, and system utilities could have been exposed to open-source security risks.

CVE-2019-13574

CVE-2019-13574  Ruby mini_magick version 4.9.4 has backdoor access to unwanted app server crashers. 

Vulnerability Score: Critical — 7.8 High (CVSS v3.0)

Platform: Ruby

Affected versions: mini_magick version 4.9.4

My oh my. Ruby open source gems are not looking too hot for application security this month! Harsh Jaiswal discovered a remote shell execution vulnerability  in mini_magick – a Ruby library interface that acts as a buffer between the ImageMagick / GraphicsMagick programs and your Ruby code by providing you with the tools and resources to transform and customize images for Ruby applications that is exploitable when using MiniMagick::Image.open with specially crafted URLs originating from unsanitised user input.

Similar to the aforementioned case of the strong_password gem, the vulnerability within this mini_magick gem allows attackers to perform arbitrary code execution (ACE) on servers; it essentially opens the path to access the image in ib/mini_magick/image.rb in the pre-4.9.4 version of the mini_magick gem. The image.open input (aka path to image) is passed to Kernel.open, which functions to accept the ‘|’ (pipe) character followed by a command. This use of Kernel.open represents a serious security risk as the pipe (‘|’) is a character that allows chain commands in the Linux terminal, which means the result of a single command could have further-reaching consequences. Therefore, when installed on an application, this compromised mini_magick version could open the door to  highly risky remote code execution on the hosting server.

This flawed version was downloaded over a million times, suggesting a large potential scale of impact for C2 backdoor attacks. Although a patch has been applied to version 4.9.4 of mini_magick, we believe the expansive list of gems using this flawed version means many developers and organisations might not be aware they have installed mini_magick due to the nature and ubiquity of open source work. Even if these gems do not necessarily use mini_magick in a way that exposes the program to the vulnerability, it is still well-advised to install the updated version of mini_magick 4.9.4 without the erroneous code

So there you have it! Go right on ahead to perform an update to secure your applications and software programs if they use these Ruby gems – you know it would give you peace of mind!

Alas, these 2 identified vulnerabilities are just two needles in a haystack; open source code can typically make up to 90% of most software programs, and this resulting pervasiveness of open source vulnerabilities means new security flaws are popping up like hotcakes. To better equip for your combat against exploitation by third-party attacks, it would be prudent to conscientiously scan for vulnerabilities in your software.

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: Ruby

Meterian “Life and Hacks of Open Source” Prize Draw

Following yesterday’s event at IDEALondon over in Shoreditch, London, we’re pleased to announce the launch of our new website scanner and prize draw.

Draw Period: July 10 – July 17, 2019

Prize: A bundle consisting of £100 Amazon.co.uk eGift Voucher, a 1-hour in-person consultation with Meterian, 10% lifetime discount to Meterian cloud-based annual subscription product from Startup, Bootstrap, and Enterprise plans.

Eligibility Criteria: Prize Draw entrants must register their email and contact information on Meterian’s website at https://www.meterian.io/webscanner.html during the Draw Period. Only 1 winner will be selected.

Read on for detailed terms.  Happy scanning!

Meterian “Life and Hacks of Open Source” Prize Draw Terms

  1. We shall specify the opening and closing dates of each prize draw (“Draw Period”).  
  2. There will be one winner per Draw Period who will win a prize for registering on Meterian’s website at https://www.meterian.io/webscanner.html during the Draw Period. We reserve the right to reclaim any prize where a participant makes false claims to identity and affiliation with the company they register on the website.
  3. The prize is a bundle consisting of £100 Amazon.co.uk eGift Voucher, a 1-hour in-person consultation with Meterian, 10% lifetime discount to Meterian’s cloud-based annual subscription product from Startup, Bootstrap, and Enterprise plans.
  4. Prizes will be awarded to entries picked at random by computer or an independent person within 7 working days after the closing date. Each winner will be contacted by telephone, post or email within 21 days of the Prize Draw closing, and be sent their prize by post no later than 90 days after the Prize Draw Date. If a winner for a Prize Draw cannot be contacted using reasonable efforts within 10 days from the Prize Draw date for that Draw Period, then an alternative winner will be drawn from the entries for that Draw Period.
  5. There is no cash alternative to the prize. We reserve the right to award an alternative prize of equal or greater value, should the advertised prize or any part of it become unavailable. The result of the Prize Draw is final. No correspondence will be entered into. The name and county of each winner will be available on request by sending a stamp addressed envelope to Customer Service, Meterian Ltd., 196 Freston Road, London W10 6TT, United Kingdom and may be posted online.
  6. Each winner may be required to participate in reasonable press or PR activity related to the prize draw as notified by Meterian Ltd.  
  7. We reserve the right to cancel or amend the prize draw or these rules at any time without prior notice, with no liability to any entrants.
  8. We can accept no responsibility for entries which fail to be properly submitted for any technical reason whatsoever, and we will reject entries submitted by any other means.
  9. Additional terms:
    1. Each winner must be a UK resident.
    2. The prizes are as stated, not redeemable for cash or other products and are not transferable. Each prize can only be claimed by the winner.
    3. If the prize package is not claimed by 90 days after the prize draw, the prize will be forfeited.
    4. We endeavour to run the competition as stipulated, including the closing date of 11:59pm on last date of Draw Period.
    5. The winners will be communicated via the email used to submit their entry shortly after the completion closing date.
    6. Acceptance of these terms and conditions is a condition of entry and the entry instructions form part of these terms and conditions. By entering into the competition, you agree to be bound by these terms and conditions.
    7. The Promoter (Meterian) reserves the right, at its sole discretion, to exclude you from the competition if you do not comply with these terms and conditions.
    8. Internet or Wi-Fi access is required.
    9. If unable to physically attend the consultation, then the consultation will be conducted via Skype and will only be 1 hour long.
    10. No purchase necessary.
    11. The Promoter’s decision will be final and binding and no correspondence will be entered into.
    12. The Promoter reserves the right to change, alter or withdraw the competition at any time.
    13. This Competition is in no way sponsored, endorsed or administered by, or associated with, Twitter, Facebook, Instagram, LinkedIn or any UK registered charity.
  10. If any of these terms and conditions are found to be void or unenforceable, that term shall be deemed to be deleted and the remaining terms and conditions shall continue in full force and effect.
  11. These terms and conditions shall be governed and construed in accordance with the laws of England and Wales. Any dispute arising is subject to the non-exclusive jurisdiction of the courts of England and Wales.
Meterian “Life and Hacks of Open Source” Prize Draw

What do we mean by “stability”?

When you open one of our reports you will see three different sections. At the top you will find our security section, that will tell you whether any of your components is potentially exposing your system to hacking due to known vulnerabilities. At the bottom, you will find our licensing section, that will tell you if any of your components are using a non-business friendly license. But what about the middle section, stability?

This is a concept which we’ve been working on for a while, and now it’s in its early stages. At the moment, in regards to a component, it’s basically an indication of how up to date it is. The stability report will provide you also with an upgrade path to any component your software is directly using, giving you the knowledge to move forward to the next version if you choose to. But is this advisable? Well, in general, yes, mainly because a new version usually includes bug fixes for issues you are not even aware of, performance enhancements and, of course, vulnerability fixes.

But should you always upgrade? And to the latest version? Well, the decision to upgrade has to be evaluated by the development team. For platforms using semantic versioning (the mast majority on the planet these days), it’s usually considered safe to upgrade in certain conditions, but let’s pause for a moment to understand how this works.

A semantic version number is usually in the format MAJOR.MINOR.PATCH and each part can be independently incremented against the previous when:

  • MAJOR: an incompatible API change has been implemented
  • MINOR: a new functionality has been implemented but it’s backwards compatible
  • PATCH: backward compatible bug fixes have been implemented

So for example version 2.5.3 means major 2, minor 5, patch 3. Following on the previous explanation. 2.5.4 is a patch release, 2.6.1 is a minor release and 3.0.0 is a major release.

We need to appreciate that these are all conventions, and may be overlooked sometimes! Some platforms have a more “creative” ways to think about minor releases, and that’s the reason we usually suggest that only a patch upgrade is safe. Even in that situation, you should always have your test automation, CI, and QA team to validate your release.

Is that all for stability? Well, for the time being, yes, but please stay tuned as we do have something else cooking in the area!

 

What do we mean by “stability”?

How the wrong license can harm your business

legaldoc

 

Friendly disclaimer.

First and foremost, let me immediately start saying that this article is not legal advice, but it’s my attempt to explain in a simple way the problems connected to software licensing: in case of emergency, call a lawyer 🙂

The problem.

Many people think that because you can download a piece of software without paying a fee it means that such software is free. But if something is freely available, it does not mean that the same thing is free to use. Some development teams have the expectation that, when including a software component in their own customised system, it simply becomes “part of it” inheriting their licensing model: this is simply not true.

Imagine, for example, that you are building a new revolutionary car, all electric, and self-driving! You will need a lot of software to make that happen, and certainly, you do not want to code everything from scratch. So you start first assembling some basic components, an operating system (Linux), some basic tools (BusyBox), some software from other vendors and then you finally write your magic code. Sounds familiar? Anybody said “Tesla” in the audience? And what happens when a competitor discovers that you are using open source software with a certain license (GPL) and asks you to provide them with your code, the valuable code you wrote… well, they can lawfully do so and you will have to comply! And so that’s what happened, and forced Tesla to start releasing its software on public repositories. But please, without leaving the car making business, see also BMW who handed over its i3 car code to a random guy, who immediately published it on GitHub.

The restrictions.

It’s important to understand the restrictions you face when you decide to use an opensource component. Even one single component with the wrong license can impose a restriction on all your source code.

  1. you may be forced to release your code under the same license. If you use a component licensed for example under GPL or AGPL (or even LGPL in case of derivative work), all your software will have to be released with the same license.
  2. you may be forced to release to the public your source code. If you use a component licensed for example under MPL or GPL, you will have to provide all your code in a human-readable format upon request (distribution of obfuscated code is not compliant).
  3. you may not be allowed to distribute your software commercially. Licenses like the Oracle BCLA will prevent that, and you can easily be sued (and you will most certainly lose).

But wait, what about the code that does not have any license? For sure I can use it without problems, right? And the answer is again a resounding no! Under current law, copyright extends for the life of the author plus 70 years (and sometimes 120 years after its creation), and the creator (or his/her dynasty) can simply sue you for using it. Unless a piece of code includes a license, do not use it.

The risks.

If you decide to not comply with a license, or you are simply unaware of the problem (this would be the most common case) you face two main risks.

First, you are in actual violation of contractual obligations. This can lead to a long case in court that, if you are lucky, you settle outside court, with money transferred. There are a lot of examples of that, with payments that go up to $100K (please see an incomplete list here), so I really think you should not discount this risk, also because in some cases, firms preferred to file for bankruptcy in order to avoid bigger losses.

Second, you may be in violation of statutory law, a corporate liability that may become also a personal liability. Corporate Criminal Responsibility derived from copyright crimes can also be extended to labour law, in case it can be demonstrated that the responsible was not carrying out his duties properly.

Solutions.

First and foremost you need to be aware of the problem. If you read this article until this point, you now probably are, so we can safely assume you are onboard with this point.

Now, assuming your company is building software, you need to make sure that all components your development team is using, and end up being part of the final product, are accounted for in terms of licensing. Remember: one single component in your chain can influence the whole system.

You will need then to create policies to allow/disallow certain licenses to be used and enforce them across your development teams. The best solution would be an automated one, which automatically detects violations and blocks unwanted releases.

Meterian to the rescue!

Meterian, among others, provides an elegant mitigation for this problem, which is also affordable and efficient. By placing Meterian in your development pipeline you can have continuous reporting about the licenses used by your software so that you can make sure you are not exposed to the risks explained before. Please have a look at one of our reports.

When Meterian is included in your development pipeline, policies can also be enforced so that the presence of certain licenses will stop the build to progress further, preventing the product to be shipped to the final customers.

Make sure to get in touch if you want to learn more!

How the wrong license can harm your business