OpenSSL Will Issue a Patch for a Critical Vulnerability on Nov 1st.

OpenSSL has classified an upcoming issue as critical severity as it affects common configurations and can be exploited. So far (it’s October 31st right now as I type this blog post), they are not saying anything else.

It is mostly a Linux package, so here is what you should do tomorrow:

  • Ubuntu/Debian users should run “apt update” and “apt upgrade,” 
  • Redhat/Amazon/Fedora/Suse users should run “yum update,” 
  • Alpine users should run “apk update” and “apk upgrade.”
  • Any Docker containers running on base images based on any of the above obviously need to be re-imaged!
  • Typically updates do not require machine restarts, but personally, I would still reboot.

Also, after upgrading, everyone should then type “openssl version” on their machines to verify whether they even have it installed and are running a vulnerable version.

For example, on my machine right now (Ubuntu 22.04 – October 31st – 1 day before the security release):

$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Yikes! I’m vulnerable!

But seeing as it’s still Monday, October 31st, there is not much I can else I can do at this point.

Note: Only versions 3.x before 3.0.7 are vulnerable. They have never released any 2.x versions, and versions that start with 1.x are not vulnerable to this bug.

(For now, let’s pray it’s a runtime weakness in OpenSSL, and not a weakness in private keys generated by it since a weakness in generated keys would be a huge headache to deal with – I don’t think keys even retain which version of OpenSSL they were generated by!)

Forthcoming Releases

Screenshot from OpenSSL mailing list:  CRITICAL bug fix in 3.0.7
Screenshot from SSL mailing list: CRITICAL bug fix in 3.0.7

Find more here.

More updates after the release on Nov 1st:

  • OpenSSL team’s blog post about why they downgraded the vulnerability from CRITICAL to just HIGH.
  • AWS Distinguished Engineer Colm MacCárthaigh shows in deep technical detail exactly how the bug works (and how very difficult it would be to exploit).
  •  Cybersecurity and Infrastructure Security Agency (CISA) also warn about the vulnerability and encourages users and administrators to review and update to the new version.

Mitigating Supply-chain and Third-party Risks: What You Need to Know about Bill C-26 and the CCSPA

In June of 2022, the Canadian House of Commons introduced its first reading of Bill C-26, an initiative addressing cyber security within Canada’s infrastructure. This bill is not a very controversial document, and if it passes, it will bring about a few significant changes to cyber security standards in Canada.

We don’t know when (or if) C-26 will become law. But because it is keeping with trends in third-party liability law, it’s wise for software companies (and companies involved in Canadian infrastructure) to take note of the bill’s implications.

Bill C-26 deals with an emerging issue in cyber security law—third-party liability. For an overview of this issue and why it’s important, read our Executive’s Guide to Third-party Liability in Cyber Security Law.

A quick overview of Bill C-26

This bill aims to make Canadian infrastructure more secure in two major ways.

First, C-26 would keep Huawei technologies outside of Canadian telecommunications systems by amending the Telecommunications Act. While other nations have built Huawei technology into their 5G networks, Canadian legislators want to protect their network (and their data) from being accessible to the Chinese tech giant. 

Second, C-26 would raise cyber security standards for companies that operate vital systems by enacting the Critical Cyber Systems Protection Act (CCSPA)

The CCSPA designates some operators as critical cyber systems (CCSs). The act defines a CCS as a system that “if its confidentiality, integrity, or availability were compromised, could affect the continuity or security of a vital service or vital system.” If the CCSPA is enacted, organizations responsible for critical cyber systems would be required to do the following:

  1. Establish a cybersecurity program within 90 days of becoming a designated operator
  2. Mitigate against third-party and supply-chain risks
  3. Immediately report cybersecurity incidents related to any CCS
  4. Comply with any direction from the Governor in Council with regard to securing CCSs
  5. Adhere to new rules regarding the disclosure and use of information

This act applies to designated operators: individuals, partnerships, and unincorporated organizations that belong to at least one of the following classes:

  • Telecommunications services
  • Interprovincial or international pipeline and power line systems
  • Nuclear energy systems
  • Transportation systems that are within the legislative authority of Parliament
  • Banking systems
  • Clearing and settlement systems

Many companies that would become designated operators under this bill are already doing most of the things this bill would enforce. However, if this bill obtains royal assent, a few major changes will take place.

Three major changes to cybersecurity under the CCSPA

If Bill C-26 becomes law as it stands, then we can expect three things to change: incident reporting, supply chain regulations, and the degree of direct control the government will have on enforcing cybersecurity measures.

1. Security incidents will become more transparent 

The CCSPA will require any designated operator to immediately report any security incident that affects a CCS. The procedure and detail of such reports are yet to be determined.

The goal is to tighten the response loop when vulnerabilities and breaches are discovered. By requiring organizations to report incidents immediately, Canadian legislators hope to keep the public and private sectors unified in their responses to cyber threats.

2. Supply-chain security will be regulated

The supply chain has always been an effective way to breach large entities. Just like it’s easier to climb into a wooden horse than it is to directly climb the walls of Troy, it’s easier to breach a small software contributor than it is to directly breach an enterprise application. 

This is why the CCSPA would formally increase security around designated operators’ software supply chains. Under this act, companies who operate critical cyber systems would need to immediately take “reasonable action” as soon as any threat or risk related to their third-party suppliers is discovered—including actions prescribed by regulators.

3. The government will compel companies to take security actions

This act wouldn’t simply change the status quo regarding responses to third-party vulnerabilities—it would also give Governors in Council the authority to direct any single designated operator (or class of designated operators) to take new cybersecurity measures. This may be in response to a known threat, or it may be preemptive.

How to prepare for C-26

If you operate in a vital class designated by C-26, or if you plan to sell software services to organizations that will become designated operators under C-26, it would be wise to start preparing for the CCSPA now. (And even if you don’t sell into these industries, keeping your systems secure is both smart and responsible.)

Talk (and listen) to the regulators

Specific requirements will be determined by regulating authorities, and discussions have already begun. Talk to the regulators who oversee the designated class you do business in—this will be your best source of information.

This is also your chance to bring ideas and concerns to regulators. The rules will depend on how diligent and well-informed the regulators of each sector are when the bill goes into effect—so if there are security measures you’ve found particularly effective, there are threats and vulnerabilities you find especially concerning, or there are proposed cybersecurity measures that could negatively impact other aspects of your business, now is a good time to make those known.

Future designated operators: begin analyzing your vendors’ software.

If you do business in one of the classes C-26 designated, you will need to take reasonable steps to protect your software supply chain from threats. A wise place to start is by asking your vendors for their software bills of materials (SBOMs). This will give you a full view of what code libraries your vendors used to make the software your critical cyber systems rely on.

Beyond obtaining your vendors’ SBOMs, now is a good time to analyze your vendors for vulnerabilities. You can do this easily with a software composition analysis tool like MergeBase, which allows you to analyze other organizations’ code for vulnerabilities, even if you don’t have direct access to that code.

Vendors to future designated operators: prepare your supply chain security documentation.

In order to continue doing business with designated operators, your software supply chain must be compliant with regulatory standards. You can expect your designated-operator clients to begin asking you for your software bill of materials.

This applies to you even if you’re not a Canadian company.

Therefore, you can take three actions to prepare for this bill to go into effect:

  1. Assemble your software bill of materials. Compile a list of any third-party code you are using in your product, as well as any other third parties who have access to the code you sell.
  2. Ask your suppliers for their software bill of materials. This will help you get a comprehensive view of all the contributors to your final product.
  3. Analyze your entire supply chain for vulnerabilities. You can use an advanced software composition analysis tool like MergeBase to find and patch vulnerabilities in your own code as well as your suppliers’ code—and their suppliers’ code too.

Having your house in order will put you in the most prepared position when (or if) the CCSPA goes into effect.

All software companies: expect trickle-up cybersecurity standards to increase.

Even if you don’t do business with a designated operator, there’s a chance that one of your customers or partners does. If this is the case, it’s possible that they will pass their new cybersecurity standards on to their suppliers and partners.

Now is a good time to check if you’re part of a future designated operator’s supply chain. If you are, consider preparing your own SBOM. At the very least, make a plan for what to do if one of your customers or partners begins raising cybersecurity standards for you.

Pro-tip: You can use MergeBase to generate your own SBOM or the SBOM of any other software. Our customers tell us that our reports are more thorough and accurate than most in-house SBOMs—book a demo if you’d like to see how it works!

Mitigate third-party and supply chain risks with a software composition analysis (SCA) platform

Cybersecurity measures will only increase in the future. One way to prepare for legislation like the CCSPA is to implement our advanced SCA platform

MergeBase allows you to analyze code for vulnerabilities as it’s being written, and it lets you check for third-party vulnerabilities in both your test environment and your live product. It also gives you the opportunity to automatically patch vulnerabilities in your software supply chain, which keeps you, your customers, and your users more safe from cyber-attacks than they otherwise would be.

If you want to raise your own cybersecurity standards ahead of C-26, schedule a MergeBase demo today. Our team will show you how you can begin protecting yourself from supply-chain risks now.

Scanning Ant-Based Java Projects For Know Vulnerabilities


Ant was Java’s original build system. Ant was developed internally at Sun Microsystems around 2000 to help build the original Tomcat JSP server. I vaguely recall learning many years ago that James Duncan Davidson and Jason Hunter (now of JDOM fame) were the main culprits behind Ant. Of course, we’re now in 2022, and Ant has long since been replaced with Maven. But from 2000 to 2010, Ant was very popular. Even today, many projects, especially internal corporate Java projects, still use Ant. Why fix something when it’s not broken, right? Unfortunately, important application security tools for SBOM generation and known-vulnerability scanning currently don’t work with Ant. But MergeBase does!

Scanning Ant-Based Java Projects With MergeBase

Unlike Maven, Ant does not include any built-in dependency resolving and downloading.  With Ant-based projects, developers are their own when it comes to specifying and retrieving important re-usable libraries required to build and deploy their software systems. Because it’s up to developers, there’s a huge mishmash of approaches and traditions across the Ant universe – it’s a total free-for-all! (Maven was designed from the ground-up mainly to solve this pain and chaos).  Nonetheless, there is one constant we can count on:  when Ant is finished building a software system, the end-result will be a deployable runnable Java software artifact, including all of its required libraries.  MergeBase leverages this fact to achieve a reliable “post-build” known-vulnerability SCA scanning solution for Ant projects.

MergeBase uses a powerful signature-based matching algorithm to accurately identify Java dependencies. Unlike binary fingerprints (like SHA-2 or MD5), our matching algorithm is stable in the face of typical library permutations (e.g., cryptographically signed vs. unsigned libraries, compiler variations, and even different timestamps in zip-file metadata). Our matching algorithm is also able to find versions “between” versions – for example if your developer decided to grab a pre-release version of Apache Commons HttpClient 3.0 directly from “trunk” and threw that into your Ant lib directory, MergeBase’s library-identification logic can handle that.

Scanning Ant-Based Java Projects With MergeBase

Competing Scanners vs. Ant

Most competing scanners are not able to scan Ant-based Java projects. They exit with error messages like these:

  • “Could not detect supported target files”
  • “Detected supported file(s) in ‘.’, but there was a problem generating a dep-graph.”
  • “No dependencies were identified”

This is because existing commercial scanners probe projects build scripts for dependency coordinates. Of course, MergeBase is happy to operate in this mode as well when it’s available, but we also offer a pure “files-on-disk” mode of scanning. Philosophically, we believe a “files-on-disk” scan mode is critical because that gives you the ground-truth: the actual libraries included in your application’s deployment! Of course, your Maven pom.xml scripts and NPM project.json files and yarn.lock files say useful, interesting things about your system’s dependency graphs, but there’s nothing stopping post-build processes from further adjusting the deployment context by deleting, transforming, copying, or even downloading additional dependencies outside of normal build processes.

Turns out our “files-on-disk” philosophy is also perfect for Ant-based Java projects. When an Ant-based application is finished building, all of its dependencies will be packaged up for deployment. A powerful signature-based scanner like MergeBase can then figure out exactly which Maven-coordinates correspond to each of these files.

Of course, Ant projects don’t use Maven-coordinates, but the industry has now standardised around these (e.g., see: PURLs). Known-vulnerability reports and SBOM exports are expected to refer to Maven-Central dependency coordinates. Fortunately, MergeBase is able to accurately map the random Jar files sitting across various “lib/” directories in an Ant-based Java project back to Maven-coordinates. Thanks to these Maven-coordinates, MergeBase can then determine the known-vulnerabilities in your libraries that you need to be aware of, as well as giving you any SBOM reports (in CycloneDX or SPDX formats) you might also need to comply with current software engineering standards.

Using MergeBase To Scan Ant Projects

In this section, we’ll show you explicitly how you can use MergeBase to scan Ant-based Java projects.

First, make sure your Ant project successfully builds! Once your Ant build completes, you can now run MergeBase. When scanning Ant projects, we recommend using MergeBase’s “–binary” and “–all” flags. This way, even zips inside zips and jars inside wars will be examined.

MergeBase Scan Example:

$ java -jar mergebase.jar --name=myProject --group=myGroup --binary –all <project-dir>

Running recursive binary scan. This could take some time especially if *.dll/*.exe files are detected.
Scanning - completed
Saving application profile (1 kb) to

Vulnerable Files Overview

CVE-2016-1000343, CVE-2016-1000342, 2 more...!/bcprov-ext-jdk15on-151.jar (org.bouncycastle/bcprov-ext-jdk15on@1.51)
CVE-2022-23307, CVE-2022-23305, 4 more...!/log4j-1.2.13.jar (log4j/log4j@1.2.13)

CVE-2020-26939, CVE-2020-15522, 7 more...!/bcprov-ext-jdk15on-151.jar (org.bouncycastle/bcprov-ext-jdk15on@1.51)
CVE-2020-13956, CVE-2012-6153, CVE-2012-5783!/commons-httpclient-3.0.jar (commons-httpclient/commons-httpclient@3.0)
CVE-2020-15250!/junit4-4.11.jar (junit/junit@4.11)
CVE-2020-9488!/log4j-1.2.13.jar (log4j/log4j@1.2.13)

Creating an SBOM Report

Simply add the “–sbom” flag to the “java -jar mergebase.jar” command above. Alternatively, you can also download the SBOM report directly from your MergeBase dashboard. All MergeBase scans are also stored in your MergeBase dashboard to help keep you up-to-date in case any new vulnerabilities are discovered in between scans.

Creating an SBOM Report

A Quick Scanner Bake-Off

We have put together a small buildable Ant-based Java project for anyone who would like to play with competing scanners. You can download this project here. It’s an old Apache-2.0 licensed Java open-source project I created in 2006!

To build it, run the following steps:

1. Download it and unzip it.
2. cd ./not-yet-commons-ssl-0.3.17
3. ant clean
4. ant all

Scanning It With MergeBase:

Take a free MergeBase trial, and then download the “mergebase.jar” CLT. Run the following command in the “./not-yet-commons-ssl-0.3.17/” directory (after building it first!):

$ java -jar mergebase.jar –binary –all .

The resulting output is the same as above (24 vulnerabilities found circa September 2022). Of course, that will change as more vulnerabilities are discovered with each passing year!

Snyk?  “There was a problem”

Snyk does not appear able to scan this project:

$ snyk test --scan-all-unmanaged .

Failed to get maven dependency for './not-yet-commons-ssl-0.3.17.jar'. No package found querying '' for sha1 hash '4858e51d5290a3640f706ed0c7db8eda5c646899'.
Detected supported file(s) in '.', but there was a problem generating a dep-graph. No Maven artifacts found when searching

Mend (a.k.a. WhiteSource)?  “No dependencies were identified”

Mend also does not seem to be able to scan this:

$ ws scan –extended .

File system scan is not allowed, only package manager dependencies resolution is performed
Scanning: /opt/automated-benchmark/ssl/not-yet-commons-ssl-0.3.17 [...../]
Retrieving: Security vulnerabilities and compliance information [...../]
No dependencies were identified


Many important Java systems are still built using Ant, but unfortunately, most application security tools are not able to understand and scan such systems.  MergeBase, however, uses a powerful signature-matching algorithm that works wonderfully well with Ant-based Java projects!

p.s.  We published our matching algorithm in a peer-reviewed software engineering journal in 2013 if you would like to implement it yourself (it is not patent protected). Look for “Software Bertillonage, Determining the provenance of software development artifacts” by Davies et al. in Springer’s Journal of Empirical Software Engineering, 2013.  As an author, I’m allowed to send free full-text copies of this journal article to anyone who would like to see it. You can email me at:

p.p.s. Speaking of provenance, I bet you didn’t know Davies was my maiden name!  😉 

The Executive’s Guide to Third-party Liability in Cyber Security Law

As cybercrime becomes more sophisticated, governments have begun introducing initiatives to hold regulated industries accountable for their data security. This includes initiatives involving third-party liability, where software companies are held responsible for vulnerabilities that come from external sources.

This is an important issue for both software providers and regulated companies using third-party software. Here, you’ll get an overview of what third-party liability is, why it matters, and what you can do to prepare for third-party liability laws.

What is third-party liability in software?

Third-party liability refers to a company’s responsibility to keep their data, and their users’ data secure from any vulnerabilities—including vulnerabilities introduced by code from third parties. 

Most software companies incorporate libraries from third-party sources in their offerings. If one of these third-party libraries becomes vulnerable to cybersecurity threats at any time, the company is still liable for any breaches of their own data.

Key terms to know when discussing third-party liability

If your company is discussing cybersecurity, odds are good that third-party liability will come up. The following terms are often used in conversations about this matter:

Third-party vulnerabilities: these are the specific vulnerabilities introduced by third-party code. 

Software supply chain: this refers to all the elements that go into creating and delivering your software product. This can include hardware, open- and closed-source code, operating systems, consultants, and testing tools. It’s everything that touches your application as it’s being made, and everything that touches those things, and everything that touches those things, and so on.

Software bill of materials (SBOM): this refers to the full list of libraries that make up a software system, including code from vendors and open-source libraries. This terminology is more often used in discussions of cyber security policy and legislation. 

The regulatory gap: how third-party liability became so important

Third-party liability became an important issue due to the extreme regulatory gap between software companies and industries that play an established, essential role in societies’ infrastructure. 

The world came to rely on (unregulated) tech companies

In the 1990s, industries like finance, transportation, energy, and healthcare had already cemented themselves into the infrastructure of society. These industries were vital to the average citizen’s daily life as well as economies as a whole; therefore, governing bodies heavily regulated them. 

This regulation prevented any one regulated company from growing to the point of global scale. (For example, there is no worldwide consumer bank.) This meant that innovations happened on a smaller scale, and regulators were, for the most part, able to keep in step with those innovations.

However, the internet and ubiquitous use of personal computers (and later smartphones and other smart devices) led to increasing global demand for software services. When the tech industry began, software applications were not regulated. Tech companies multiplied and innovated, and the capabilities of software increased exponentially.

In a matter of decades, software applications have become a crucial part of everyday life worldwide. Consumers relied on large tech companies for commerce, navigation, and communication—but so did small and mid-size businesses, enterprise corporations, and even government entities.

Innovation relied on third-party code

As software capabilities expanded, more and more tech companies began building applications on code libraries written by outside sources. This was essential to economic survival. In order to innovate efficiently and competitively, tech companies couldn’t start from scratch. Today, most commercial software applications are built on a mix of proprietary in-house code and third-party libraries—much of which is open-source.

These third-party providers were also unregulated. An ecommerce marketplace in Spain could license a transaction processing system from a US fintech startup, which might include code libraries produced by companies in Mexico, Norway, Singapore, and Germany—or even open-source code with no single identifiable author. (And each contributing company could have built their code on even more third-party libraries.) 

Since none of these companies were regulated, any cyber security standards were either set by the buyers or self-imposed.

This became especially problematic when highly regulated corporations and government entities began using unregulated applications.

Third-party code became an easy target for cybercriminals

A system is only as secure as its weakest component. Breaching an enterprise application is difficult, and malevolent hackers soon realized that it was much easier to breach a large entity’s data by simply targeting code produced by smaller players. Hacking a third-party software supplier created a “back door” to the supplier’s customers, clients, and partners.

[Source: Usenix]

This was a known issue in the software community for a long time, but in 2021, it became a matter of national security in the United States.

In 2020, presumed Russian hackers gained access to an IT monitoring system created by SolarWinds. SolarWinds was a third-party supplier to large companies, including Microsoft, Cisco, and Intel, as well as US federal departments, including Homeland Security, State, and Treasury. Through SolarWinds, the hackers gained access to more than 18,000 organizations’ data—and the breach wasn’t discovered until the spring of 2021.

This was not an isolated incident. Third-party software supply chain attacks have been increasing exponentially in the past few years—and it’s leading governments to make laws regarding third-party liability.

Third-party liability in cyber security law

Because of the growing threat of third-party attacks, governments have begun forming policies to hold companies accountable for the security of their applications—including the security of their third-party suppliers.

Third-party liability policy can be thought of as a spectrum across two general approaches, the prescriptive approach and the principled approach.

The prescriptive approach: focus on the rules

Governments taking a prescriptive approach to software supply chain security (like the United States) set compliance standards for key industries. Regulated companies and government entities are required to hold all vendors to a known set of security standards. Procedures are likewise set in place for when these standards are breached.

The advantage of this approach is that both regulated customers and their vendors know if they are compliant and what to do if suddenly they’re not (i.e., they’ve been hacked). This makes it easier for vendors to become compliant and easier for customers to determine which vendors are eligible for consideration.

However, this approach has a major disadvantage: reality moves faster than regulations. The measures a government prescribes can become obsolete, and changing regulatory standards takes time. This lag effect can burden industries with (expensive) outdated compliance standards that don’t actually protect them from threats. 

The principled approach: focus on the results

Governments taking a principled approach (like Germany) instead leave compliance standards up to the software companies—but penalize them heavily for any breaches. Regulated companies and government agencies are held to the standard of perfection: if you’re hacked, it’s because you weren’t secure enough.

The disadvantage with this approach is that there is no clear-cut compliance standard (aside from being unbreachable). This makes it more difficult for regulated customers to source innovative vendors. Likewise, vendors lack clear security standards to meet in order to know if they are eligible, let alone a competitive solution.

On the other hand, this approach has the advantage of incentivising both third-party vendors and regulated entities to innovate at the speed of malevolent hackers. By raising the stakes of failure, principled policies encourage regulated entities to make absolutely sure that their suppliers and their suppliers’ suppliers are secure.

How to prepare for third-party liability laws

As governments begin exploring cyber security policies, software vendors and regulated clients need to invest in tools and practices that will keep them compliant. And even if you’re not operating in a regulated space, protecting yourself (and your users, customers, and partners) from third-party vulnerabilities is a smart idea.

How to prepare as a vendor

If you create software, you need to ensure that both your own code and your third-party code are vulnerability-free. You can do this with a software composition analysis (SCA) solution like MergeBase. An SCA solution analyzes every library that touches your final product and alerts you of any vulnerabilities.

In addition, you should begin the practice of preparing your software bill of materials for every contract. Future contracts in regulated spaces will depend on your ability to provide up-to-date information about where your code comes from, so it’s wise to begin preparing for this now.

How to prepare as a regulated client

If you are in a regulated industry, third-party liability laws will put the onus on you to ensure that your vendors are using proper data security. In order to protect yourself and your stakeholders, you will need to do two things:

  1. Obtain a software bill of materials from every vendor. You need to know exactly what code is being used for each contract. This is not always easy to do. Your vendors may not have a one-size-fits-all SBOM for every contract—and they may not have internally prepared their SBOMs for external viewing.
  2. Analyze every vendor’s SBOM. In addition to obtaining the vendors’ SBOMs, you need to analyze them for vulnerabilities yourself. (This is especially key if you are operating under laws that take the principled approach discussed earlier.) 

Both of these can be very difficult to do because they involve inspecting another organization’s code. This is why using an advanced SCA suite like MergeBase is a good idea. MergeBase allows you to analyze anyone’s SBOM for vulnerabilities, even if you do not have direct access to their code. (You can even use MergeBase to verify the SBOMs your vendors give you—we have a reputation for generating SBOMs that are even more thorough and accurate than those a vendor creates in-house.)

It’s a reliable way to know exactly how secure a vendor is.

Don’t let third-party liability catch you off guard

Third-party liability laws are coming, and whether you’re a software producer or customer, the best thing to do now is prepared. MergeBase gives you the ability to find vulnerabilities in your own code as well as code from suppliers and vendors—which helps protect you from third-party liabilities.

If you want to prepare for third-party liability laws, we would love to show you how MergeBase can help. Book a demo with us today and see how you can protect yourself, your code, and your customers.

How To Avoid Catastrophic Cryptographic Failures In Your Apps

Danger, Cryptography Ahead!

The latest OWASP Top 10 ranks “Cryptographic Failures” as the 2nd worst security problem currently facing software engineers today. In this webinar AppSec experts Jim Manico (OWASP Top Ten contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will discuss why this is the case and offer the best practices and resources for developers trying to avoid such failures in their own systems.

As the very recent (and very serious) CVE-2022-21449 shows – this problem never goes away! It’s hard for software practitioners to stay up-to-date because new critical cryptographic weaknesses and configuration disasters are discovered and disseminated every year, and seemingly tiny benign mistakes can be game over.

Answers to the following questions are critical in avoiding cyber failure:

  • Should you use Argon2 or bcrypt?
  • When should you salt things?
  • What parameters should you feed into your TLS endpoints?
  • Anything to be careful about with JWT?

Watch the video of our webinar on How To Avoid Cryptographic Failures from June 3rd, 2022

Want to know more?

OWASP ASVS: your balanced appsec diet

Build strength, fitness and peace of mind!

In this webinar, application security heavyweights Jim Manico (OWASP Top Ten contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will talk about the best thing that can happen to you if your application security team is overwhelmed, overworked and over-worried.

What you will learn in this section:

Are you thinking of establishing a balanced appsec process, or are you looking at fine-tuning your existing process?

  • The first application security standard by developers for developers!
  • That defines three risk levels with 200+ controls.
  • And gives you a similar value to ISO 27034 for a fraction of the hassle.


The OWASP Application Security Verification Standard (ASVS) is a balanced way for organizations to approach application security and align it with their organization’s risk appetite and resources.

ASVS is a set of best practices that can be used by any organization, large or small, to assess the security of their applications. It takes a proactive, risk-based approach to secure applications and is designed to be flexible enough for you to customize it for your specific needs.

It captures the totality of global APPSEC knowledge for securing web applications and web APIs.

Current Version: 4.0.3 

How can a company best implement ASVS?

It depends on what they are doing, so if the company is building an application, if they’re building software in-house, then the best place to start is to make sure that they’re using it as requirements right. So if you’re on your journey, even if you’re part way through your journey or all the way there, if you’re building software and you’re like, “hey, what are my security requirements?” and usually everyone looks at each other in the team, and they throw their hands up.

It has been seen in some situations that they’re like: “well, we have no idea what the security requirements are,” or at best, they’ll be very high level while “we need to comply with sock too.” So, the best place to start is to take ASVS and say there are my security requirements. Define which level is appropriate for your company, take this as a requirement, and test it internally.

Summing up, start with the requirements and prepare for being tested.

Check the list the requirements on GitHub.

Did you like this webinar? Don’t miss the next ones! Secure your spot today!

I was asked: Are your application secure?

How paranoid about application security is enough?

I was asked to secure my company’s software application at a previous job. I dutifully headed off to do some online research. Five hours of googling later, I realized that the concept of an “application secure” was in fact, ephemeral. A growing unease started to grow inside me. Is anything, anywhere safe?

Am I the only one that feels this way? Am I going crazy? I dig even deeper down the rabbit hole. Apparently, psychology has been studying this phenomenon for the past few decades, and while a small corner of my mind feels relieved to find out that I am not alone, another louder part of my mind worries about the fact that psychology is looking at it… is it really that prevalent? 

One quote in a Frontiers paper sticks in my craw: “On balance, the weight of the evidence points to an excessive level of fear regarding information technology within society, in that the level of fear seems to be out of proportion to the actual risks.” This can’t be true, every month brings out reports of more vulnerabilities, more data breaches, more people getting defrauded, of more people getting their identities stolen.

Not so confident of academia’s understanding of the ‘real’ world, I do a quick Google search using the words “security” &  “paranoia”. Immediately I find my feelings echoed on Reddit with the following post*: “So is it just me or the more you learn about cyber security, the more paranoid you are about every little action you do?” The answer provided does not make me feel better: “You learn how to accept risk. The only completely secure computer is powered off at the bottom of a line shaft broken into inoperable pieces.”

So, which is it? Are my “fears out of proportion”, or is security only achievable at the bottom of an abandoned mining shaft?

Is anything, anywhere safe?

Only a small portion of a single course (of 40 total!) from my Computer Science degree actually addressed security in a formal way. It was in this course, Computer Networking, where I met Alice & Bob innocently trying to communicate unaware of the villainous Charlie sneaking around in the middle hacking into their messages. 

There I learned how to use WireShark and started sniffing packets at the local coffee shop. This sharpened my desire to pay attention in class and I diligently studied the “known knowns” of the industry, cognitively arming myself to move around with more environmental awareness in the digital space. 

I started checking for security vulnerabilities on my own sensitive applications with 2FA (2-factor authentication) and preach this as the way to all I know because it is surely infallible. Right? Wrong. 

I read that the 2FA SMS and OTP implementations such as Google Authenticator are often breached* by middling Charlie, and my security blanket once again becomes damp. (FIDO implementations such as Yubikeys are not vulnerable to this).

My research reveals that it is impossible to really anticipate all of the attack vectors, all of the potentially penetrable planes of any process. The monitoring systems that I had once trusted to keep my company’s system safe all of a sudden become the opposite of that*. Facebook Careers can be hacked using Word documents*.  Even harmless wee CSS becomes an affordance upon which one can inject malicious js scripts*.

What really feeds my anxiety beast, though, is the fact that there are still so many dangers lurking in the shadows that I haven’t even conceived of yet. The SolarWinds attack was so effective because internal build processes behind firewalls were presumed safe. Very few ever imagined CSS could be a target either. 

As a digital nomad, it reminds me of when I land in a new city, when I am still unaware of the “bad” areas, of its particular flavour of crime. Are pickpockets rampant here; are the kebabs actually chicken? I remember that time a random woman threw a cat at me, and how her kid ran off with my bag as I was shaking it off. I had never really anticipated getting ripped off in that particular way; had never conceived of it being something to be careful of.

What gave me hope, the only spark of light in all of this darkness was the fact that my boss had decided to take security seriously. She had convinced the money people that even though the process of securing a system can be both time & money-consuming in the short run, it ends up being both time & cost-reducing in the long run. She explained how with practice we could learn to anticipate obvious attacks and with creativity, we could start anticipating some not-so-obvious attacks.

What did I do after I embraced my paranoia and decided to build secure applications?

I came across Jack Rhysider’s list of 20 things he learned as a network security engineer. Reading it I see a pattern of measured precautions, little building blocks to feel prepared, to involve a team, to stay on top of matters without panicking. 

I learn that I am not alone in my world of AppSec worries and that this space is rich with interesting, knowledgeable, and appropriately paranoid people. Spend any time trawling through Reddit, lurking within Twitter, and you will find people who are already on the ground running.

Poking my head out of the rabbit hole, I decide once and for all to embrace my paranoia, to make it work for me. I figure that the only way to win this battle, to create a proper offensive, is to think about it as much as attackers do and that my (un-panicked) paranoia will help me do exactly that.

Want to keep your application secure?

Start a free trial today and find out what we can do to help you to assuage your paranoia.

How to Instantly Secure Log4j

The log4j vulnerability was announced on December 10, 2021, and ranks as one of the worst in history. How to secure log4j? The best resolution is to upgrade to a secure version. However, sometimes that is not possible, or at least it takes time. In these scenarios, runtime protection for log4j or other vulnerabilities can be a lifesaver.

In organizations that have hundreds or thousands of applications, it can take days or even weeks of an all-out effort to upgrade these applications. Or it could be that the vulnerable applications are supplied by a vendor, and the vendor does not have a fix immediately available. The runtime protection can be applied with a few clicks of a mouse and save you a lot of time. This video below walks you through how that works.

How to secure log4j instantly at runtime?

In this video, Julius Musseau and Delan Elliott show how:

  • How to access a vulnerable library can be controlled
  • Either for the full library or surgically for just the method(s) that is at the root of the vulnerability.
  • This enables the organization to respond instantly to new vulnerabilities.
  • It applies to vulnerabilities such as CVE-2021-44228, and CVE-2021-45046
  • But can be applied to any Java-based vulnerability.

If you are looking to secure log4j or other libraries, contact us, or try out MergeBase for free.

Critical Java Log4j Vulnerability

What can go wrong with a tool that just logs messages to a text-based file? Nothing right? Suddenly on December 11, 2021, we were all exposed to the log4j vulnerability, and your organization could have been (might have been?) breached!

A quick definition of what Log4j is

The software industry has become increasingly reliant on reusable code—software libraries—to reduce development time and cost. Log4j is a widely used library written in Java under the Apache Software License. It provides developers with an effective way to track and monitor the activity of their applications and services. Its use helps ensure reliable, user-friendly software.

Log4j Vulnerability Explained

Log4j is an extremely popular and heavily used open-source Java library that can be used for unauthenticated remote code execution, making CVE-2021-44228 and CVE-2021-45046 critical vulnerabilities that you must pay attention to.

In other words: if your software uses this library, then there is a good chance that anyone can gain full remote control of your servers and data.

The log4j vulnerability is among the worst we’ve seen in the last 5 years, in part because the vulnerability itself is so severe and so easy to trigger. It allows anyone with access to the network or internet to gain unauthorized access to data. Adding to the severity, this vulnerable library is among the most popular and widely deployed open-source Java libraries on the planet.

Differences between log4j vulnerability versions?

The Apache Struts disaster from 2017 (CVE-2017-5638) was a large part of why we launched our startup ( to help companies protect themselves from known vulnerabilities in open source libraries exactly like these.

This time it’s even worse. This particular vulnerability is especially dangerous because it can be exploited remotely without the need for authentication. This means that attackers can easily target systems that are using vulnerable versions of log4j and can potentially gain full control over them.

Globally, everyone must now urgently scramble to upgrade all applicable software to use Java library log4j version at least 2.15.0 (which was published today). Companies that, for whatever reason, fail to execute this upgrade will likely be attacked and exploited within the next few days – assuming they are not already under attack.

We cannot stress how urgent it is for administrators of Java systems to succeed in rolling out this upgrade. Patch this Critical log4j vulnerability in Java CVE-2021-44228 immediately.

How can you check for vulnerabilities?

There is an easy way to check any server for the log4j vulnerability. At the root of your file system, using an administrator account, download and run our free Log4J-Detector tool:

This command can take several hours to complete. Any occurrence of “_VULNERABLE_” in this command’s output indicates with a high probability that you are vulnerable to this severe software exploit.

monitoring - Log4j vulnerability

Further reading:

  • The Cybersecurity and Infrastructure Security Agency has issued a guide that gives assistance in scanning internet-facing assets and prioritizing patching. The guide also makes suggestions for monitoring for unusual traffic that could be an indication of attempted exploitation of the Log4j vulnerability.

Still interested in learning more about it?

Check the video on securing log4j instantly with runtime protection.

MergeBase can help you patch your vulnerable systems to eliminate this bug and help you in situations where patching is not possible. We have a patented cyber security technique for exactly this situation. Learn more about our Runtime Protection feature. 

Do not waste time! Secure your apps with MergeBase. You can try the MergeBase SCA tool to check if you are vulnerable or even download our free tool to detect vulnerable log4j versions on any of your machines and in any application.

Ubuntu Docker Container Scanning – Is it enough to protect your app?

In this post, we are going to look at Docker container scanning:

  1. First, we will build an Ubuntu Docker container, add some software to it, run a Docker scan, and record the vulnerabilities.
  2. Then, we will try to resolve some of those vulnerabilities, run another scan, and examine the results.
  3. Finally, we will determine whether container scanning is enough to protect your applications and data from compromise. 

Building the Docker Container

We will build our Ubuntu Docker container using the Ubuntu Xenial image. Since it is a few versions behind, it will hopefully contain a few vulnerabilities. We are also going to install Python, PIP3, and a vulnerable version of urllib3. If we search the CVE database, we find CVE-2021-28363. According to this CVE, the urllib3 library 1.26.x before 1.26.4 omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies.

The first step in our process is to pull the Ubuntu Xenial Docker image from Docker Hub and run it as a container on our Docker host. The command below will get the image, start the container in interactive mode, and name it ubuntu_xenial. 

docker run -it –name ubuntu_xenial ubuntu:xenial

Once the process completes, you will be presented with the Ubuntu prompt, as shown in the text output below.

PS C:\Users\docker> docker run -it --name ubuntu_xenial ubuntu:xenial

Unable to find image 'ubuntu:xenial' locally

xenial: Pulling from library/ubuntu

80bce60046fa: Pull complete

55a738a15540: Pull complete

e19cf0706c62: Pull complete

de4cdd6c27d1: Pull complete

Digest: sha256:9775877f420d453ef790e6832d77630a49b32a92b7bedf330adf4d8669f6600e

Status: Downloaded newer image for ubuntu:xenial


The next step is to install Python and PIP by running the following command:

apt update && apt install python3-pip

root@a317929cf5d7:/# apt update && apt install python3-pip

Get:1 xenial InRelease [247 kB]

Get:2 xenial-security InRelease [109 kB]

Get:3 xenial-updates InRelease [109 kB]

Get:4 xenial-security/main amd64 Packages [2051 kB]
Fetched 19.4 MB in 42s (458 kB/s)

Reading package lists... Done

Building dependency tree

Reading state information... Done

5 packages can be upgraded. Run 'apt list --upgradable' to see them.

Reading package lists... Done

Building dependency tree

Reading state information... Done
The following packages will be upgraded:


1 upgraded, 85 newly installed, 0 to remove and 4 not upgraded.

Need to get 98.7 MB of archives.

After this operation, 289 MB of additional disk space will be used.

Do you want to continue? [Y/n]


After installing Python and PIP, we are ready to install urllib3. However, since the development team fixed the vulnerability in version 1.26.4, we need to install an earlier vulnerable version. For the purposes of this exercise, let’s install version 1.26.0 from requirements.txt. 

We can check that our requirements.txt file includes our vulnerable version by running the cat command.

root@a317929cf5d7:/# cat requirements.txt


We can use PIP to install the  requirements.txt file.

pip3 install -r requirements.txt

root@a317929cf5d7:/# pip3 -r requirements.txt

Collecting urllib3==1.26.0

  Downloading (136kB)

    100% |################################| 143kB 3.9MB/s

Installing collected packages: urllib3

Successfully installed urllib3-1.26.0

You are using pip version 8.1.1, however version 21.1.2 is available.

You should consider upgrading via the 'pip install --upgrade pip' command.

root@a317929cf5d7:/urllib3_test# pip3 freeze requirements.txt


You are using pip version 8.1.1, however version 21.1.2 is available.

You should consider upgrading via the 'pip install --upgrade pip' command.

Now that we have updated our container, it is time to commit it and create our image by running the following Docker command from the docker host.

docker commit ubuntu_xenial

PS C:\Users\docker> docker commit ubuntu_xenial


Let’s check that Docker created the image by running the docker images command.

docker images

As we can see in the text output below, Docker created the image. 

PS C:\Users\docker> docker images


<none>      <none>    130de6a9e382   About a minute ago   465MB

ubuntu       xenial   9ff95a467e45   12 days ago          135MB

However, to make our lives easier, let’s give the new image a tag to identify it by running the following command.

docker tag 130de6a9e382 our_ubuntu_image

If we rerun the docker images command, we can see that Docker updated the information.

PS C:\Users\docker> docker tag 130de6a9e382 our_ubuntu_image

PS C:\Users\docker> docker images

REPOSITORY         TAG       IMAGE ID       CREATED        SIZE

our_ubuntu_image  latest   130de6a9e382   3 minutes ago   465MB

ubuntu             xenial    9ff95a467e45   12 days ago     135MB

As Docker’s scanning feature only works on images and not containers, we are now ready to scan the image for any vulnerabilities. Let’s start the Docker container scanning by running the following command.

docker scan our_ubuntu_image

PS C:\Users\docker> docker scan our_ubuntu_image

Docker Scan relies upon access to Snyk, a third party provider, do you consent to proceed using Snyk? (y/N)docker y

/ Analyzing container dependencies for our_ubuntu_image

/ Querying vulnerabilities database...

Once the scan completes, the final report indicates 193 issues, as shown in the text output below.

Package manager:  deb

Project name:     docker-image|our_ubuntu_image

Docker image:     our_ubuntu_image

Platform:         linux/amd64

Licenses:        enabled

Tested 185 dependencies for known issues, found 193 issues.

Docker Container Scanning Results

If we study the vulnerability report, we find that Docker container scanning highlights some vulnerabilities that can be fixed, as shown in the text output below.

✗  Low severity vulnerability found in glibc/libc-bin

  Description: Improper Data Handling


  Introduced through: glibc/libc-bin@2.23-0ubuntu11.2, meta-common-packages@meta

  From: glibc/libc-bin@2.23-0ubuntu11.2

  From: meta-common-packages@meta > glibc/multiarch-support@2.23-0ubuntu11.2

  Fixed in: 2.23-0ubuntu11.3

✗ Low severity vulnerability found in glibc/libc-bin

  Description: Integer Underflow


  Introduced through: glibc/libc-bin@2.23-0ubuntu11.2, meta-common-packages@meta

  From: glibc/libc-bin@2.23-0ubuntu11.2

  From: meta-common-packages@meta > glibc/multiarch-support@2.23-0ubuntu11.2

  Fixed in: 2.23-0ubuntu11.3

If we look at the message for the two vulnerabilities in the image, we need to update those particular packages to resolve the issue. First, we need to create a container from the new image to make sure we are working with the latest version. As we did previously, we need to execute the docker run command as shown in the image below.

docker run -it –name our_ubuntu_image our_ubuntu_image

PS C:\Users\docker> docker run -it --name our_ubuntu_image our_ubuntu_image


After executing the docker run command, we can run the following commands to update Ubuntu from the container’s command line.

apt update && apt upgrade

root@0dfcbff2e3d1:/# apt update && apt upgrade

Hit:1 xenial-security InRelease

Hit:2 xenial InRelease

Hit:3 xenial-updates InRelease

Hit:4 xenial-backports InRelease

Reading package lists... Done

Building dependency tree

Reading state information... Done

4 packages can be upgraded. Run 'apt list --upgradable' to see them.

Reading package lists... Done

Building dependency tree

Reading state information... Done

Calculating upgrade... Done

The following packages will be upgraded:

  apt libapt-pkg5.0 libc-bin multiarch-support

4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Need to get 2458 kB of archives.

After this operation, 70.7 kB of additional disk space will be used.

Do you want to continue? [Y/n]

After running and installing the updates, we need to commit and create another Docker image to save the changes. 

docker commit our_ubuntu_image

PS C:\Users\docker> docker commit our_ubuntu_image


We can check that Docker created the image successfully by running the docker images command.

docker images

As we can see in the text output below, Docker confirms the new updated image exists.

PS C:\Users\docker> docker images

REPOSITORY         TAG       IMAGE ID       CREATED          SIZE

<none>             <none>    bf5809ae94d9   2 minutes ago    476MB

our_ubuntu_image   latest    130de6a9e382   19 minutes ago   465MB

ubuntu             xenial    9ff95a467e45   12 days ago      135MB

As we did before, let’s give the new image a tag to identify it by running the following command.

docker tag bf5809ae94d9 updated_ubuntu_image

If we rerun the docker images command, we can see that Docker updated the information.

PS C:\Users\docker> docker tag bf5809ae94d9 updated_ubuntu_image

PS C:\Users\docker> docker images

REPOSITORY             TAG       IMAGE ID       CREATED          SIZE

updated_ubuntu_image   latest    bf5809ae94d9   3 minutes ago   476MB

our_ubuntu_image       latest    130de6a9e382   21 minutes ago 465MB

ubuntu                 xenial    9ff95a467e45   12 days ago       135MB

We are now ready to scan the updated container to see if our efforts resolved any vulnerabilities. As before, to run docker scan execute the following command. Note that we are now scanning our updated image.

docker scan updated_ubuntu_image

PS C:\Users\docker> docker scan updated_ubuntu_image

/ Analyzing container dependencies for updated_ubuntu_image

/ Querying vulnerabilities database...

Once the scan completes, the final report indicates 191 issues, as shown in the text output below. This result demonstrates that updating our Ubuntu container resolved two vulnerabilities. 

Package manager:    deb

Project name:      docker-image|updated_ubuntu_image

Docker image:      updated_ubuntu_image

Platform:          linux/amd64

Licenses:         enabled

Tested 185 dependencies for known issues, found 191 issues.

However, if we search both the original vulnerability report and the report generated after our updates, neither report contains an alert for CVE-2021-28363. If you recall, when we created our image, we installed a vulnerable version of urllib3. Since neither scan picked up this vulnerability, we need to consider alternatives that mitigate this risk.

MergeBase Vulnerability Analysis and Resolution

To test the validity of Docker scan’s analysis and reporting, let’s run the same scans using MergeBase.

As in the first example, we first need to run a scan on the Docker image named our_ubuntu_image before we run any Ubuntu updates. 

First, we need to get the docker image repository and tag by running the following command:

docker images

As we can see in the text output below, the repository name is ‘our_ubuntu_image,’ and its tag is ‘latest.’


our_ubuntu_image latest 130de6a9e382 18 minutes ago 462MB

ubuntu xenial 9ff95a467e45 3 weeks ago 135MB

Using the MergeBase command-line tool, we can scan this image using the following command:

java -jar mergebase.jar –mode=profile –name=our_ubuntu_image our_ubuntu_image:latest

If we look at the summary scan report on the MergeBase portal, we can see that it found 301 vulnerabilities. This number exceeds the 193 found by Docker scan by 108 vulnerabilities.

Below is the text output from the command-line tool. As you can see, it details multiple CVEs and categorizes them by severity.

java -jar mergebase.jar --mode=profile --name=updated_ubuntu_image updated_ubuntu_image:latest

Saving application profile to

  Vulnerable Files Overview




  CVE-2017-7614, CVE-2017-7226, CVE-2017-6969 (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2017-8283 (dpkg-dev@1.18.4ubuntu1.7.UBUNTU)

  CVE-2017-8283 (dpkg@1.18.4ubuntu1.7.UBUNTU)

  CVE-2019-18218 (file@5.25-2ubuntu1.4.UBUNTU)

  CVE-2008-1530 (gnupg@1.4.20-1ubuntu3.3.UBUNTU)

  CVE-2016-6309 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  CVE-2017-12814 (perl-base@5.22.1-9ubuntu0.9.UBUNTU)

  CVE-2017-12814 (perl@5.22.1-9ubuntu0.9.UBUNTU)

  CVE-2018-1126 (procps@3.3.10-4ubuntu2.5.UBUNTU)

  CVE-2020-15801, CVE-2017-1000158 (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-15801, CVE-2017-1000158 (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2018-20839, CVE-2018-15688, 2 more... (systemd@229-4ubuntu21.31.UBUNTU)



  CVE-2019-3462 (apt@1.2.35.UBUNTU)

  CVE-2016-7543 (bash@4.3-14ubuntu1.4.UBUNTU)

  CVE-2020-6096 (libc-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2020-6096 (libc-dev-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2019-11922 (libzstd1@1.3.1+dfsg-1~ubuntu0.16.04.1.UBUNTU)

  CVE-2017-17522 (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2017-17522 (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  HIGH (18)


  CVE-2018-6557 (base-files@9.4ubuntu4.13.UBUNTU)

  CVE-2019-18276, CVE-2017-5932, CVE-2016-0634 (bash@4.3-14ubuntu1.4.UBUNTU)

  CVE-2021-3549, CVE-2021-20294, 73 more... (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2015-8865, CVE-2014-9653 (file@5.25-2ubuntu1.4.UBUNTU)

  CVE-2021-3345, CVE-2019-14855, 2 more... (gnupg@1.4.20-1ubuntu3.3.UBUNTU)

  CVE-2018-5733, CVE-2018-5732, CVE-2017-3144 (isc-dhcp-client@4.3.3-5ubuntu12.10.UBUNTU)

  CVE-2021-3326, CVE-2019-9192, 4 more... (libc-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2021-3326, CVE-2019-9192, 4 more... (libc-dev-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2016-6305 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  CVE-2018-6952, CVE-2018-6951, CVE-2018-20969 (patch@2.7.5-1ubuntu0.16.04.2.UBUNTU)

  CVE-2016-2381 (perl@5.22.1-9ubuntu0.9.UBUNTU)

  CVE-2018-1125, CVE-2018-1124, 2 more... (procps@3.3.10-4ubuntu2.5.UBUNTU)

  CVE-2019-20916 (python3-pip@8.1.1-2ubuntu0.6.UBUNTU)

  CVE-2020-26116, CVE-2019-16056, 3 more... (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-26116, CVE-2019-16056, 3 more... (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-1712, CVE-2019-3844, 8 more... (systemd@229-4ubuntu21.31.UBUNTU)

  CVE-2016-6321 (tar@1.28-2.1ubuntu0.2.UBUNTU)

  CVE-2018-7738 (util-linux@2.27.1-6ubuntu3.10.UBUNTU)

  MEDIUM (18)


  CVE-2018-0501, CVE-2016-1252 (apt@1.2.35.UBUNTU)

  CVE-2016-9401 (bash@4.3-14ubuntu1.4.UBUNTU)

  CVE-2021-3487, CVE-2021-20284, 80 more... (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2017-18018 (coreutils@8.25-2ubuntu3~16.04.UBUNTU)

  CVE-2017-1000249, CVE-2014-9621, CVE-2014-9620 (file@5.25-2ubuntu1.4.UBUNTU)

  CVE-2011-2207 (gnupg@1.4.20-1ubuntu3.3.UBUNTU)

  CVE-2019-20795 (iproute2@4.3.0-1ubuntu3.16.04.5.UBUNTU)

  CVE-2020-27618, CVE-2019-7309, 7 more... (libc-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2020-27618, CVE-2019-7309, 7 more... (libc-dev-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2021-24032, CVE-2021-24031 (libzstd1@1.3.1+dfsg-1~ubuntu0.16.04.1.UBUNTU)

  CVE-2018-0739, CVE-2016-6308, CVE-2016-6307 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  CVE-2019-20633, CVE-2016-10713 (patch@2.7.5-1ubuntu0.16.04.2.UBUNTU)

  CVE-2021-3426, CVE-2020-8492, 4 more... (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2021-3426, CVE-2020-8492, 4 more... (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-13776, CVE-2020-13529, 3 more... (systemd@229-4ubuntu21.31.UBUNTU)

  CVE-2021-20193 (tar@1.28-2.1ubuntu0.2.UBUNTU)

  CVE-2016-5011 (util-linux@2.27.1-6ubuntu3.10.UBUNTU)

  CVE-2021-28363 requirements.txt (urllib3@1.26.0)

  LOW (4)


  USN-3156-0002 (apt@1.2.35.UBUNTU)

  CVE-2020-35448 (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2019-1552 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  USN-4120-0002, CVE-2019-20386, 2 more... (systemd@229-4ubuntu21.31.UBUNTU)

Included in the list of vulnerabilities identified by MergeBase is the vulnerable version of urllib3 we installed.

To ensure we are comparing like for like, we should also run the MergeBase scan on the updated image after applying the Ubuntu updates as we did with Docker scan. We can reuse the same MergeBase command line after updating the relevant parameters.

java -jar mergebase.jar –mode=profile –name=updated_ubuntu_image updated_ubuntu_image:latest

Interestingly, the results for the updated Ubuntu image are identical before and after running the updates. 

We can deduct the following outcomes from this exercise:

  1. Docker Scan and MergeBase find different vulnerabilities on the same containers.
  2. MergeBase provides far more detailed results when it comes to the actual software components installed on a container. The text output from the command line tool and the report it generates even details the relevant CVEs. 
  3. The Docker scan results change after running system updates while Mergebase remains the same. This difference indicates that Docker scan focuses more on the operating system while MergeBase concentrates on its specialty, Software Composition Analysis.

Container Scanning Limitations

Our rudimentary experiment shows that default container scanning solutions do not find application-layer vulnerabilities. Consequently, even though these tools provide a critical service that helps you find security issues in your containerized application, they do not offer a complete solution. For example, if we build a Python app and use the vulnerable urllib3 library, our containerized app is not secure. In that instance, a container scan will not show any vulnerabilities, but an attacker could create a rogue certificate authority and compromise your containerized service.

However, this simple illustration is only one example. If we consider that researchers found 18,325 vulnerabilities in 2020 and 7,545 in the first five months of 2021, protecting your containerized application requires multiple layers of security. If you only rely on container scanning solutions, you are not getting the visibility you need for application-layer vulnerabilities, as our urllib3 example demonstrates. What you need is a layered defense-in-depth security approach. 

Defense in Depth for Containerized Applications

While containerized applications offer several benefits, such as application consistency, scalability, and cost-effectiveness, managing all the moving parts that provide the platform running your app can be challenging. Since hosts, images, and containers make up a standard Docker architecture, a vulnerability in any of these three critical components could lead to a security incident. 

For example, should a threat actor manage to compromise an image on Docker Hub, it could lead to a devastating supply chain attack. A vulnerability in your Docker host, whether you use a cloud platform, Windows, or Linux server, could also lead to a compromise of your container. Finally, there is the container itself. As we have illustrated with our simple example, standard container scanning apps do not find application-layer vulnerabilities. 

Implementing defense-in-depth security for your containerized application requires a holistic approach. First, you need to secure your platform from external threats by implementing the relevant network segmentation, firewalls, and similar technologies that prevent unauthorized access. Then you need to continuously harden your hosts, images, and containers by leveraging Docker container scanning and implementing patches and upgrades. 

The final element you need to secure in your defense-in-depth strategy is your application layer. Since firewalls and vulnerability scanners that focus on hosts, images, and containers do not identify any application-related security threats, you need a solution to identify and mitigate this risk. As our example illustrated, Software Composition Analysis (SCA) tools, like MergeBase, provide visibility into the real risk of enterprise applications. Since most, if not all, modern applications leverage external libraries and packages, identifying vulnerabilities in these elements is vital in securing your application. If we revisit our urllib3 example, scanning the containerized application with an SCA tool like MergeBase found the vulnerability, and 107 others the Docker scan failed to identify.

Ready to mitigate risks?

Discover More from MergeBase

Open Source Protection

Stay on top of the real risk of open source at any time.

Avoid false positives and get sophisticated upgrade guidance based on risk, compatibility and popularity.

More on Continuous Protection

Add RunTime Protection

Detect and defend against known-vulnerabilities at runtime. The only SCA to do so.

The quickest way to respond to an imminent threat like log4j with CVE-2021-44228.

More on Run-time Protection

Shift Left Now

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

More on BitBucket and Github apps