OWASP Adopts CVE Lite CLI to Boost Dependency Scanning

Checking for dependency vulnerabilities in freshly developed software is usually done near the end of the build process. Remediation at that point can be tricky. 

Now, JavaScript and TypeScript developers can check for vulnerabilities themselves as they – or their agents – write their source code, using an open source project called CVE Lite CLI

Last month, the Open Worldwide Application Security Project (OWASP) accepted CVE Lite CLI as an incubating project. Sonu Kapoor specifically created CVE Lite CLI to check vulnerabilities earlier in the development cycle. 

Kapoor’s approach can be seen as a form of “shift left,” where the developer assumes more responsibility in ensuring the security of their code. It differs from how vulnerability scanning is typically done within production workflows, where security is a separate test that happens at the end of the development cycle. 

Once installed, the app can scan your lockfiles – the dependency tree configuration –  and check the installed dependencies for any vulnerabilities they may have, by referencing the Open Source Vulnerabilities database. If a vulnerability is found, it then generates a set of ready-to-copy commands that can be pasted into the command line to update from your given package manager (npm, pnpm, Yarn and Bun are currently supported).

CVE Lite CLI can also work offline, caching all the CVEs on a local database. 

Parent-Aware Guidance

Other interface-based vulnerability remediation tools include GitHub’s Dependabot, The Node Package Manager’s npm audit, Google’s OSV-Scanner, Snyk CLI and the Socket CLI.

CVE Lite is smart with the transitive dependencies, pinpointing the exact root level of an errant package. 

“Transitive parent update guidance is one of CVE Lite CLI’s core differentiators,” the documentation claims. “Instead of telling users to install a vulnerable transitive package directly, the CLI points at the parent package that controls the dependency path.”

A direct dependency is easy to replace. Transitive dependencies, or dependencies embedded within other dependencies, are trickier to sort out. 

But CVE Lite is smart enough to know when the package is transitive. A lot of package managers, if they can’t find the embedded package, or if the parent package prevents it from updating the problematic dependency, will just put the new version of the embedded dependency in the root directory, which is effectively useless. 

CVE Lite takes a different approach: Instead of updating the package itself, it updates the parent package. 

CVE Lite CLI can even work with the Node.js Hoist model, where all the packages reside in the node_modules folder, reducing the problem of recursive nesting, though obscuring the dependency tree for most scanners.

There are a few immediate limits with this developer-first approach which must be considered in an overall security defense strategy.

CVE Lite doesn’t provide any runtime protection, so an organization will need separate tooling for that function. It is wholly dependent on a single CVE database, and thus may miss some vulnerabilities that don’t get reported there. The offline cache will continually need to be updated when the software is online. 

The Problem of Vendoring

Hidden dependencies remain a quagmire for the open source community in general, especially as unpatched vulnerabilities are the major source of supply chain attacks – witness the Mini Shai-Hulud attack earlier this month in which 170 npm and PyPI packages were poisoned. 

A user may install an app that comes with its own set of dependencies. Unless the app itself is updated (if it is updated at all), it may contain libraries or other code that will have known vulnerabilities. This is sometimes called “vendoring,” where a software provider introduces hidden vulnerabilities through third-party software.    

Mitchell Hashimoto, creator of the popular Ghostty terminal, recommends forking any dependencies you use, trimming them to just what you need, and then embed them in your code and never update them, at least until something breaks. 

“I’ve always said that updating is way riskier than latent bugs (which can be tracked and CVEs monitored),” he wrote on X. “If you are updating a dependency, it’s on you to analyze every single commit in the full transitive set of dependencies.”

Read More

Scroll to Top