clj-commons

slipset 2022-10-09T18:56:12.837579Z

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?

lread 2022-10-09T20:37:39.704539Z

Probably makes sense? Might want to ask @seancorfield 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.

seancorfield 2022-10-09T20:59:55.724319Z

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".

lread 2022-10-09T21:11:43.079779Z

tx sean!

vemv 2022-10-09T21:30:41.599719Z

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

vemv 2022-10-09T21:31:53.551369Z

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

vemv 2022-10-09T21:33:12.129169Z

...the verbosity can be tweaked per https://github.com/rm-hull/nvd-clojure#logging

lread 2022-10-09T21:47:01.350709Z

tx vemv!

slipset 2022-10-10T06:14:12.858309Z

@vemv you need another issue type, Improvement šŸ™‚

slipset 2022-10-10T06:28:20.314459Z

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

vemv 2022-10-10T09:38:20.929819Z

(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

lread 2022-10-10T11:23:52.044689Z

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.

lread 2022-10-10T11:25:02.178619Z

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

vemv 2022-10-10T11:35:41.583059Z

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)

lread 2022-10-10T11:40:37.558769Z

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

vemv 2022-10-10T11:44:05.451199Z

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 :)

slipset 2022-10-10T12:24:59.594549Z

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

slipset 2022-10-10T12:25:23.789849Z

Like, I just blanket upgraded snakeyaml, and see where that got us šŸ™‚

vemv 2022-10-10T12:57:06.046479Z

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

lread 2022-10-10T13:02:05.101699Z

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