Author: bbossola

Meterian now supports pnpm!

bbossola, Leave a comment

Hello fellow developers!

We are happy to report that now Meterian supports pnpm, a new fast and more efficient alternative to npm. It’s comparably faster, especially when installing packages, compared to npm and it also saves a lot of disk space as it used symlinks to represent modules. Pnpm also supports very well monorepos using workspaces, and it has built-in support for multiple packages in a repository.

Pnpm support is available out of the box now in GitHub Actions, Azure DevOps, Bitbucket Pipes and of course using either the thin CLI or the dockerized CLI, so that you can continue to be informed about any vulnerable, out of date, or non-business friendly node module in your dependencies.

Remember: Meterian is free for open source!

Meterian now supports pnpm!

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

bbossola, , Leave a comment

Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.

CVE-2022-22963

Vulnerability Score: 9.5 (CVSS: 3.0 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework.cloud:spring-cloud-function-core, org.springframework.cloud:spring-cloud-function-context
Affected versions: 3.1.6, 3.2.2 and older unsupported versions
Fixed in version: 3.1.7, 3.2.3

CVE-2022-22965

Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework:spring-beans
Affected versions: all versions before 5.2.20, all versions before 5.3.18 
Fixed in version: 5.2.20, 5.3.18

Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgrade spring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).

Which systems does these affect?

CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.

CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:

  • JDK 9 or higher is used as the runtime environment
  • Apache Tomcat is used as the Servlet container
  • The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
  • There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled

Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.


Why do these threats demand an urgent patch?

Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

CVE-2022-22963:

$ mvn dependency:tree | grep spring-cloud-function | grep compile
[INFO] +- org.springframework.cloud:spring-cloud-function-core:jar:3.1.2:compile

If you see any response lines, check the version: if it’s below 3.1.7 (as in the above example) or, if using 3.2.x, below 3.2.3, you may be affected.

CVE-2022-22965:

$ mvn dependency:tree | grep spring-beans | grep compile
[INFO] +- org.springframework:spring-beans:jar:5.3.11:compile

If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.


My system has the vulnerable spring cloud function library — how can I mitigate the risk?

There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.

CVE-2022-22963:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-function-core</artifactId>
        <version>3.1.7</version>
    </dependency>

Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.

CVE-2022-22965:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>5.3.18</version>
    </dependency>

Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 

  • To do a scan from the command line using the Meterian CLI scanner
  • To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.


Are Meterian applications affected by the spring vulnerability?

We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.   

Related references

CVE-2022-22963

CVE-2022-22965

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

Is it a good idea to have vulnerable opensource components in my application?

bbossola, , , Leave a comment

This may seem to be a trivial question or something more like a joke. Why would one keep a vulnerable component in his tech stack? That said, from time to time, we meet people who simply answer “well, this is not an issue”.

Surprisingly, some are part of the technology leadership, or even the security chapter. Often their answer is usually along the lines of: “Well, you should know there’s a difference between vulnerable and exploitable: the fact that a component is vulnerable does not automatically mean that it’s possible to exploit it”.

“There’s a difference between vulnerable and exploitable…”

Yes, that is perfectly correct. We know it, as we do our own analysis as part of our routine.

Do you know what the problem is? You are probably not involved in the project and you are not a developer. I can bet that you are not continuously monitoring and assessing the code that your developers are daily pushing. Are you? Because at the speed innovation is going these days, there’s no guarantee that even tomorrow one of your developers will push a line of code that will enable the exploit. Yes, these exploits may be quite complex but also may be very easy to enable. It’s possible that an application including a vulnerable component is not exploitable today, but what about tomorrow? Your software is changing continuously.

“…but developers push new code daily, software is changing continuously.”

Do you know why Struts in Equifax was hacked? Because of a log message. A simple log message that echoes the content of a header, only that such content contained OGNL code, crafted by an attacker.

Do you know how jackson-databind remote code execution can be exploited? It’s just one configuration property away: enable polymorphic JSON deserialization and you are on.An apparently innocuous JSON message can feed now code to your server to be remotely executed.

So, in your position, I would not sit too complacent on the fact that you have vulnerable components that today cannot be exploited because of the current application code. That code changes continuously, daily, and unless you have in place an incredibly strict validation process, you are at risk, and you are putting your customers at risk. I do not believe such risk is acceptable.

“Most of the times the fix is just one patch away.”

Furthermore, most of the time fixes are just a patch away. We are not talking about a four-week refactoring session, but probably more like a one minute change and a run of the normal test regression suites, And if you had a system in place to continuously check your components against known vulnerabilities, you would have caught such an issue and patched it a while ago.

This is not a commercial plug for Meterian. Yes. this is our bread and butter, and we think we provide tons of value for the money. But some of our competitors do that as well. Maybe you are already using one of them in your company, and that’s great. Plug that in and set your customers free from this risk.

Nobody likes to be hacked.

Is it a good idea to have vulnerable opensource components in my application?

The new social network from Trump may violate the AGPL license.

bbossola, , , Leave a comment

It looks that everybody can misread a license, even a former President of the United States. The Software Freedom Conservancy (SFC) concluded that Trump’s new social network, “Truth Social”, violates the terms of the AGPL license. It looks like the code of the system is simply a copy of Mastodon, an existing open-source social network licensed under the AGPLv3 license. That license is a (very infectious) copyleft license, it specifically states that every user is entitled to receive the complete source code of the system. “Truth Social” is not compliant on this aspect, and also violates the license calling their software “proprietary”.

“…an entire open-source platform was just copied with no regard to the license…”

This is a very common mistake: nowadays software is built by hundreds of open-source components and license compliance is a very complex task, you can read an explanation in this article. However, in this instance and based on the SFC analysis, an entire open-source licensed platform was just copied and reused, with no regard to the license.

So what are the options for Truth Social at this time? I believe they can: 

  • release the derived system under a compatible open-source license, most possibly the AGPLv3 itself, and make their code publicly available
  • obtain a license for commercial use from the Mastodon contributors, but I doubt this will be possible, also given Mastodon view on Gab, another right-wing social
  • rewrite everything from scratch and relaunch

Of course, they may also fight this in court, but having seen some of the evidence from Mastodon, I doubt this is going to be a successful choice. It will be interesting to follow how this will evolve.

*** UPDATE ***

The Gab team, threatened by legal action, decided to release the source code publicly!
https://uk.pcmag.com/social-media/137421/trumps-social-media-site-quietly-admits-its-based-on-mastodon

The new social network from Trump may violate the AGPL license.

Rust— the new language shaking up the open source programming world

bbossolaLeave a comment

Rust is a relatively “new” software language across all the available ones at this time and rising in popularity among developers. Having been voted ‘most loved’ language for the past five years1, it is no wonder that Rust is gaining more attention. Read on to hear why we think Rust is worth your time.

Why a developer should consider Rust

Rust is a system language, along the lines of C and C++, but at the same times it incorporates many of the features of higher level languages, such as:

  • A reliable memory management (without a garbage collector)
  • An extremely low overhead
  • The use of static typing
  • A build design that prioritises performance (at the level of C and C++)
  • The use of a modern package management ecosystem

Remember Go? Rust will almost be faster than Go in run-time benchmarks because it has superior fine-grained control over how concurrency works in terms of threads and shared resources2. 

Additionally, Rust is being considered for use in the Linux Kernel3 by Linus himself, which is no small feat. Rust also supports WebAssembly4, just in case you fancy writing some web stuff 🙂

Rust has also become the ideal candidate for  IoT application development. Labeled as fast, reliable, and secure by Smart Device Management organisation Dwello5 who switched to Rust for their IoT platform. As they build IoT applications, developers have many programming languages to choose from. Some popular options are Java, C, JavaScript and Python. C and C++ are especially popular for device-run code. Another, less popular, option today is Rust, but that is likely to change. Let’s start with the characteristics of any programming language that makes it a good candidate for IoT development.

Application performance is a top priority, especially for code running on devices with minimal CPU and memory resources.  Developers can develop highly performant applications with C and C++, but at a cost. C and C++ developers know all too well the risks and challenges of dealing with bugs related to memory management such as unhandled null pointers and failing to deallocate unused memory.

Another component of a good IoT development language is developer productivity. Productivity is often a byproduct of skills, tools, and programming language abstractions and patterns. Popular programming languages are well supported by development environments. Additionally, developers acquire build tools and skills with time and experience; as a result, language abstractions and patterns are a key consideration with regards to developer productivity.

For those looking for both application performance and developer productivity, Rust is an increasingly popular option. The IoT market size is expected to grow from $250.72 billion in 2019 to $1,463.19 billion by 20276. Clearly, this is an area of the tech world that is only set to expand in influence. Meterian prioritises remaining at the forefront of innovation and supporting languages that have a vital role in ever advancing tech trends.

Why Meterian has decided to add Rust to its supported languages

First of all, Rust is big in open source, so it’s a natural continuation in our mission to support open source. Although security is extremely important in the Rust philosophy, there are vulnerable packages appearing in the wild. The GitHub advisory database7 does not have an entry for Rust (although some advisories do surface here and there) and the NVD database contains only a portion of all the vulnerable Rust components. Meterian is ingesting not only the NVD and other official security Rust databases, but it’s also actively monitoring many Rust open source projects at their source. Our ongoing efforts for getting the optimal coverage of all known vulnerabilities for open source dependencies extends our mission to Rust developers so we can maximise preventative care for Rust coding projects. 

Rust is important to pay attention to because on average every single rust open source project we scanned contains at least 1 vulnerable component that often could be patched.

Sizing up the risks in the Rust ecosystem

Screenshot from: https://www.rust-lang.org/

Rust, like all other modern languages, has an ecosystem of components, called “crates”, that are available from the open source community, which is accessible at crates.io. Although as a Rust developer you will always prefer writing some code from scratch (at the end of the day, this is a system language), it’s highly likely you won’t be reinventing the wheel. As shown on the screenshot from May 6th, over 60,000 crates with over 6.8 billion downloads, this is a significant size.

There’s a good chance that, if you never checked, you have been using a crate affected by a publicly disclosed vulnerability. Unless you are in application security and unless you spend half of your time reading bulletin boards, advisories, mailing lists, you won’t know about it. However, hackers do. They keep an eye on these vulnerabilities and routinely develop automated attacks to exploit them. In fact, hackers have it nailed to a T. The vulnerabilities are made public on open source vulnerability databases, the code is open source, they already have a botnet to run them (maybe even your Amazon Alexa or Google Play). All of a sudden, your shiny new service written with the latest cutting edge technology is vulnerable, and it can be used to exfiltrate confidential user data from your backend!

Let’s assume, for example, that you are using hyper, an HTTP library:

Screenshot taken from: https://www.rust-lang.org/

Since hyper is a relatively low-level library, it’s meant to be a building block for other libraries and applications. It may be a transitive dependency, a crate that is pulled in your code as the result  of another crate that is used. In particular version 0.12.34 of hyper has an interesting vulnerability: it allows an attacker to remotely execute code on the machine where your code is running. Check out this Common Vulnerabilities and Exposures ID CVE-2020-35863 for more details.  This security vulnerability would allow the attacker, for example, to install a very simple bot on your server, open an undetected tunnel and start pulling data from your proprietary system.

This is the beauty of a tool that detects the problem automatically and informs you promptly. We prioritise your time so that you can focus on the solution to remediate the issue, maximising productivity whilst maintaining high standards of open source security. 

What can Meterian do for you?

Sign up for a free account to see how our invisible security platform can work seamlessly in your software development life cycle (SDLC) and auto-remediate vulnerable components.

1 https: //insights.stackoverflow.com/survey/2020#overview

2 Howarth, Jesse. “Why Discord is switching from Go to Rust”. Discord, 4 Feb 2020, https: //blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

3 Salter, Jim. “Linus Torvalds weighs in on Rust language in the Linux kernel”. Arstechnica, 25 March 2021, https: //arstechnica.com/gadgets/2021/03/linus-torvalds-weighs-in-on-rust-language-in-the-linux-kernel/

4 “Why Rust?”, https: //www.rust-lang.org/what/wasm

5 Hiner, Jeff. “We Rewrote Our IoT Platform in Rust and Got Away With It”. Medium, 31 July 2019, https: //medium.com/dwelo-r-d/we-rewrote-our-iot-platform-in-rust-and-got-away-with-it-2c8867c61b67

6 Fortune Business Insights, https: //www.globenewswire.com/en/news-release/2021/04/08/2206579/0/en/Global-IoT-Market-to-be-Worth-USD-1-463-19-Billion-by-2027-at-24-9-CAGR-Demand-for-Real-time-Insights-to-Spur-Growth-says-Fortune-Business-Insights.html

7 https: //github.com/advisories

Rust— the new language shaking up the open source programming world

Easyjet hacked, 9 million customer records compromised.

bbossola1 Comment

Easyjet today admitted it was hacked by a “highly sophisticated cyber-attack”. 9 million customer records were compromised, where email addresses and travel details had been stolen. Also 2,208 customers credit card details were stolen.

“Are we surprised? Honestly, we are not.”

Are we surprised? Honestly, we are not. A quick surface scan of the Easyjet website reveals that it is using at least two out of date and vulnerable components: jquery 1.11.2 and angularjs 1.4

jQuery is a popular package used to simplify manipulation of HTML via Javascript. Version 1.11.2 of the package was popular in 2014, when the Ebola pandemic started. Yes, the previous pandemic, not this one. Still, for some reason, somebody thought it was a good idea to keep using it in 2020. But hey, what if I like legacy? Well, there are a few problems related to such library version, but among all of them, I think the most relevant one is CVE-2015-9251. This vulnerability allows an attacker to cause the execution of arbitrary code using a cross-site scripting (XSS) attack.

Angularjs is another popular web framework used to simplify web development. Version 1.4 of this framework was mainstream in 2015, when we had a nuclear deal with Iran and Barack Obama was at the White House. Sweet. But even if we do really miss those times, you do not necessarily want to use such version of angular because of multiple XSS, DOS and security bypass issues that can easily exploited.

“We can see what’s on the frontend.
But what is the situation in the backend systems?”

Do we think that any of those two components can be the culprit of this hack? Well, we do not know. But remember: a system like the EasyJet.com is always composed of a frontend (the website itself) and a backend system, which contains the real business logic of the services (and usually your data).

So, if in the fronted we can see components outdated and vulnerable, what do we think the situation could be on the backend? Well, actually, we think it could be worse. As the frontend is usually easy to change and in fact changes frequently (think about new offers or new branding) the backend is usually a much more stable environment that changes less frequently. So it would be reasonable to expect a similar or worse situation on the backend code, with some outdated and vulnerable components. And this is scary.

“You should always know and assess your
risks due to opensource components”

However, this is also something any development team should always actively look into. Making sure that your opensource components are up to date and not vulnerable is a fundamental step in the development process. Meterian can help you do that (actually, it can do that for you and your team). Check out our one minute video that explains how meterian works:

And if at this point you want to learn more, please take a look at these two articles:

Remember also that you can check your website yourself with our online web scanner, and Meterian has also a free plan that you can start using today. Why wait?

Stay safe. Stay connected. Stay endless.

Easyjet hacked, 9 million customer records compromised.

Why do I need Meterian? My code is secure.

bbossola1 Comment

This is really a good question, that many potential prospects are asking us. For most of the time the answer is easy: we can point them to hacks to the likes of Equifax, British Airways, Carphone Warehouse and so on. But what if someone believes they’re already protected?

We are already checking our code!

Yes, some of us already have a SAST solution in place, like SonarCube or Fortify, and we think we are fully protected. Some of us instead use opensource alternatives, like Spotbugs or PMD, and we also feel okay. These tools will continuously scan your developers’ source code and make sure that it’s not including any pattern that could be exploited by a malicious hacker.

On top of that, we have already secure coding in place: we use peer reviews and pair programming, so that all our code is severely scrutinized. We use a set of agreed secure coding practices, we follow detailed checklists, and we have developers trained continuously on these matters. And yes, that’s good!

But not everything is written from scratch…

When developers code, they do not write everything from scratch. Have you ever been surprised at how little time it took a piece to be delivered? Maybe, just once. And you ask how did that happen? Your developers, rightly so, dipped into the big pool of opensource and pulled a component that was able to accelerate their development, providing ready to use building blocks so that they could concentrate only on the business logic.

Those opensource components are so widely used, that in your final packaged product, up to 80% of the code is made of those components. Only a mere 20% is the carefully crafted code by your developers, where your internal practices and existing tools make a difference. But who’s checking the security of those opensource components? Well, it so happens that many people across the world checks them. This allows the components to evolve quickly. When a problem is found, either a bug or a security problem, it’s rapidly fixed and a new version of the component is released. When this becomes a security problem, often the issue is publicly reported in specific mailing lists or newsrooms dedicated to security.

How do you know an opensource component needs to be updated?

The core problem is, how do you know about all this? How does your team become aware that a certain component they use is now vulnerable, and that they need to update to a new version? How do they make sure that the code they do not write, which could account for 80% of your product, is also secure? Do you maintain a team the does these things? A team that painfully scrutinises multiple news sources, makes sure that your application does not contain a vulnerable or out of date component, alerting your developers accordingly?

This is where SCA (Software Composition Analysis) like Meterian enters the scene. These products are a natural complement to tools like SonarQube or PMD, as they check the code your team did not write. Typically running along with your build system, they will prevent your product to go live if a vulnerable component is discovered and will provide your developers the information they need to fix the problem immediately (and, in some occasions automatically). You will be able to secure 80% of the code your development teams produce without investing a fortune, without further head count, and with a minimal integration effort.

So, if you do not have a solution for your opensource components in place, it won’t hurt taking a look at Meterian: it’s an all round affordable system that will give you peace of mind about the code that developers do not write. And, by the way, it also checks component licences, but this is for another blog post 🙂

Why do I need Meterian? My code is secure.

What do we mean by “stability”?

bbossolaLeave a comment

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

bbossola8 Comments

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.

Thankfully, not all open source licenses are so harsh. Read our blog: Open Source Licensing- The Weirder the Better, to see some more light hearted component’s conditions of use.

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.

Similarly, if you are looking to assign a license to your own proprietary code, read our blog: Which Open Source License is For You for an introduction to the world of open source licensing.

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

Time to update your boots!

bbossolaLeave a comment

Bootstrap v4.3.1 and v3.4.1 are out and available to patch an XSS vulnerability, CVE-2019-8331. For any users of the legacy 3.3.7, this will fix also other three XSS issues, namely CVE-2018-14040,  CVE-2018-14041 and CVE-2018-14042. Bootstrap now include a JavaScript sanitizer that will only allow whitelisted HTML elements in the data attribute of an element.

It’s available through all the channels: as NPM package, via CDNs and for old fashioned guys also as a direct download from Github. You do not have any excuses now, please upgrade!

 

Time to update your boots!