Very nice! I'd recommend documenting the nvd usage such that https://github.com/rm-hull/nvd-clojure#avoiding-classpath-interference is honored In particular, the classpath the nvd program itself will be running should never be affected by a given project's dependencies. This can be as easy as cd ~ before running the program. Next point, the analyzed classpath's should be received as an argument out of a clojure -Spath invocation, please don't let it be inferred (that API will soon be deprecated)

I've updated the command to run the :security/nvd alias to include the two arguments. As :security/nvd is a user wide alias, then clojure-nvd is not included in the project path, which is what the documentation seems to warn against. However, the clojure-nvd jar is merged into the classpath when used as an alias no matter where the clojure command is run, so it would still be there. Perhaps this is a candidate for being a tool and dropping this alias (or marking the alias with a warning) This would make a good example of why the -Ttool approach is useful.

Thanks! Looking reasonable > However, the clojure-nvd jar is merged into the classpath when used as an alias no matter where the clojure command is run, so it would still be there. One should be careful both ways: a given project's dependencies can affect nvd-clojure's own dependency tree. So cd ~ does buy one extra isolation for that one case as well. -Ttool is a bit better which is why we added it to nvd-clojure. Still, I was disappointed that Tools adds . to the classpath, so cd ~ still buys a little bit of correctness. For a security-oriented tool I'm generally favoring correctness over convenience/minimalism.