Cool! I’ve just started to use https://github.com/rm-hull/nvd-clojure, is this something similar?
it's similar but afaik nvd-clojure does not try to remediate the vulnerability
Indeed. They use the same tech, with some nuances from what I checked out.
nvd-clojure does not provide automated remediation because I don't think it's a good idea, I say this as someone who has used the tool for years and has worked in the security industry a number of times.
If it's about saving some typing/googling, one certainly can run antq and selectively stage relevant changes. Then again I don't recommend mindlessly updating versions without understanding the CVE in question, its impact (or lack thereof), and best remediation (which might not involve upgrading at all e.g. discard/replace the dep or add :exclusions for unused transitive deps).
I'll add this as a FAQ to nvd-clojure.
Hey @vemv interesting perspective but I’ve worked as a security engineer in a company with over 700 engineers and 800+ Clojure services and this approach definitely did’t work for us. The majority of the developers do not prioritize the findings since the available tools only provide not so rich information about the vulnerability and even when they try to fix the vulnerabilities the amount of work necessary to understand/find/fix the dependency tree discourage than. And since it’s really hard to delegate this kind of problem to infosec folks because they are just a few I truly believe that the most efficient approach is to give more information to the developer and a way to help they automatize the fix.
Interesting! Nice to have options!
Likewise, interesting perspective :) I'd be interested in seeing how much richer can the contextual info be. A list of CVEs (and perhaps links, for handiness) seems to be just about everything one can do to explain an issue at hand?
Other than that, if a given org's engineers aren't proactive/careful in their practices, that's a pretty severe problem in itself, that can manifest itself in many other ways later.
Giving them something 'easy' might provide quick wins but it also can mean a) a suboptimal remediation was chosen, b) said remediation introduced downtime e.g. it introduces an issue that managed to escape the test suite.
In practice, an already-healthy dependency tree will have to be updated once every couple months or so. i.e. the frequency is so low that it is viable to remediate it intentfully, crafting a nice PR/dialogue that everyone can learn from (vs. the typical 'junk automated PR' that would come from dependabot or such)
> said remediation introduced downtime You can rely on other mechanisms to reduce the possibilities of downtimes, such as canary deploy.
@mthbernardes Instead of clogging up issues on your GH, I figured I'd have an interactive convo here. I've been trying to use clj-watson with no success so far:
(! 645)-> clojure -Sdeps '{:deps {io.github.clj-holmes/clj-watson {:git/sha "a1b37f23b04e8b95313a1ba6bfe4f0379607da3b"}}}' -M -m clj-watson.cli scan -p deps.edn
Downloading/Updating database.
Download/Update completed.
I expected that to find dependencies with CVEs (because nvd-clojure does).Are the dependencies in some aliases?
In Polylith, all dependencies are in :dev for normal REPL working, and there are separate projects/*/deps.edn files used to just build the artifacts.
Running watson via -M -m from git deps also "pollutes" watson's environment (I started getting a lot of low-level logging appear, running it inside a project folder). I haven't tried running it via the JAR -- nvd-clojure lets you install it as a CLI "tool" and run it anywhere via clojure and that avoids pollution (as would downloading the raw JAR and running it per your README, but no one runs Clojure stuff like that).
Hm I’m going to investigate why all those logs are appearing when using it just like u used. You’re totally right no one runs code like that lol
Does it only read the :deps section of deps.edn or does it read :extra-deps in all :aliases as well?
By now it’s only reading dependencies from :deps but I’m working to fix it.
The main issue with a monorepo (in general) and Polylith, in particular, is that the aliases are critical to picking up the correct deps. I will try watson with the projects deps.edn files, but I suspect the relative :local/root deps might make that more complicated...
Yeah, I can't just point watson at projects/api/deps.edn, I actually have to go into projects/api and run watson against the deps.edn there, so I'd have to run it separately against each of our 20 projects -- but it does work that way.
I’ve just found a solution for this issue and now it’ll support all dependencies in aliases.
I’ve made a few changes on it and I think that now https://github.com/clj-holmes/clj-watson/blob/main/README.md supports everything that you’ve mentioned.
Is it relying on t.d.a to produce the classpath and library versions or is it doing some other parsing of deps.edn?
not sure if t.d.a is tools.deps.alpha but clj-watson https://github.com/clj-holmes/clj-watson/blob/a1b37f23b04e8b95313a1ba6bfe4f0379607da3b/src/clj_watson/diplomat/deps.clj#L11-L14 it.
Glad you're not trying to just slurp and read the deps.edn file and make sense of it directly 🙂
nvd-clojure uses a classpath which is nice because then you can produce your classpath however you want and just tell nvd-clojure to check that.
interesting I’ll investigate if I could do something similar.
nvd-clojure had deps.edn parsing at some point but I prefered to remove it - for a security tool I'd favor making sure that the user understands what's going on and is responsible for the results he's getting