Software Supply Chain Implications for Zero Trust

Zero Trust (ZT) has been the source of hope and confusion for many organizations looking to improve and modernize their security program. 

It is not a new concept, but President Biden’s 2021 Executive Order has recently highlighted it. The order cites Zero Trust, Software Supply Chains, and SBOM as critical pieces toward better securing American institutions and people against cyber attacks.

There is wide agreement that ZT concepts lead in a positive direction toward better security. Implementing it requires fundamental changes and raises questions: How does it really work? How do I apply it? What are its implications?

In this webinar,  Jerry Hoff and Julius Musseau break down Zero Trust’s fundamental concepts and resources. Also, they looked at Zero Trust’s implications for Applications, SBOM and Software Supply Chains.

Watch it now:


Webinar Highlights


Zero trust is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.

Put more simply, zero trust security is a way of thinking about cybersecurity that trusts no one until they can be proved worthy. This proactive approach is designed to cut down on the number of breaches that occur by preventing access to systems and data until it can be guaranteed that the user is who they say they are and that they have a legitimate reason for wanting to access the data.


ZT provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privileged per-request access decisions in information systems and services in the face of a network viewed as compromised.

Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a ZT enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.

How Does Zero Trust Address Cybersecurity Challenges?

Zero trust security is an approach that addresses the inherent lack of trust in today’s networks. Because users can access resources from anywhere, companies have to rely on security measures that can’t be circumvented or ignored.

It addresses this challenge by verifying users and devices before granting access to any resource. This helps to ensure that only authorized users have access to the data they need, and it also helps to prevent unauthorized access, theft, or corruption of data.

ZT is an important part of today’s cybersecurity landscape, and it’s quickly becoming the new norm for companies of all sizes.

Strong Identity, Authorization & Data

Core Zero Trust Logical Components
Source: NIST

Which effectively means

  • Strong Authentication / Identity is paramount
  • Identity based access control for all connections
  • Encryption on all connections
  • Consistent application of security rules
  • Cloud and on prem workloads
  • Remote and on prem workers
  • Device Control / Inspection
  • Deliberate access granting / strong governance
  • Enriched monitoring

Base Pillars to build ZT

High-Level Zero Trust Maturity Model
Source: CISA

High-Level ZT Maturity Model

High-Level Zero Trust Maturity Model
Source: CISA

New Capabilities

  • Need for unified, centralized, overarching authentication
  • Need for centralized authorization & decision-making capabilities
  • Need for device information
  • Updated SOC capabilities (EDR)
  • Updated Training for Staff (design, implementation, deployment, production)
  • Internal delegation (who oversees centralized auth, authz, etc…)
  • Policy design, update, implementation (who ?)
  • Updated Governance (Many more decisions)

Implications for Application Security

  • Identity
  • Internally facing / externally facing paradigm breaking down
  • Secure connections
  • ZT is getting grouped together with new appsec regulations.


Zero trust security is an emerging cybersecurity paradigm that enables businesses to protect their data and resources by verifying the identities of all users, devices, and applications before they’re given access. In other words, with zero trust security, there are no trusted networks or users—everyone is treated the same, regardless of their past behaviour.

When Container Scanning Falls Short

Are you relying on your container scanning to secure your applications? You might be exposed!

Containers have taken IT by storm. They increase delivery speed and stability. To secure them, you just run a scanner, right? Perhaps…

Metal detectors cannot detect plastic explosives. Similarly, many container scanners (e.g., Quay, Docker Hub, and even Snyk) are unable to detect the most vulnerable libraries inside Docker containers or Kubernetes clusters.

Do you want to know what your container scanner might be missing?

Watch this live streaming event with the heavyweight security expert Julius Musseau, where he highlights the issues and presents solutions. Learn about the typical container scanning shortfalls.

What you learn (takeaways)

  • Where most container scanners fall short (and can seriously hurt you).
  • A methodology to evaluate container scanners
  • How to simplify application security AND improve container scanning (too good to be true?)

Webinar Highlights


Container Images

I created 3 “log4j” container images. (If you want to play with these container images, click here)
1.)  Easy Mode – container created using “apt install liblog4j”.  This brings in log4j via Ubuntu’s own native package manager.
2.)  Medium Mode – the container was created by downloading log4j from Maven directly to disk.  (This mode best simulates what developers normally do.)  I even rezipped the jar to cause all the timestamps to refresh (which alters the sha1, of course), but this did not trick any scanners.
3.)  Hard Mode – same as #2 except the following 3 files are removed from “log4j-core-2.14.1.jar” before scanning it:
Initial Unexpected Distracting Problem

I didn’t expect this at all, but all the container scanners (except MergeBase) are barfing a ton of uninteresting CVEs against the “ubuntu:20.04” latest base image. This is an LTS image under active support (still receives security patches) until 2023.  Why are the scanners reporting a bunch of vulns against it (including some from 2016)?  This doesn’t make any sense!

As an end-user, there’s nothing I can do!

apt update
apt dist-upgrade

Ubuntu reports, “You’re completely up to date; there’s nothing to do!” but the scanners are still reporting vulnerabilities. Why not warn me that the sun will explode in 5 billion years while you’re at it?


Container Scanning – The Actual Results

When Container Scanning Falls Short

It turns out most container scanners are police officers where if you say, “oh, sorry, officer, I seem to have misplaced my driver’s license,” they just let you go!

This could be a problem because:

1.  Some libraries don’t include metadata files – either on purpose, or by accident, or by historical happenstance (e.g., the metadata format had not been standardized back in 2005 when the Jar was created).
2.  Open source logic can be mixed and imported in different ways (open source licenses usually don’t forbid this), and metadata might get altered or omitted during such transformations.  Copy/paste, anyone?
3.  Finally, what if someone maliciously removes or alters the metadata?


When evaluating scanners, it’s very important to examine them with a pre-seeded known-vulnerable sample (preferably one you create yourself) during your tool selection process (and perhaps during an annual check-up/review).

And one final caveat:  I suspect the scanners were all carefully tuned to detect log4j (e.g., special one-off logic).  I would be pleasantly surprised if they did as well against less infamous (but similarly vulnerable) samples.

MergeBase actually looks at the class files.  And so MergeBase detects the vulnerable version in “Hard Mode” regardless of the metadata present or not present.

Ready to try our SCA tool and avoid problems when scanning your container?

Want to check out our next live event? Click here and find out more about it.

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?

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 Mergebase’s Log4J Detector tool, you can accurately find the log4j vulnerabilities in any cloud system, situation, and context.

CSRB’s Report

A new report from the Cybersecurity and Infrastructure Security Agency’s (CISA) Cybersecurity and Infrastructure Resilience Bureau (CSRB) 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.

The report 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.

“Our nation’s cybersecurity depends on the security of the software we all use every day,” said Tonya Ugoretz, Director of the CSRB. “

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.

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. So, API security is becoming a crucial topic.

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.

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

Why Do APIs Matter?

  • The “REST Revolution” gave us all an important software architecture for free: front-end/back-end.
  • And then back-ends started calling back-ends.
  • And the rest is history!

What do we need to do?

APIs act as translators that allow communication between various devices and/or apps.

APIs must be: Discovered, secured, and governed systematically.

API Proliferation

The overall ecosystem of APIs at the global scale is already into millions of public APIs. We have indexed a lot of them that way, and we have built the world’s largest repository of APIs, more than what programmable web has, more than what rapid API has, or even that other organizations may have catalogued.  

For example:

  • Microsoft in 2020: 60,000
  • Google: 35,000
  • Amazon: 30,000

How do you discover APIs?

It is a technologically challenging problem. It is a very easy concept to understand but very hard to solve because the information over the internet could be so unstructured.

There is a lot of unstructured information available on the internet, and a lot of this information is embedded in the software liability itself because a lot of times, a lot of companies have APIs, but they never published a report or a portal or a page which describes their APIs simply because either they don’t have a business functionality, they want to expose, or they just want to keep these APIs secrets for just their customers and partners.

There are various mechanisms we are applying that are curating this information at a global scale, mining repositories mining international web pages.

It is possible to get visibility into authenticated APIs?

Yes, because if you just see the declaration of an endpoint that isn’t good enough, that doesn’t tell you what that API actually does. So, if we wanted to go beyond that, we need to authenticate and access the API, and many times you need to register to get the account, get the API keys, or in some cases, the authentication can be author or JWT.

So we could use these APIs as much as we could, but there’s a lot of automation that can’t be done because you actually have to register to get the key.

And to do that, we need to have information where we can actually authenticate and make a call to the API and actually see what data comes in and out, look at the header, look at the response and other information so that there are authenticated APIs in your index absolutely no interest, that’s what makes things more interesting.

How can you secure public APIs?

Simple things, for example, you may create an account to access an API, do some experimentation and may end up not using it, but it can stay there; you may forget maybe you might hardcore the password because you were in an experimental shooting mode and suddenly you checked out this library and somebody decided to make this open source. There you go, you expose some of those things.

The first step is to be aware of all your APIs, document them, and nicely catalogue them.  Because the problem is a lot of times, teams do not know their APIs and end up being exposed to unnecessary risks.

How can you secure internal APIs?

The typical approach taken is since this is an internal API, you don’t need to authenticate; you don’t need the layer that is needed for my publicly exposed API. So, actually, the zero trust principle is authentication. Authorization is a must for all your resources. If you’re treating your API as a resource, then you want to make sure that you are using the same level of authentication authorization tightness around your internal APIs as much as you’re doing for your external APIs. 

Advice for building brand-new APIs

As we know, security doesn’t start when your product is built, and then you buy the best tool to fix your problem; that’s not how it should be security. It starts with your design, and security starts with your stakeholders.
For example, if you’re building API, ask the very first question who are we
building this for? Who needs to consume it? Is this an API that only one set of customers needs to use, or is this a very useful API that perhaps hundreds and thousands of users need to consume it? Is this a paid API? Is this a free API?
All this is part of your security assessment which starts with the design aspect itself, and then, what’s the best way for us to authenticate it?
If there is an API that needs to be doing machine-to-machine communication, you don’t want to implement OAuth or token-based because it defeats the purpose of machine-to-machine communication. Maybe an API key base, but what is the session approach you want to take? How far will your tokens go on to be? 
So all starts with the design thinking in place and making sure that you understand your stakeholder, the user and what is the criticality they are going to support. Once you have figured out those details, you can start to implement, test and ongoing monitoring them.

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?

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

2 – 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 suitable data types for access control decisions
  • Learn how to build a 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.

3 – 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!

Webinar’s Highlights

What are Access Control and Authorization?

AC is about selectively restricting access to 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.

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!

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 to running applications, 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 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

Categorize Cybersecurity tools and Information Security Tools

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 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 focuses:

  • SCA – > External Libraries/ Supply Chain

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

  • DAST – Test Application Surface

Try to break it 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 for us all there.

Ready to start securing your applications?

When Dependabot Is Worse Than Nothing: Log4J As A Sub-Dependency

Watch this webinar about how Dependabot applies to you and find out how to fix this :).

Why should you care about using Dependabot?

Because if you’re using industry-standard software leader Dependabot, then your devs didn’t fix the recent Log4J problem properly.

If you’re using it, then the tools you’re using now aren’t getting the job done.

In practice, it has a serious implementation flaw: it can only see transitive dependencies (aka sub-dependencies) in languages and dependency managers that support lock files.

Dependabot: Theory vs Reality

In theory, Dependabot is exactly what the world needs to keep software dependency chains safe from known vulnerabilities: tightly integrated with Github; auto-generates pull requests, plugged into Github Security Advisories (GHSA); it also supports a wide range of programming languages and dependency managers.

But in practice, it has a serious implementation flaw: it can only see transitive dependencies (aka sub-dependencies) in languages and dependency managers that support lock files.

Do you know any languages that currently DO NOT support lock files?

Java / Maven!

Dependabot History

  • 2017 – Started by Grey Baker & Harry Marr

Initially, a “bot” would automatically create pull requests to keep NPM dependencies up-to-date.

  • 2019: Acquired by Github

Now claims to support: C#, Java, Python, PHP, Rust, Go, etc…

Dependabot’s Problem

It can only find all the vulnerabilities, including the dependencies of the dependencies, if there’s a log file. So if you have a package lock.json or a gem lock or a yarn.lock if you have those in your git and you’ve committed them to get and push them up to your git server to GitHub, then dependabot can is able to use those lock files to examine the complete dependency tree, and then it can find the vulnerable libraries deep in that dependency tree.

When is there a lock-file?

A lock-files are pretty much out-of-the-box standard usage with javascript, PHP, Go and Ruby.

 If there’s no a lock-file?

if not have a lock-file

When there’s no log file, but dependable is not really going to tell you about that dependabot; it’s not going to say: “alert! I’m in severely degraded instead the dependabot is going to look in this case what we’re saying is that this

the particular software system has six direct dependencies, and then those six direct dependencies bring in 50 or 60 additional sub-dependencies (indirect dependencies)

So dependabot, it’s only going to look at those six libraries, and “uh; oh,” there’s the bad ones; the depentabot’s gonna miss those because those are in the transitive or in the indirect right.

What is a lock file?

It’s funny lock-files themselves have nothing to do with application security, and they have nothing to do with the open source problem lock files solve a different problem; they solve build repeatability. We use these lock files so that everyone on your team is able to build the same software system with all the same libraries, so you auto-generate this lock file.

  • Ensures Repeatable Builds across a software


  • Examples: yarn.lock, composer.lock, package-lock-json
  • Idea: auto-generate (e.g.,”npm update”) and store in Git to ensure everyone is working from the same libraries.

When Dependabot Is Worse Than Nothing: Log4J As A Sub-Dependency

example 2

The nice thing about the package-lock is it’s going to also take the full tree and write the full dependency tree to disk in this file so that everyone on the team has the exact same dependency tree in their software system.

Why doesn’t Java have lock-files?

  • Because lock-files are born from chaos
  • Do you remember how “npm install” circa 2013 was absolute utter mayhem?
  • Any dependency system that supports “Give me anything that matches 1.2.x” or “Gives me anything ›= 3.2.1” is going to have lock-files.

What about DotNet?

  • Classic case of “If it’s not enabled by default”
  • Also, DotNet implementation is a little clunky (one lock-file per *.csproj / * voproj file, so usually, that means hundreds of lock-files).
  • On that note, lock-files are available with Java Gradle builds these days! (But the same problem is not enabled by default!)

Note: Lock-Files Make SCA Easy!

  • Recall that SCA – Software Composition Analysis – is the industry term for tools that
  • “help you fix your vulnerable libraries.
  • SCA is essentially 2 problems:
  1. Identify all the libraries in the software.
  2. Determine safe upgrade versions.

Both are hard, except #1, if a lock-file is present!

Why does MergeBase find transitive dependencies at this level when other industry-leading tools do not?

The reason that MergeBase is able to find the transitive rate is that we’re not relying on lock files exclusively; certainly, we’ll look at the lock file and consider it, but we’re also, you know, we’re going to ask maven to tell us maven like what do you think the full dependency tree is.

Does Dependabot Know About This?

  • They certainly do!
  • Dependabot team wrote a blog post about Log4j
  • “You can use GitHub Dependabot to surface all locations Log4j is explicitly declared as a dependency”

Side Note / Sad News / Re: DotNet

  • We tried to research the “direct” vs. “indirect” situations with DotNet projects as well.
  • Bad news: Dependabot failed to identify transitive vulnerabilities.
  • Sad news: Also failed to identify direct vulnerabilities.
  • If anyone knows how to scan DotNet, tell us!

Want to know more?

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