developer

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

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

viviandufour, , , , Leave a comment

Updated: 31 Dec 2021

5 minute read

This is a call to arms. All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered Apache Log4j vulnerability since its announcement on Dec 9, 2021. Since then several security vulnerabilities in the wild have been discovered.

CVE-2021-44832

Vulnerability Score: 6.6 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: 2.0-alpha7 to 2.17.0 inclusive, except 2.3.2 and 2.12.4.
Fixed in version: 2.17.1

CVE-2021-44228

Vulnerability Score: 10.0 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions before 2.14.1, inclusive
Fixed in version: 2.15.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45046

Vulnerability Score: 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) (updated 18/12/2021)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions up to 2.15.0, excluding 2.12.2
Fixed in version: 2.16.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45105

Vulnerability Score: 7.5 (CVSS: 3.0 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions from 2.0-beta9 to 2.16.0, inclusive
Fixed in version: 2.17.0


Which systems does this affect?

Apache Log4j is probably the most common library used for logging in the Java ecosystem with over 400,000 downloads from its GitHub project. It is used in Java applications to log system and user activities, so there’s a serious possibility your Java software is using it. It is used, internally, by many other Apache frameworks such as Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo. It is also actively used in many other open source projects, like Redis, ElasticSearch, Elastic Logstash, Ghidra and many others.

Among all these open source components, one needs a special mention: Apache Struts. Yes, it is actively using Log4j. There exists a potential to trigger high-impact attacks against a wide variety of apps and services, similar to the scale witnessed in 2017. At that time, due to the vulnerability exploited in the Equifax megahack, 140 million customers’ data in North America and UK were breached. The latest version of Apache Struts, 2.5.28, uses by default Log4j version 2.12.21, which is vulnerable to this attack. This time, however, the scope for damage could be even wider, as Apache Struts is one of many Apache frameworks that use Log4j. 

The Java ecosystem is in very broad use in enterprise systems and web apps and many mainstream services are likely to be vulnerable. Therefore, software maintainers and developers should pay close attention to this vulnerability. 

This has been preliminary filed as CVE-2021-44228, and a subsequent vulnerability was also flagged, now filed under CVE-2021-45046.


Why does this threat demand an urgent patch?

This vulnerability allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers.

This is actively exploited on the internet now and there is already a simple POC (proof of concept) available on the internet that explains how to do it. 

From https://www.wired.com/story/log4j-flaw-hacking-internet/:

“All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.  […]Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers told WIRED that the approach could also potentially work using email.”

If you maintain an enterprise system using Java software, you would need to update all affected applications, whether they are maintained directly by your organisation or your supplier organisation.

Within 2 days of the 2017 vulnerability being announced, several systems around the world were breached by exploiting the software weakness.  We do not want more cyber breaches of such scale and all need to react quickly to patch vulnerable systems.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using Apache Log4j.  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using Log4j, 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:

$ mvn dependency:tree | grep log4j-core | grep compile
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.12.1:compile

If you see any response lines, check the version: if it’s below 2.16.0 (as in the above example) you may be affected.


My system has the vulnerable log4j library — how can I mitigate the risk?

There is a patched version of the library that resolves the issue.  Released by Apache Software Foundation, the solution is to immediately upgrade log4j to the latest log4j version 2.16.0.  The fixed version is available via Maven. 

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:

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.16.0</version>
    </dependency>

A set of mitigations, specific to the version you are using, are also available on the Apache Log4j website. The Apache Struts team provided specific advice on how to handle the issue.

If you are using an external product that runs with Java, you can also protect your systems by launching the JVM with this special parameter:

-Dlog4j2.formatMsgNoLookups=true

This is useful for tools like Jenkins, where you have control of the installation but you do not have control of the code, but please note that this does not protect against the latest CVE.


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 


Are Meterian applications affected by the log4j vulnerability?

No. We have verified our applications and none are using log4j.  We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components.   

Related references

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

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

Open Source Licensing- the Weirder the Better

Elizabeth Laffoy1 Comment

5 minute read

Photo by Sora Shimazaki on Pexels.com

As it’s a requirement that all open source projects are released under at least one open source license, they hold a great deal of influence in how said open source code is used and re-distributed by others. Whilst some licenses can be difficult to make head or tail of due to complicated non-developer language, there are some more relaxed licenses that take the opportunity to have some fun with their requirements. So, to save you doing it, we have assembled our top 5 all time quirky open source licenses to look out for: 

  1. The Beerware License

Written by Danish software developer Poul-Henning Kamp, this license states that if the user thinks the stuff they reuse is worth it they must buy the creator a beer in return. The license’s original notation can be found here. Kamp states his reasoning for the Beerware license is an act of defiance against ‘lawyers trying to interpret freedom’, believing that free open source code should remain free regardless of how much profit is made through its use. Since the requirement is optional, based on the contingency that the user believes the code is ‘worth it’, this license falls under the category of ‘CopyRight only’ licenses. If the requirement were mandatory, the license would be classed as ‘non-free’, and Kamp would most likely be drunk a lot of the time. 

  1. The Chicken Dance License

Otherwise known as the CDL, this license requires employees affiliated with organisations using the open source code to perform ‘The Chicken Dance’ for varying amounts of time, depending on how many units are distributed. The license was created by Andrew Harris with the goal of making “intellectual property far more entertaining to deal with”. Similarly to Kamp, Harries includes himself in wanting fewer lawyers in software – suggesting that the motive behind this wacky license holds strong roots in open source principles of open collaboration. The ‘Chicken Dance’ in question can be found here, but if you can’t master it don’t worry- the license states that moving in a chicken like manor is sufficient.

  1. The Don’t Ask Me About It License 

Perhaps the most simple of the licenses included in the blog, this license simply requests that users do not pester the creator with any issues they may be having with the file. The nod to lack of responsibility is admirable, there is something to be said for wanting to lead a quiet life post software development.

  1. The Hot Potato License

This license states that ‘all rights are reserved by the last person to commit a change to this repository’. Thus, the rights are passed on from person to person infinitely- like a game of hot potato. However, to avoid anyone interrupting this game of hot potato, users are prohibited from making drastic changes to the repository that would do so. It’s a nice touch from the creator to give us all the opportunity to control the rights of such a well known open source license at least once in our life 

  1. The Do What The F*** You Want License

The Do What The F*** You Want License is a ‘very permissive’ license that can be taken as a direct stand against the principle of licencing software in general. Whilst playing by the rules of licencing, this license intends to be a free pass for distribution without any constraints. However, in the attempt of being so liberal, this license actually poses an issue for some major corporations. For example, Google finds the license too unclear to use confidently. As a result, they have banned the use of components under this license completely. However, if you like the look of this license don’t let Google scare you off, wtfpl.net offers guidance on how to make the most of it.

Whilst there is a funny side to open source licensing, failure to stay on top of your business’s license compliance management could be detrimental. A strong defence of these risks, as well as efficient software composition analysis tools will help manage the use of open source in your code base and avoid hefty fines and diminished customer relations. In this way, legal due diligence is an important step in agile development as it allows to ‘push forward’ and remediate any legal obstacles blocking a decision from being made. To read more about cyber due diligence, check out our past blog.

Get in touch with a member of our team to learn more about how Meterian can help your business master License Compliance Management.

Open Source Licensing- the Weirder the Better

Which Open Source License is best for you?

Elizabeth Laffoy1 Comment

3 minute read

Photo by Pixabay on Pexels.com

The right open source license is necessary to protect your intellectual property and an important factor in maintaining license compliance management. As well as this, open source licensing underpins the essence of open source values in facilitating open redistribution. The integration of license compliance management into your CI/CD pipeline is just another way of optimizing the efficiency of your software supply chain. The best license for you will be shaped by your reason for creating code and your goals for redistribution. Use our introductory guide to decide which is best for you. Licenses and legal terminology are that of a very different world than what developers are used to. Because of this, we have organised our guide into developer persona categories. Simply pick the Dev that aligns most closely with yourself to learn more.

Devs working within a community:

If you are collaborating with an existing community or project, the best option for you is to align with the community you are a part of by adopting the project’s existing license. This can be found under the ‘license’ or ‘copying’ file of a project. If this fails, simply contact the maintainers of your community for clarification. As the licensing decision has already been made for you, you can spend less time on legalities and more time on software innovation- lucky you.

Devs not looking to overcomplicate:

The MIT license is perfect for devs that want to keep things straightforward. It is relaxed in that redistribution requires little to no control criteria other than the continuation of copyright and licensing details. The material that falls under this license is able to be used for both commercial and private use, as long as a copy of the license and copyright notice is included in any instances of modification or distribution. However, when using this license you should be aware that limitation of liability is included. As well as this, there is no warranty provided with this license.

Devs that care about sharing improvements:

The GNU General Public License v3.0 allows you to copy, distribute and modify projects under the condition you note all modifications and dates of modification in the source files. All modifications made to GPL-license code must also be made available under the GPL with installation instructions for future devs. This license forbids users from sub-licensing, although it provides software that does have the right to run and distribute the code. Users should be aware that this license includes a limitation of liability, meaning that the owner cannot be charged for damages associated with code using this license.

We hope this quick read has shed some light on the world of license compliance management. Whilst it may be confusing at first, it is worth taking the time to pick the right license for you and your project to best publish your software and display your innovation. For more information on potential risks associated with license compliance, see our past blog: ‘How the wrong license can harm your business’.

Get in touch with a member of our team to learn more about how Meterian can help your business master License Compliance Management.

Which Open Source License is best for you?

Love Your Developer: How to maintain & secure your open source components?

Victoria C., , , , 1 Comment

6min read

Happy Valentine’s Day! Meterian is feeling the love, so we want to share it by telling you the best way your business can love their developers! In this article we highlight the benefits and costs of using open-source software.  We’re also going the extra mile to give you tips on how to secure and maintain these components without slowing down your developers – the guardians of your business’ software that can propel you ahead of competitors.  

Here’s a little history lesson for you to begin with! Back in the 1940s-70s, software innovated at a slow pace. It wasn’t even regarded as a valuable asset in the working environment. The 1980s came and we see how software copyright was introduced, commencing a period where there was a boom in software innovation and a burst in software companies.  As the decades went on, people started to realise the value of open source software.

In 2000, the use of open source projects as well as components, began to grow significantly. Market research has predicted the global market size to grow from USD 11.40 billion in 2017 to USD 32.95 billion by 2022. Open source software has lowered development costs and accelerated innovation by reducing time to market. Now we see that companies who innovate early are 67% more likely to outperform.

Benefits of open source software 

Sometimes taking advantage of free resources is better. For example, in 2010 the use of open source was so common, it became a table stake. All companies were using it, otherwise they would fall at a disadvantage to their competitors. Open source solutions speed up software/hardware solutions, save money, provide flexibility and help companies stay on top of technological developments. This is supported by a survey which found 53% of companies have an open source program or plan to establish one in the near future. 

Developers are able to become creative and help solve problems in the software space when using open source solutions. It is the consumer and producer relationship that makes open source software thrive. As a result, there is more software availability for all users without having to reinvent the wheel. This in turn helps organizations. Recent research from Harvard Business School has shown that open source contributing companies capture up to 100% more productive value from open source than companies that do not contribute back. It creates a snowball effect: the more companies use it, the more the community is able to survey, criticize and praise it. Therefore, this strengthens the quality of the software used, including its security, usability and stability.

Open source software also comes with management benefits. Organizations tend to struggle when managing huge volumes of structured and unstructured data. This is where open source solutions can help! It helps to simplify business processes, as well as saving resources for things which are not needed for the success of a business. Essentially, it provides more flexibility for the company.

Taking a look at customer value is important. Due to the flexibility of open source software solutions, companies are able to customize to suit the needs of their particular customers. For example when you integrate two pieces of software. This requires less time than if the company were to write the integration software from scratch themselves. Therefore, it benefits both the company and their customers as well. Customers might even be willing to pay more for better solutions if they see this software is meeting their needs so efficiently and rapidly. It is all about viewing open source software as a resource and a powerful motivator.  

Costs 

When it comes to the law, open source solutions can sometimes be restricted to certain countries. For example, GitHub made headlines when it made it difficult for developers in Cuba, Iran, North Korea and Syria to access private repository services. There have been changes for open source licences in response to these types of situations, as it should be allowed to continue to expand and not interfere with international rules on software access. So companies should always know what licences are tied to the software they are using to avoid an IP breach. Read our past blog post on how the wrong licence can harm your business, if you haven’t already!

Moreover, open source components are attractive to cyber attackers. Firstly, open source vulnerabilities within components are discovered daily. Secondly, traditional testing tools and methods are ineffective in identification and therefore few companies understand the components being used in their applications. This lack of awareness leaves organizations increasingly exposed to an attack. For example Hollywood Presbyterian Hospital in California suffered a ransomware attack due to an outdated JBoss server software. The attacker uploaded malware to the out-of-date server without any interaction with a victim. This resulted in delayed patient care and the hospital had to pay $17,000 to recover access to files and the network.

A further cost or strain is the need to constantly maintain, test and secure these components. For example, in 2018 Sonatype released its fourth annual State of the Software Supply Chain Report and showed how software developers had downloaded more than 300 billion open source components in the past 12 months, 1 in 8 of those components having contained known security vulnerabilities.

Not catching these security bugs early on in the development process can lead to very costly and damaging outcomes.

How to maintain and secure open source components?

Firstly, you can start by making an inventory of all your open source components used when developing software. This inventory must include all the components, versions in use and the download locations for each project. Software bill of materials (SBoM) would be this inventory.

There is also a need to map out any known security vulnerabilities. The National Vulnerability Database (NVD) is a great place to provide information on publicly disclosed vulnerabilities in open source software. However, make sure you do not use this as your sole source for vulnerability information, as sometimes not all vulnerabilities are reported and the format of NVD records make it difficult to see which versions have been affected.   Meterian uses several sources in addition to the NVD.

Open source solutions are a brilliant resource. But to maintain its benefits there needs to be an effort to secure the open source components to lower the risk of them being vulnerable to cyber attacks. For example, a study conducted by Kula et al. on migrations of 4600 GitHub projects showed that 81.5% of them do not update their direct library dependencies, sometimes even in cases when they have been affected by publicly known vulnerabilities. This emphasizes the lack of awareness about security vulnerabilities within open source software. For this reason, to secure your open source components there is an urgency to upgrade software and keep on top of the known vulnerabilities.

https://www.pexels.com/photo/close-up-photography-of-yellow-green-red-and-brown-plastic-cones-on-white-lined-surface-163064/

Security is a community effort. There is a testing process for each project that is open to everyone. Developers using open source software are able to judge. This community of users are constantly evaluating and testing the security of certain components. Following this, there will be feedback on issues that have been found. For this reason, building open source software is safer than proprietary software because more people can test and contribute to its security. At the same time, there must be care about the code contributions accepted. A governance process and reviews in regards to any open source contribution should be made.

Constant vigilance is key. More than 3,600 new open source vulnerabilities are discovered every year and a significant amount appear daily.  Developers need to make sure their use of open source software is secure. Asking questions such as, is the code I am using good? Does it have any bugs? Due to vulnerabilities being identified on a daily basis–some have more high risk than others–there needs to be a practice within organizations to monitor or test each time the software changes. 

Meterian helps businesses get the most out of their software investments

Open source software has been changing how our world works, giving us a sustainable ecosystem that can work for everyone as long as it is looked after.

Meterian can automatically inventory your open source components and analyse them to check if they are up-to-date or have any publicly disclosed security and licence risks. Get started on building a proactive defence for your customer data and software IP.  Love your developers and let them innovate freely while using Meterian to secure your open source components. We can block insecure code before it goes live.  It will save you and your developers time and money, allowing your business to be less vulnerable to cyber attacks.  

Check if there are any open source security holes in your company’s website that puts your business at risk of a data or IP breach before it’s too late.

Try our free webscanner today.

Love Your Developer: How to maintain & secure your open source components?