Fork me on GitHub
#clj-commons
<
2022-10-09
>
slipset18:10:12

I just made a https://github.com/clj-commons/clj-yaml/pulls for clj-yaml to set up a nvd scanner. I think that would be useful for the other projects with transitive deps?

lread20:10:39

Probably makes sense? Might want to ask @U04V70XH6 what he uses, I vaguely remember him liking an alternative? I use the nvd scanner manually on cljdoc. I very much appreciated it. The only things I’m not crazy about are the overly wordy output and that it can generate quite a few false positives.

seancorfield20:10:55

We were using https://github.com/rm-hull/nvd-clojure for a while but we switched to https://github.com/clj-holmes/clj-watson -- I prefer the output/control it provides and the ability to mark certain CVEs as "acceptable".

vemv21:10:41

nvd-clojure accepts suppressions in this format https://jeremylong.github.io/DependencyCheck/general/suppression.html, which means one has control over what is "acceptable"

vemv21:10:53

other than that I'd happily accept a specific issue with a suggestion! nvd-clojure tries to stand out by being very strict - we prioritize simple over easy when it comes to security. no second-guessing of classpath, or such

slipset06:10:12

@U45T93RA6 you need another issue type, Improvement 🙂

slipset06:10:20

I could be happy to submit some sort of PR for that.

vemv09:10:20

(un)fortunately you can skip the whole template machinery :) gh offers a link for that or you can delete the query params from the url shipit

lread11:10:52

Thought/question: I'm a fan of specifying exact versions for deps, but is the nvd dep version one that should be set to RELEASE? I'm thinking it would be important to always use the latest security scanner.

lread11:10:02

An altermative would be to also check for outdated deps, but maybe RELEASE is a simpler compromise.

vemv11:10:41

Good q! I would recomend to use fixed versions. That way you are encouraged to read the changelog (which antq now links to!) and not possibly use a backwards-incompatible version (which I try to avoid as much as poss of course, but sometimes it's the right thing for security)

lread11:10:37

I think you typically also CI check for outdated deps on your projects too @U45T93RA6?

vemv11:10:05

depends, I'm not much into blindly updating stuff. But maybe it makes sense for something like a clj-commons lib (whereas in an app it's just too much of a can of 🪱s) I do have antq (and clj-kondo) hard-failing Eastwood :)

slipset12:10:59

I’m not a huge fan of blanket-upgrading-libs.

slipset12:10:23

Like, I just blanket upgraded snakeyaml, and see where that got us 🙂

vemv12:10:06

as mentioned it depends :) antq in particular can be configured in a fine-grained way. also, I don't know the backstory of that snakeyaml upgrade but if it caused any problem, it might have been a good stimulus to revamp the CI / test suite

lread13:10:05

I typically update deps. I do read the changelogs. And do nvd security scans. And npm audits. And trivy image scans. For a lib I’m extra careful if the dep is included with a release. The only app I work on these days is cljdoc. Cons are these changes introduce some risk and can break things. Pros are that newcomers will have an easier time contributing, and I help the OSS community by ensuring my stuff works with current deps, and by uncovering and reporting issues in updates.

🙂 1