Dependency management is a critical aspect of software development that ensures applications have access to up-to-date and secure libraries and frameworks. One popular tool in the industry for managing dependencies is Dependabot, which automatically updates your npm packages and other dependencies in your GitHub repository.
However, despite its promising features and integrations, Dependabot has a significant implementation flaw that limits its effectiveness. 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 dependencies 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?
When there’s no log file, but Dependabot is not really going to tell you about that; it’s not going to say: “alert! I’m in severely degraded mode.” Instead, Dependabot is going to look in this case what we’re saying is that this 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 team.
- 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.
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 .Net?
- 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:
- Identify all the libraries in the software.
- 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!
Conclusion:
While Dependabot initially seems like a promising tool for dependency management, its limitations regarding lock-file support hinder its ability to identify and address transitive vulnerabilities accurately.
Developers should be aware of these constraints and consider alternative solutions like MergeBase for more robust dependency analysis. Understanding the importance of Software Composition Analysis and exploring suitable scanning options can significantly enhance the security and stability of software projects.
Ready to experience a comprehensive dependency analysis with MergeBase? Try it out today and ensure the safety of your software. Find out more about how MergeBase can revolutionize your dependency management process. Don’t leave your software’s security to chance – make informed decisions with MergeBase.
