Dependencies have known vulnerabilities

[trevordixon]

@asyncapi/cli is the only dependency in our project that depends on packages with vulnerabilities according to npm audit. Is upgrading to rely only on patched versions of dependencies a goal of the project, or should we assess the risk of individual vulnerabilities on our own and find a way to ignore vulnerabilities whose risk we deem acceptable?

[github-actions[bot]]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

@trevordixon hey, thanks for opening the issue. We rely on dependabot across the whole org, and I just checked that it was disabled in this repo. I don't know why, but anyway, just enabled it. We definitely want to have CLI always up to date with patches to solve quickly any vulnerability issues.

cc @Souvikns @magicmatatjahu

feel free to also open a PR for specific patches that you need in place

[derberg]

dependabot started kicking in -> https://github.com/asyncapi/cli/pulls?q=is%3Apr+author%3Aapp%2Fdependabot 💪🏼

I guess I can close this issue?

[mattias-persson]

@derberg I think the most critical vulnerability is still present in the vm2 dependency, indirectly included via spectral-cli. Upgrading spectral-cli from 6.6.0 to 6.9.0 should resolve that one though. I started with a PR patching this but a bunch of tests failed and I need to find the time to understand and resolve the failures. If you get a chance to look at it before me that would be very much appreciated 😄

[derberg]

@mattias-persson even if tests are failing, please open a PR so I can have a look, maybe will have some hints

[mattias-persson]

Done @derberg! https://github.com/asyncapi/cli/pull/750

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[KristinaB162]

There are still many vulnerabilities. These can be fixed by an audit with version regressions (0.8.1). But this in turn causes other problems. When using the asyncapi cli, errors are thrown that modules cannot be found ([MODULE_NOT_FOUND] Error Plugin: @asyncapi/cli: Cannot find module '@oclif/plugin-help/lib/command')

[Amzani]

still relevant

[Amzani]

@KristinaB162 The highest severity issues are present in the dependencies we don't have control over: @oclif/plugin-commands and @oclif/plugin-warn-if-update-available Created https://github.com/oclif/plugin-commands/issues/661

[SARAN-thala]

Still the high vulnerability from lodash.template are coming from this package. run npm audit

lodash.template  *
Severity: high
Command Injection in lodash - https://github.com/advisories/GHSA-35jh-r3h4-6jhm
fix available via `npm audit fix --force`
Will install @asyncapi/cli@0.10.2, which is a breaking change
node_modules/lodash.template

Totally 14 vulnerabilities (12 moderate, 2 high)