DependencyCheck VS gitlab

Use Security Tools: To identify known vulnerabilities in your project's dependencies, you can utilize commands like npm audit or employ third-party security scanners such as DependencyCheck or Dependabot. These tools thoroughly analyze the dependency tree and offer actionable insights to assist you in resolving any identified vulnerabilities.

OWASP DependencyCheck - a really decent tool for scanning your project for vulnerable dependencies. It is actively developed and updated and up to date with the most latest vulnerabilities. Sometimes it can be a pain in the ass, though. Some security researchers and such find a vulnerability, publish it and the next day our CI/CD pipelines fail (the dependency check build step prevents the code from going to production). And not always there is a fix available. So, some vulnerabilities have to be ignored, temporarily. Also, to be able to ignore a vulnerability one has to do a fast risk assessment. And that will require from him to read about the vulnerability and decide if it is safe to be ignored or some different workaround must be found.

The ultimate guide somehow fails to mention the best CVE checker: https://github.com/jeremylong/DependencyCheck

We run https://github.com/jeremylong/DependencyCheck over our dependency tree regularly, via this Clojure wrapper: https://github.com/clj-holmes/clj-watson which tells us the dependency tree path to each item that has a CVE and also the version in which the CVE is addressed, if known.

We use OWASP dependency-check and pass reports to SonarQube.

From OWASP for those class of tools you could look into DependencyCheck and DependencyTrack

DependencyCheck is an open source tool that checks for vulnerabilities in dependencies used within a project. While it is a reactive tool, it's an important one since the code a developer writes is not the only code an application uses.

One more aspect to consider, although I know it is not the primary ask of the post, is to be sure and run something like dependency check on your repository. There are quite a few vulnerabilities being injected through the packaging process these days.

Since the relevant code appears to be in the "ee" directory <https://gitlab.com/gitlab-org/gitlab/-/blob/v16.11.0-ee/ee/l...> and is not present in the foss repo, I'm guessing the answer is no, at least for now. They do have a history of "releasing" features from EE back to CE but my suspicion is not for LLM stuff

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that https://hub.docker.com/layers/multiarch/qemu-user-static/7.2... actually mutates the binfmt_misc in buildx's context in order to exec the static copy of qemu in it https://github.com/multiarch/qemu-user-static/blob/v7.2.0-1/...

and, that the buildx plugin itself has some qemu magick in it, which got addressed in a minor version bump but I couldn't track down the relevant GitHub issue this second (I've flushed it from my mind, only recalling that there were a lot of actors in that tire fire)

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...