Blog

Container Security Tools Comparison for Vulnerability Scans

Recently, we took on a new challenge: compare 5 popular container security tools, including our solution. We wanted to see how the products stack up against each other. How did they do? Read on to find out!

TL; DR:

Containers have been causing waves in IT and dev circles since 2013 when Docker’s container technology was launched. They have revolutionized deployment adding both speed and stability and have become critical for most IT operations, so securing them is a priority for all of us. How well do various tools do that? See the table below:

ToolStep 1 (Squid)Step 2 (Patched)Step 3 (Add App)Result
MergeBase312ALL
Aqua000NONE
Snyk2002
Docker Hub1001
Quay000NONE

But before we get into the details, it’s worthwhile to quickly revisit the importance of application container security in the modern-day development landscape.

The Importance of Container Security

Containers enable developers to run applications quickly and reliably when moved from one computing environment to another. But despite their many advantages – including increased application isolation – containers also amplify security risks. Increasing adoption in production environments makes them attractive to malicious actors. Since traditional network security solutions cannot always protect against lateral attacks, a lot of effort goes into developing application container security solutions.

Container security refers to the tools (e.g. Docker container security solutions) and policies implemented to protect container integrity and reliability, mitigate risk, and minimize vulnerabilities.

Container Security Tools Compared

To protect containers from attacks, many security tools are available. Usually, they audit the Common Vulnerabilities and Exposures (CVE) set by the National Vulnerability Database (NVD), or the benchmarks set by the Center for Internet Security (CIS).
Most containerized applications and their underlying infrastructure are distributed widely and highly dynamic. In this scenario, manual vulnerability scanning can be time-consuming and resource-intensive. To reduce operational overhead, many tools offer automation. Some focus on specific aspects of the cloud-native ecosystem, e.g. runtime security.
For our analysis, we picked 5 popular automated container scanners:

  • Aqua
  • Snyk
  • Docker Hub
  • Quay
  • MergeBase

Methodology

Before starting our analysis, we set up three images. The images are a logical progression where start with a vulnerable version of squid, then patch it and then add a vulnerable proprietary library, a proxy for applications you might produce and deploy in Docker images

container scanning expectations
  1. Seeded with a vulnerable version of Squid, a caching and forwarding HTTP web proxy
  2. Patch Squid to latest safe version
  3. Download a proprietary jar file that is vulnerable. Your own applications would typically fall in this category and it is challenging for most container scanning tools to analyze these.

We expected that each application would find vulnerabilities in all these steps.

However, this is not quite what happened!

Before we reveal the results of our tool comparison, here’s a sequence of steps that shows the Docker files used to build the images. Also, for readers planning to replicate our experiment, bear in mind that vulnerability scanning is sensitive to the date of the scan. We completed this experiment in early April 2021. New vulnerabilities may have been found and published since then, and security scanning tools themselves may have also changed.

Procedure to Build Images with Docker Files

If you need the build scripts, please ask us. We believe in transparency and are happy to provide them.

Results of Container Scanner Tool Comparison & Analysis

1. Aqua

For teams wondering how to secure Docker containers, Aqua claims to provide “enterprise-grade security for Docker environments” from development to production. Its tool scans images for vulnerabilities, malware, configuration issues, etc. for continuous image assurance. Its vulnerabilities database is aggregated from multiple, constantly-updated data streams to increase detection accuracy and provide better protection.

Aqua container scanning did not find any vulnerabilities

Despite these claims, the tool didn’t quite make the cut in our test. In fact, Aqua found no vulnerabilities at all, raising doubts about its effectiveness.

2. Snyk

Snyk helps teams automatically find, prioritize and fix vulnerabilities in containers throughout the container lifecycle. It can detect vulnerable dependencies during coding, prevent new vulnerabilities from passing through the build process, and test the production environment for newly-disclosed vulnerabilities.

Snyk says that it has fixed over 5 million container vulnerabilities. But during our tests, Snyk found two vulnerabilities in Step 1:

  • CVE-2020-25097 (Squid)
  • CVE-2021-30139 (apk-tools)

Snyk did not find any vulnerabilities from Steps 2 and 3.

3. Docker Hub

Docker hub container scanning did find only one vulnerability

When a Docker image is pushed to Docker Hub, it automatically scans it for vulnerabilities. Teams can review the security state of images, and fix identified issues for more secure deployments. The vulnerability report displays vulnerabilities, and sorts them according to severity. It also displays information about the:

  • Package containing the vulnerability
  • Version in which it was introduced
  • Whether the vulnerability is fixed in a later version

In our analysis, we found that this Docker container security scanner is not effective at finding all vulnerabilities. During testing, it only found one vulnerability from Step 1.

4. Quay

Quay container scanning did not find any vulnerabilities

Quay automatically scans containers to provide a real-time view of known vulnerabilities. The scan report displays vulnerabilities by severity level: Low, Medium and High. It also specifies whether patches are available.

But in our vulnerability test, Quay found no vulnerabilities. For all 3 steps, the report displayed a “passed” status for the security scan.

And now, we come to the final tool in our analysis: our own MergeBase tool.

5. MergeBase

In our analysis, only MergeBase found all vulnerabilities, including those the other tools missed:

MergeBase container scanning finds all vulnerabilities
  • CVE-2021-28116 (Squid) for which no patch is available
  • CVE-2016-5725 in the application, a directory traversal vulnerability in JCraft JSch before 0.1.54 on Windows, when the mode is ChannelSftp (source: CVE Mitre)

In summary, MergeBase found:

  • 3 vulnerabilities in Step 1
  • 1 vulnerability in Step 2
  • 2 vulnerabilities in Step 3

Comparison Conclusion

In containerized environments, the deployment pipeline is often standardized across different dev teams. Container scanning can help find vulnerabilities and take proactive action to fix security gaps. Securing containers and building security into the CI/CD their pipeline can help reduce the size of the attack surface.

However, different container scanning solutions yield inconsistent results on the same environment. Worse, many solutions fall short of their claims to help strengthen end-to-end container security.

In our analysis of 5 application container security tools, we found that our tool MergeBase was the only one that could find all vulnerabilities in our testing environment. Thus, compared to other tools, MergeBase provides complete DevSecOps coverage and reliable container security.

Want to know more about MergeBase? Take a look here!

Enhance software supply chain security says White House

Summary

The White House exec order to improve the software supply chain security
White House executive cyber security order

Software supply chain security is a common theme in recent attacks such as on the Colonial Pipeline and SolarWinds. In response, President Biden released an executive order to improve the nation’s cyber security. The order is a testimony of the importance of the digital ecosystem today to our society, economy and way of life. Cyber security is critical in protecting it and the President’s clear message is that we need to do more.

The government want to improve its own cyber security practices and related agencies. It also proposes to remove barriers for information sharing, and enhancing software supply chain security. The software supply chain security is the only specific attack vector that is highlighted.

These attacks cause the most damage and at the same time businesses and governments are ill prepared. So what is a supply chain attack and how can it be mitigated?

What is a Software Supply Chain Attack?

A supply chain attack leverages the access of an external partner or provider to gain unauthorized entry to a system or network. It takes advantage of the inherent trust a target has in its suppliers, using it to infiltrate and launch the cyber-attack. Its use of stealth and its indirect ‘trusted’ approach make a supply chain attack an effective weapon in any threat actor’s arsenal.

Every organization and individual relies on third-party software in some way or another. When we install software, hardware, or use code from a trusted source, it is natural to assume that it hides no malicious intent. In addition to this inherent trust, a supply chain attack also uses the human element to bypass any perimeter security. As administrative users and software developers install software, hardware, or reuse third-party code, they do so on the internal network, bypassing any security controls that prevent external threats.

Supply chain attacks that target technology infrastructure come in many variations. Threat actors can infiltrate a software provider and embed malicious code that infects end users when they install or access the product. Another effective supply chain attack technique is infecting software code repositories that software developers leverage to create systems. Finally, threat actors can also infiltrate and infect the embedded software that operates the hardware on networking equipment, servers, and end-user devices.

What is a software supply chain?

Modern software development processes rely on code reuse to build systems rapidly and cost-effectively. By leveraging existing code, developers can quickly assemble a system with its needed components instead of coding the entire solution from a blank canvas. Typically, programmers either reuse internally developed software code or leverage third-party libraries and frameworks. These components and their dependencies form part of the software supply chain. In other words, a software supply chain is a list of elements that goes into or affects the code from development to production.

Almost every software application or service we use today leverages a software supply chain. For example, Netflix and Uber use Node.js, an open-source, server-side JavaScript platform that is well suited for scalable applications. Another example is WordPress, a content management system used to run nearly 40% of the world’s websites. The list goes on, but it suffices to say that organizations leverage software supply chains everywhere. Besides leveraging the frameworks and platforms mentioned, software developers also use code libraries to build their solutions. Services like GitHub and StackOverflow are valuable resources where developers can find libraries, code snippets, and advice to help them create solutions.

However, a software supply chain does not only pertain to software development. It can also refer to instances where organizations install and run third-party applications in their technology environment. For example, every organization leverages third-party software for email. It would be both inefficient and expensive to develop an in-house solution for this utility. The same goes for system monitoring, file sharing, security, and other commodities in a technology environment. All these third-party applications and the external code it uses in its custom-developed applications form part of an organization’s software supply chain.

The anatomy of a supply chain attack

A supply chain attack infects the third-party technologies organizations use. It then leverages this unauthorized access to infiltrate and attack their primary targets. Typically, supply chain attacks start when threat actors exploit a vulnerability to gain access to a supplier’s systems. Once they have gained entry, they embed malicious code into the supplier’s software or hardware with a particular payload. The threat actor then waits until the target organization or user runs the supplier’s infected software or installs its infected hardware. As this infiltration technique circumvents any perimeter security, its indirect attack methodology is highly effective. It is also successful in gaining access to secure environments as these attacks typically target less secure elements in the supply chain.

Supply chain attacks are not a new type of threat, but recent cases have raised their prominence in the public domain. If we look at past instances, the Target data breach where malware infected their Point of Sale systems occurred in 2013. In that instance, the attackers compromised the organization’s third-party refrigerator vendor to infect Target’s POS environment with malware that stole credit card details. Another significant example is the famous Stuxnet malware that nation-states used to sabotage Iran’s nuclear centrifuges in 2010. In this example, the attackers used the digital certificates of Realtek Semiconductor to make their malware look legitimate to system administrators and evade anti-virus.

More recently, in the SolarWinds supply chain attack, threat actors deployed malware during a routine update that emanated from SolarWinds’ servers. Every organization that ran the update was subsequently compromised, including technology companies and secure government agencies. As a result of this attack, the United States sanctioned Russia, believing that the Kremlin played a role in this mass infiltration. Other recent supply chain attacks include the narrowly averted PHP backdoor and the Code Dev incident.

These supply chain attack examples show that this technique has successfully infected many organizations around the world. What is of particular concern is that these supply chain attacks also succeeded in highly secure environments. The examples also show the extensive ramifications of a successful attack. One undetected infection can affect thousands of users and organizations.

Software supply chain security, the open-source risk

Many organizations use open-source software in some way, shape, or form. With open-source code present in 90% of modern applications, this vital element in the software development ecosystem is vulnerable to a supply chain attack. The recent PHP case mentioned earlier is a prime example. Modern software applications reuse open-source libraries, frameworks, and code snippets. Threat actors target these components as they are typically less secure.

The 2020 Sonatype State of the Software Supply Chain Report stated next-generation attacks increased by 430% in the preceding 12 months. Unlike commercial software, open-source relies on the community to ensure its security. However, it is up to the organizations that use the software to conduct regular analysis, security audits, and penetration tests.

Technology supply chain risk

The technology supply chain includes hardware and software. Although the focus of this article has been on software supply chain attacks, organizations cannot ignore the hardware risk. Numerous examples of mobile devices arriving with embedded malware and compromised networking equipment used to breach secure networks highlight this threat.

These instances illustrate that business and technology leaders need to consider their entire technology ecosystem when assessing their supply chain risk. As threat actors have shown they can infiltrate hardware vendors, global software corporations, and open-source code repositories, organizations need a comprehensive security strategy. A supply chain attack could come from multiple vectors, and enterprises need to ensure they cover all their bases.

Software supply chain security 

Mitigating the risk of a supply chain attack requires a defense-in-depth approach. Organizations need to conduct thorough security assessments and implement multiple measures to minimize this risk. For example, many regulatory security frameworks such as PCI DSS and the NIST Cybersecurity Framework mention supply chain risk. These compliance standards state that organizations should routinely assess third parties to ensure they comply with any contractual obligations.

As part of the contractual obligations organizations enforce on their suppliers, security testing must form a vital part of any technology deliverable. By placing the responsibility on the vendor to ensure their product is safe, organizations can enforce terms should the vendor fail to meet their obligations. In addition to requiring vendors to test, organizations should also implement internal security testing and monitoring. This layered defensive approach can help them identify any security issues the vendors may have missed.

However, when leveraging open-source software, enforcing contractual terms is not an option. As many open-source technologies come with set licensing terms, it compounds the problem even further. Organizations also need to consider the license and infringement risk, restricting how the company can use the software while protecting itself from a supply chain attack. In these instances, leveraging the services of a Software Composition Analysis (SCA) tool like MergeBase mitigates this open-source risk. As the onus is on the organization to test and validate the open-source components used in an application, an SCA tool like MergeBase adds the required defensive layer.

According to this Gartner Report, the information security of a supply chain must focus on data and IT infrastructure, products, and operations. If we consider the various security technologies in place at enterprises today, organizations implement a myriad of defensive technologies and processes. Firewalls, intrusion detection and prevention solutions, segmented networking, and vulnerability scanners are just some of the solutions that protect their IT landscape. However, these solutions typically safeguard against external threats. Organizations need to ensure the configuration of these platforms also scan and detect any internal anomalies which may indicate a successful supply chain attack.

Enterprises can also consider air gapping systems to mitigate the supply chain risk. Applications and networks not connected to the Internet have a much lower risk of compromise. However, in many cases, this approach is not feasible. They are also not foolproof. The Stuxnet example mentioned earlier was a successful attack against an air-gapped system.

Securing the software supply chain

Supply chain attacks target less secure elements in complex systems. As modern technology solutions rely on reusable components, threat actors target these elements to circumvent security controls. This type of cyber-attack is not new. However, recent discoveries have highlighted the risk organizations face. Traditionally, organizations have tailored their security solutions to mitigate external threats. With the increase in supply chain attacks, it is clear that threat actors target the supply chain to circumvent these controls.

The supply chain attack risk covers every element of an organization’s IT landscape. Attackers have succeeded in infiltrating the supply chain of hardware and software elements. With software development components being a key area of risk, organizations need to implement controls that ensure the security of their application ecosystem.

The MergeBase platform specializes in software supply chain security. It mitigates the risk of a software supply chain attack from development to production. It highlights risks and empowers developers to remedy any security issues during the early stages of the software development lifecycle. MergeBase also assesses software components for vulnerabilities during the build process, ensuring organizations do not release insecure code to production. However, once an application is in production, it may not remain secure. Researchers or threat actors discover software vulnerabilities all the time. MergeBase mitigates this risk with its monitoring and alerting capabilities keeping organizations protected against any new vulnerabilities in production.

What is a supply chain attack?

Summary

harbour part of a traditional supply chain

A supply chain attack leverages the access of an external partner or provider to gain unauthorized entry to a system or network. It takes advantage of the inherent trust a target has in its suppliers, using it to infiltrate and launch the cyber-attack. Its use of stealth and its indirect ‘trusted’ approach make a supply chain attack an effective weapon in any threat actor’s arsenal.

Every organization and individual relies on third-party software in some way or another. When we install software, hardware, or use code from a trusted source, it is natural to assume that it hides no malicious intent. In addition to this inherent trust, a supply chain attack also uses the human element to bypass any perimeter security. As administrative users and software developers install software, hardware, or reuse third-party code, they do so on the internal network, bypassing any security controls that prevent external threats.

Supply chain attacks that target technology infrastructure come in many variations. Threat actors can infiltrate a software provider and embed malicious code that infects end users when they install or access the product. Another effective supply chain attack technique is infecting software code repositories that software developers leverage to create systems. Finally, threat actors can also infiltrate and infect the embedded software that operates the hardware on networking equipment, servers, and end-user devices. 

What is a software supply chain?

Modern software development processes rely on code reuse to build systems rapidly and cost-effectively. By leveraging existing code, developers can quickly assemble a system with its needed components instead of coding the entire solution from a blank canvas. Typically, programmers either reuse internally developed software code or leverage third-party libraries and frameworks. These components and their dependencies form part of the software supply chain. In other words, a software supply chain is a list of elements that goes into or affects the code from development to production. 

Almost every software application or service we use today leverages a software supply chain. For example, Netflix and Uber use Node.js, an open-source, server-side JavaScript platform that is well suited for scalable applications. Another example is WordPress, a content management system used to run nearly 40% of the world’s websites. The list goes on, but it suffices to say that organizations leverage software supply chains everywhere. Besides leveraging the frameworks and platforms mentioned, software developers also use code libraries to build their solutions. Services like GitHub and StackOverflow are valuable resources where developers can find libraries, code snippets, and advice to help them create solutions. 

However, a software supply chain does not only pertain to software development. It can also refer to instances where organizations install and run third-party applications in their technology environment. For example, every organization leverages third-party software for email. It would be both inefficient and expensive to develop an in-house solution for this utility. The same goes for system monitoring, file sharing, security, and other commodities in a technology environment. All these third-party applications and the external code it uses in its custom-developed applications form part of an organization’s software supply chain.

The anatomy of a supply chain attack

A supply chain attack infects the third-party technologies organizations use. It then leverages this unauthorized access to infiltrate and attack their primary targets. Typically, supply chain attacks start when threat actors exploit a vulnerability to gain access to a supplier’s systems. Once they have gained entry, they embed malicious code into the supplier’s software or hardware with a particular payload. The threat actor then waits until the target organization or user runs the supplier’s infected software or installs its infected hardware. As this infiltration technique circumvents any perimeter security, its indirect attack methodology is highly effective. It is also successful in gaining access to secure environments as these attacks typically target less secure elements in the supply chain.

Supply chain attacks are not a new type of threat, but recent cases have raised their prominence in the public domain. If we look at past instances, the Target data breach where malware infected their Point of Sale systems occurred in 2013. In that instance, the attackers compromised the organization’s third-party refrigerator vendor to infect Target’s POS environment with malware that stole credit card details. Another significant example is the famous Stuxnet malware that nation-states used to sabotage Iran’s nuclear centrifuges in 2010. In this example, the attackers used the digital certificates of Realtek Semiconductor to make their malware look legitimate to system administrators and evade anti-virus.  

More recently, in the SolarWinds supply chain attack, threat actors deployed malware during a routine update that emanated from SolarWinds’ servers. Every organization that ran the update was subsequently compromised, including technology companies and secure government agencies. As a result of this attack, the United States sanctioned Russia, believing that the Kremlin played a role in this mass infiltration. Other recent supply chain attacks include the narrowly averted PHP backdoor and the Code Dev incident.

These supply chain attack examples show that this technique has successfully infected many organizations around the world. What is of particular concern is that these supply chain attacks also succeeded in highly secure environments. The examples also show the extensive ramifications of a successful attack. One undetected infection can affect thousands of users and organizations.

The open-source risk

Many organizations use open-source software in some way, shape, or form. With open-source code present in 90% of modern applications, this vital element in the software development ecosystem is vulnerable to a supply chain attack. The recent PHP case mentioned earlier is a prime example. Modern software applications reuse open-source libraries, frameworks, and code snippets. Threat actors target these components as they are typically less secure. 

The 2020 Sonatype State of the Software Supply Chain Report stated next-generation attacks increased by 430% in the preceding 12 months. Unlike commercial software, open-source relies on the community to ensure its security. However, it is up to the organizations that use the software to conduct regular analysis, security audits, and penetration tests. 

Technology supply chain risk

The technology supply chain includes hardware and software. Although the focus of this article has been on software supply chain attacks, organizations cannot ignore the hardware risk. Numerous examples of mobile devices arriving with embedded malware and compromised networking equipment used to breach secure networks highlight this threat. 

 These instances illustrate that business and technology leaders need to consider their entire technology ecosystem when assessing their supply chain risk. As threat actors have shown they can infiltrate hardware vendors, global software corporations, and open-source code repositories, organizations need a comprehensive security strategy. A supply chain attack could come from multiple vectors, and enterprises need to ensure they cover all their bases. 

Mitigating supply chain risk

Mitigating the risk of a supply chain attack requires a defense-in-depth approach. Organizations need to conduct thorough security assessments and implement multiple measures to minimize this risk. For example, many regulatory security frameworks such as PCI DSS and the NIST Cybersecurity Framework mention supply chain risk. These compliance standards state that organizations should routinely assess third parties to ensure they comply with any contractual obligations. 

 As part of the contractual obligations organizations enforce on their suppliers, security testing must form a vital part of any technology deliverable. By placing the responsibility on the vendor to ensure their product is safe, organizations can enforce terms should the vendor fail to meet their obligations. In addition to requiring vendors to test, organizations should also implement internal security testing and monitoring. This layered defensive approach can help them identify any security issues the vendors may have missed. 

However, when leveraging open-source software, enforcing contractual terms is not an option. As many open-source technologies come with set licensing terms, it compounds the problem even further. Organizations also need to consider the license and infringement risk, restricting how the company can use the software while protecting itself from a supply chain attack. In these instances, leveraging the services of a Software Composition Analysis (SCA) tool like MergeBase mitigates this open-source risk. As the onus is on the organization to test and validate the open-source components used in an application, an SCA tool like MergeBase adds the required defensive layer.

According to this Gartner Report, the information security of a supply chain must focus on data and IT infrastructure, products, and operations. If we consider the various security technologies in place at enterprises today, organizations implement a myriad of defensive technologies and processes. Firewalls, intrusion detection and prevention solutions, segmented networking, and vulnerability scanners are just some of the solutions that protect their IT landscape. However, these solutions typically safeguard against external threats. Organizations need to ensure the configuration of these platforms also scan and detect any internal anomalies which may indicate a successful supply chain attack.

Enterprises can also consider air gapping systems to mitigate the supply chain risk. Applications and networks not connected to the Internet have a much lower risk of compromise. However, in many cases, this approach is not feasible. They are also not foolproof. The Stuxnet example mentioned earlier was a successful attack against an air-gapped system. 

Securing the software development supply chain

Supply chain attacks target less secure elements in complex systems. As modern technology solutions rely on reusable components, threat actors target these elements to circumvent security controls. This type of cyber-attack is not new. However, recent discoveries have highlighted the risk organizations face. Traditionally, organizations have tailored their security solutions to mitigate external threats. With the increase in supply chain attacks, it is clear that threat actors target the supply chain to circumvent these controls. 

The supply chain attack risk covers every element of an organization’s IT landscape. Attackers have succeeded in infiltrating the supply chain of hardware and software elements. With software development components being a key area of risk, organizations need to implement controls that ensure the security of their application ecosystem.

The MergeBase platform mitigates the risk of a software supply chain attack from development to production. It highlights risks and empowers developers to remedy any security issues during the early stages of the software development lifecycle. MergeBase also assesses software components for vulnerabilities during the build process, ensuring organizations do not release insecure code to production. However, once an application is in production, it may not remain secure. Researchers or threat actors discover software vulnerabilities all the time. MergeBase mitigates this risk with its monitoring and alerting capabilities keeping organizations protected against any new vulnerabilities in production.

Open Source Risk: Plugging the hole

"The leak was worse than first thought" notes a bypasser of a boy stuck head-first into the wall of a digital dyke. Plug you open source holes with a SCA tool

Origin 

Software development based on the sharing and collaborative improvement of software source code goes back to its very origins. 

In the late 1990s, the term “open-source” was coined and received mainstream recognition in publications such as Forbes. The Netscape browser’s source code was made open source and that got a lot of attention.

The original open-source projects were “revolutions” against the “unfair” profits that closed-source software companies were reaping. Microsoft, Oracle, SAP and others, it was argued, were extracting monopoly-like “rents” for software, which the top developers of the time did not believe was world class.

Open Source Growth

Open source software was originally created by developers for developers. It was embraced slowly by more and more projects, organisations and companies and it now forms the foundation for the Internet and most of our digital assets. The code base of a typical modern application consists of 80 to 90% of open source software. Even in something as proprietary as Apple’s iPhone, the operating system consists largely of open source software. 

Currently, there are close to 1 million open source projects globally and this number increases by 79% a year

Open source victorious as last ones standing capitulate

Apple and Google embraced open source more than 20 years ago. The champions of proprietary software, IBM and Microsoft, resisted much longer. 

  “Once open source gets good enough,
competing with it would be insane.”

2006, Larry Elison, the chairman of Oracle in conversation with the Financial Times

Elison was right on the mark. It looks like we reached that point a few years ago. IBM and Microsoft were the last ones standing against open source, but  in the end they capitulated. IBM acquired RedHat  early 2019 for $34B and Microsoft acquired GitHub for $7.5B in 2018.

Open source use a surprise to many executives

Many organizations where leadership does not have a strong engineering or technical background often do not fully realize yet the importance of open source and how dependent they are on it in their digital supply chain. We regularly encounter executives who are very surprised when we analyze their applications and identify many open source libraries. Awareness is the first step in managing open source risk and rewards.

Open Source Risks: Is it really free?

Open source is bringing huge rewards to business. However, with reward comes open source risk. The two main risks are legal related to the licenses  and cyber risk related to vulnerabilities. 

Open source is free but can come with strings attached that do not match with your organization’s business model. Open source software is released under different licensing models. There are over 300 licensing models in use. Most open source software comes with friendly licenses such as the licenses for Apache and BSD. However other licensing models not so much, such as licenses for GNU GPL and GNU Affero. Use of these licenses, even in a minor way, could force an organisation to open source their entire software with devastating impact on the IP value of the organisation.  

Open source software, like all software, can contain vulnerabilities. Open source software, in general, is high quality software and not intrinsically more vulnerable. However, because of its wide usage, it is a very attractive target for cyber adversaries and so, over time, vulnerabilities are uncovered. At the moment, there are more than 150,000 known vulnerabilities. A lot of these vulnerabilities can be exploited to breach organisations and are considered to be the cause of approximately 25% of data breaches. 

One example of a major breach is the Equifax breach which exposed 145 million client records and cost the organisation more than $1.3 B to remediate. The company also lost $5B in stock market value overnight and later received a $700 M fine from the US government. 

The best defence: SCA / OSS

The best defense against open source risk is to use a Software Composition Analysis tool, sometimes also called Open Source Security scanner. These tools quickly analyse your applications or containers and provide insight into license and cyber risk. MergeBase goes a step further and provides solutions to quickly and easily reduce your cyber risk. 

A Critical Look at Cyber Investment

What is the top defensive technology area to invest in right now?

Cyber defense is a global whack-a-mole game with hundreds of billions of dollars being invested in offensive and defensive capabilities. After you invest in one area, another area of risk tends to pop up. What is the top defensive technology area to invest in right now?

Cyber is multifaceted

Cyber defense requires a multifaceted approach. Fragmentation is a natural consequence of the back and forth between cyber attackers and defenders: If we have an effective defence against a particular type of attack, adversaries will try another area, angle, or approach. Over time this means we need many technologies to secure our organisation. Like it or not, cyber defence is a global whack-a-mole game. It is an arms race, with governments and corporations investing hundreds of billions of dollars continuously in building out offensive and defensive capabilities.

We all know that we need a multifaceted approach. This involves people, process and tools. We need to make sure that everyone in the organization is motivated and has the skills and resources to fight cybercrime. Beyond understanding why and how, technology is critically important as cyberspace is tech heavy.

What area do we need to invest in?

Unless you feel at ease with your cyber protection, the question is: What is the key technology area to invest in right now? This question is very difficult for most cyber professionals as most organizations under fund and under resource their cyber operations.

We posed this question to cyber professionals by posting a poll to LinkedIn. To eliminate bias, we conducted the poll twice (second poll), reaching out to two distinct networks of cyber professionals. Feel free to repost the poll and let us know what your results are.

The poll asked what areas to focus on: MFA, perimeter security, known vulnerabilities or education. The results, which were consistent between the two polls, were: known vulnerabilities at 49% , MFA at 29%, and perimeter and education each approximately at 10%.

Known vulnerabilities routinely exploited

The results of the poll make a lot of sense. Of course, all these areas are important and really need more investment. However, the NSA and CISA continue to warn that cyber adversaries routinely exploit known vulnerabilities..

If we look at major breaches, we see plenty of evidence supporting these warnings. Sophisticated attackers use a combination of hacking techniques, as we have seen recently with SolarWinds. Exploiting known application vulnerabilities is a big part of their arsenal and allows adversaries to move laterally and subsequently elevate privileges.

In reality we find that very few organizations are able to execute fully on a vulnerability strategy.

Why can we not eliminate known vulnerabilities?

Why are we not able to routinely eliminate our known application vulnerabilities? The answer is that it is a daunting task given the level of software that most organisations are operating in combination with the level of technical debt that most of these applications suffer from. Some cyber experts call for continuous upgrading of all components. That would eliminate these problems. However, continuous upgrading is difficult for organisations that have a lot of applications. For instance, a typical North American bank has 600 software applications. Large banks tend to have many more. A lot of these applications are older and do not have active development. Therefore, routinely upgrading may not be practical.

MergeBase successful seed raise

VANCOUVER, BC – Will cybercrime cause $1 trillion in damage to an already-vulnerable economy by 2021? Not if MergeBase Software Inc. has anything to do with it. The company has just announced it raised $500,000 funding for its best-in-class cybersecurity product — helping it ramp up sales and distribution. The funding round officially closed on March 19.

“I’m impressed that during this unprecedented crisis, business leaders and investors are able to ‘keep calm and carry on’, continuing to invest in leading-edge technology to solve critical problems like cybercrime,” says MergeBase CEO Oscar van der Meer. 

The current COVID-19 crisis and social distancing measures will only accelerate the move to a fully digital economy. In this new environment, cybersecurity for digital assets and IT will be even more mission-critical to business and governments.

“So many technology-powered companies are built on open-source code and third-party apps — which is a quicker, easier and cheaper way of building software,” he explains. “But those savings come with a cost, exposing organisations using these applications to data breaches.

“Integration with external apps already causes up to 24 percent of all cybersecurity breaches — and that’s only going to grow,” he says. “MergeBase is a best-in-class solution to boost the immune system of enterprises around the world.” MergeBase’s app-security solution detects more vulnerabilities than any other tool on the market.

Enterprises are already boosting purchases of app security solutions, from 5 percent in 2019 to 60 percent by 2024, according to a Gartner report. “It’s why we’re expecting to see big growth in our business.” 

MergeBase’s solutions are aimed at large enterprises. Their customers include a government agency that processes trillions of dollars of payments every year. 

The company’s co-founders bring a combined 50 years of experience in the financial industry, and a wealth of knowledge about identifying and dealing with vulnerabilities in technology; for instance, van der Meer was a senior executive at Central1, the central financial facility and trade association for the B.C. and Ontario credit union systems. 

Investors in the current funding round include Lisa Shields and Western Universities Technology Innovation Fund (WUTIF) and Maninder Dhaliwal.

Discover More from MergeBase

Core Product

BuildGreen is a powerful solution for identifying the real risk of open source at build time or in existing applications

Learn how BuildGreen can protects your Enterprise

Add RunTime Protection

RunGreen detects and defends against known-vulnerabilities at runtime.

Learn why Runtime Protection Matters

Optional Developer Add-on

CodeGreen is an early-warning defence for your in-house development and integrates directly into code repositories

Quick Start - For Free