Peaks vs. Valleys – Perspectives on Software Supply Chains

Real-world supply chains can involve planes, ocean freighters, trains, trucks, and even bike couriers. So it’s no surprise that software supply chains also involve a wide variety of complementary production, distribution, and deployment channels. 

One of the challenges with securing software supply chains is that solutions must be combined to address each conduit supporting the entire chain. Patching the libraries your software engineers copied into your final build is insufficient—you must also consider your base images, the packages and platforms brought in via provisioning scripts, and even possibly plugins deployed by admins post-deployment!

Unfortunately, these disparate channels often have different weaknesses and vulnerabilities and require different security approaches. 

Watch this webinar with our special guest speaker and expert in open-source software ecosystems, John Speed Meyers,  and the vulnerability scanning implementor, Julius Musseau, as they discuss the important perspectives on software supply chains.

What they will go through:

  • An understanding of today’s sophisticated and multi-channel software supply chains
  • What are the risks, and how to manage them
  • Software Supply chains security best practices

Take a look at the big picture and discuss specific techniques tailored to protect some of these critical pieces better.

Open Source Research 

A lot of people will claim that open source is everywhere, but how much open source software is actually out there? In this paper, we propose a methodology and associated tool that can analyze Java binaries and determine the proportion of open source that comprises them. The result of our research shows that around 80 to 90% of the software is made from open source.

Ready to start to mitigate risks in your software supply chains?

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 are 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.

Log4J Reunion Tour 2022 !!!

The unofficial, unauthorized retrospective, 9 months later.

If it was not clear before, after Log4j, it certainly is now! Everybody uses open-source software in their applications. There are no exceptions, and as a result, we are all at risk of being breached by vulnerabilities in open-source software. The Log4J bug was a wake-up call.

The Apache Log4j vulnerability was one of the most significant breaches in recent history. Its impact was felt worldwide, and the repercussions are still being felt today.

In this live event, Lunasec founder and CEO Free Wortley, AppSec Expert Jim Manico, and vulnerability scanning implementor (and Apache committer) Julius Musseau come together to discuss the 2021 Log4J debacle.

It’s been nine months since the Log4j vulnerability was disclosed! Aside from Minecraft, have any serious breaches dropped in the last 9 months? Or did everyone fix it in time? And what was so special about this bug?

To understand the issue and prepare for the future, we need to analyze the root causes of the breach and come up with a set of recommendations that can help prevent similar issues.

  • What did library developers learn from the incident?
  • What have common app developers learned?
  • How should the software industry prepare for future incidents of this scale?

Learn from the past and prepare for the future.

Live Event Highlight

Log4J Timeline

1999 – Log4J 1. x is born

2014 –  Log4J 2.x is born (includes: JNDILookup.class)

2015 – General purpose JNDI exploit technique demonstrated at BlackHat

2021 – November 24th – Vulnerability shared (privately) with Apache

2021 –  December 4th –  An interesting commit lands

2021 –  December 9th – First Annual Log4J Global Day of Celebration

2021 – December 10th – Version 2.15.0 Published

MergeBase’s Log4J Detector

With the Mergebase’s Log4J Detector tool, you can accurately find the log4j vulnerabilities in any cloud system, situation, and context.

CSRB’s Report

The CSRB’s report addresses the continued risk posed by vulnerabilities discovered in late 2021 in the widely used Log4j open-source software library, one of the most serious vulnerabilities discovered in recent years. 

It contains 19 recommendations for government and industry, focusing on driving better security in software products and enhancing public and private sector organizations’ ability to respond to severe vulnerabilities. The goal is to identify and share lessons learned to enable advances in national cybersecurity.

Advice for library Developers

  • Be more careful when preparing the fix. 
  • Github has the capability to make the pull requests and the issues private even though you’re running on a public repo.
  • Security audit code audit needs to be happening regularly with libraries that are used everywhere.

Advice for library consumers (a.k.a. Software engineers)

  • Know the libraries that you have (SBOM)
  • Keep your libraries updated and patched.
  • Keep tabs on your SCA tool – for example: How quickly was your team able to become aware of the path and how quickly they are able to apply the patch?

Advice for CISO’S & Executives

  • Don’t let your developers pick any third-party library enrolled in production; you need a stronger vetting process and understand the business risk of choosing a third party.
  • Running an SCA tool, like MergeBase, several times a day.
  • Have the willingness to update your libraries. Suggestion: keep all your libraries updated but keep one month behind an update unless you need to be at the bleeding edge because there’s a security vulnerability. Otherwise, keep a month behind the top level and then update it to avoid supply chain issues.

Ready to start to mitigate risks?

API Security – Preventing an API Breach

APIs are everywhere, and their security is becoming challenging.

It goes without saying that APIs are deployed everywhere. For instance a website click quickly initiates a dozen REST calls directly from your browser and another dozen behind the scenes. Software engineers, like you, integrate with APIs more and more to develop new features and enhancements.

Gartner is seeing explosive growth of APIs, and estimates that by 2025 less than 50% of enterprise APIs will be managed; the companies just don’t have the capacity to do it.

Are you able to secure your company’s API sprawl? 

As software engineers, we can divide APIs into two kinds: those we build & maintain ourselves (the homegrown); and those we consume (the 3rd-party externals). In this webinar, TeejLab Founder & CEO Dr. Baljeet Malhotra and MergeBase CTO Julius Musseau talked about API risks, API governance, and best practices for software engineers building and consuming APIs. 

They covered the following topics:

  • Why it’s essential to think about risk when building APIs
  • How to protect your company from the potential damage caused by a compromised API
  • API Security best practices and standards

Do you want to know more about API Security?

OWASP Top Ten #1 Worst Problem: Poor Access Control

How To Avoid “All Your Base Are Belong To Everyone!”

As you are probably well aware, access control is the biggest problem in Application Security. OWASP research in 2021 pointed this out, as did Verizon’s well-respected 2022 DIBR report.

Why is this important? The same report points out that web application attacks are the second most frequent attack pattern after DoS. So, if your organization has not been hit in this area, chances are you will be. Get ready!

The good, the bad and the ugly

Be warned; there are no quick fixes! No magical tools resolve this for you. Developers’ first response is mostly to ignore access control as an issue and to make matters worse. Application frameworks rarely provide details about their functionality since it’s not particularly generalizable.

But don’t despair! Approaches to resolve this are mature and well-developed. Watch this webinar with Application Security experts Jim Manico (OWASP Top Ten contributor), Erwin Geirnaert (Co-founder & Chief Hacking Officer at Shift Left Security) and Julius Musseau (CTO at Mergebase) to learn about guidelines, patterns, as well as pitfalls to avoid it.

What will you learn in this course?

– First, What defines the terms “access control” and “authorization,” and why are these still hard to get right?

– The building blocks developers need to know about it: 

  • Learn how to apply the principle of least privilege when building access control in your applications.
  • Learn how to use the suitable data types for access control decisions
  • Learn how to build data-centric access control system to avoid Indirect Object Reference (IOR) issues.

We are going to look at some of the building blocks around good access control. Talk about principal lease privilege we want to look at, like what data we should be using at the point of making an ac decision.

– Best protection strategies to prevent it and then one of the more difficult things, indirect object reference. It is data-specific access control, and we’re going to come up with some protection strategies and design principles. 

So, if you want to learn more about what makes applications so vulnerable and what you can do about it, this is the webinar you won’t want to miss!

The recording was made on June 20th.

Webinar’s Highlights

What is Access Control and Authorization?

AC is about selectively restricting access in a piece of software right various features and various resource access. Authorization is when you give permission to a particular user or entity to access certain features or data again. In other words, access control is the act of restricting access, and authorization is the act of giving someone access to a specific part of your software.

How do most people do access control?

They use Role Based Access Control (RBAC), which is the most common access control implemented in most web frameworks. Usually, you check in a hard-coded way what role the user is correct. This is a policy enforcement point somewhere in the software where you can check if the user has permission to execute this feature.

However, hard coding has some problems:

  • It makes “proving” the policy of an application difficult for audit or Q/A purposes.
  • Any time the access control policy changes to be updated, new code needs to be pushed.
  • It does not support horizontal ac.
  • It is often not “automatic” and needs to be “hand-coded” for each application feature. 
  • It does not support multi-tenancy.

Why is it still difficult? What is the challenge?

  • It is difficult for developers to build. Frameworks rarely provide detailed ac functionality.
  • It is difficult to test from automated tools. Scanning tools are rarely aware of your custom access control policies.

Best Practices

  • SQL Integrated.
  • Access Control Sequence: If you have a big sequence and it is hard to look down everything, protect the steps that will hurt your business
  • Data Context considered in Permissions
  • Centralize ACL Control (CanCanComunity)

Is your application safe?

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.


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.

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

What you will learn in this section:

  • 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
recording webinar on OWASP ASVS from May 11, 2022

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 Deploy an Effective Application Security Toolset?


spoiler alert: probably not

Application Security Toolset

In this webinar, application security experts Jim Manico (OWASP top 10’s contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will go over best practices for rolling out an effective Application Security Toolset to your software development and security teams.

How can you best get started, and how can you best optimize your AppSec toolset over time? Watch this webinar NOW!

How can you best get started, and how can you best optimize your AppSec toolset over time?

Are you just thinking of implementing AppSec tools, or are you looking at optimizing your existing toolset? Watch Jim, Farshad and Julius in this webinar to hear:

  1. What combination of tools gives you maximum protection?
  2. What tool gives you the highest value out of the box?
  3. How are threats likely to evolve, and how to use your AppSec tool set to stay one step ahead of cyber advisories?

Webinar’s Highlights

Definition / Acronyms

  1. SAST –  Static Application Security Testing

It looks at the source code. The scanner will investigate the source code of the system, looking for bad coding practices. For example, static application security testing can spot SQL injection or hard-coded tokens and hard-coded passwords.

2. DAST – Dynamic Application Security Testing

It looks at the running applications. If you have the running application, perhaps production, a pilot or a staging environment, the DAST tools enable you to detect security vulnerabilities in running applications using penetration tests. However, it tends to be a very slow process.

3. SCA – Software Composition Analysis (Third-Party Library Scanner)

It is specifically about open source libraries. It looks at all the open source libraries in a software system. For example, protect your business against the Equifax attack or the log4j problem back in December.In other words, It looks at bad software components and lets everyone know you need to upgrade you need not. The SCA tools are essential because open source reusable libraries are here to stay; everyone’s using them. MergeBase has a research work about open source uses. The results show, for example, that Jira has around 80% at this point.

4. IAST – Interactive Application Security Testing

It is about installing a runtime agent in the programming language, which is usually like the profiling or monitoring API of a core runtime engine and instrumentation API, and you will install an agent at the level of instrumentation to see how objects and classes and the like are executed by the runtime engine. So you are installing an agent at the runtime level of the software and watching how the program runs, not from an external point of view, but from an agent that you have installed within the application itself. Get more visibility supposedly into how the app is running.

5. RASP – Runtime Application Self Protection

It provides personalized protection to applications. It uses the app’s data and state to enable it to identify threats at runtime. It automatically isolates and identifies vulnerabilities.

Matrix – Categorize Cybersecurity tools and Information Security Tools

How to Deploy an Effective Application Security Toolset?

What are common/typical challenges teams face when implementing these tools?

The challenges faced are:

  • It lights up a lot of false positive number
  • It requires an expert operator.

Normally, they get flooded with uh findings right like thousands of findings; what do you do, and how do you prioritize them? And the solution is to bring in an expert to tune.

Application Security Best Practices

Three approaches with a different focus:

  • SCA – > External Libraries/ Supply Chain

Analyze applications for know vulnerabilities, and secure your software supply chain.

  • DAST – Test Application Surface

Try to break into production applications. It will catch configuration issues and some of the above vulnerabilities.

  • SAST – Source code, developed in-house

Analyze source code for bad coding practices

These tools complement each other, and the best practice is to us all there.

Ready to start securing your applications?

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