Watch if 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!
This has some bad implications if you’re using it to protect yourself from Log4J (since Log4J is a Java library).
- 2017 – Started by Grey Baker & Harry Marr
Initially, a “bot” that 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…
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 log-file?
If there’s not 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 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 transitives or in the indirect right.
What is a lock file?
Its 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 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 “Give 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 same problem 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-https://github.blog/2021-12-14-using-githubs-security-features-identify-log4j-exposure-codebase/
- “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 “direct” vs. “indirect” situation 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 scan DotNet, tell us!