glob reported as vulenrability in trivy scan

[forest cypress]

Hi Everyone, I am new to Backstage. Currently exploring the opportunity for implementing for our company. We are working on a mvp where first step we need is to install vanilla Backstage in k8s cluster.

We have created Backstage in our local with npx command. Pushed the code to organization github repository. Connected it to the ci/cd Pipeline.

Now in trivy image scan step we are getting error that current version of glob library is having vulnerabilities.

In the report it says we are using 10..4.5 version and 11.0.3 version. And the fixed versions are 11.1.0 and 10.5.0. How do we fix this problem. Any help or pointers would be really helpful.

[tame geyser]

https://backstage.io/docs/overview/threat-model#operator-responsibilities

Continuously keeping dependencies fresh can be done several ways. Either by hand reactively (eg using yarn commands), or by leveraging tools like dependabot or renovate to automate it

Here's one example of our automation bumping, approving, and merging a dependency. Just to illustrate.

https://github.com/backstage/backstage/pull/31795

[forest cypress]

@tame geyser Thank you so much for getting back. This helps. I am going to try this out tomorrow. One little question though, do we update this dependency in yarn.lock file and we will be done or do we need to find out where in package.json this dependency is there and update that as well. I am sorry to ask if this is a very naive question. But your insight will help me a lot.

Just to add I tried the yarn add command with the version 11. I am getting success but then the yarn.lock file did not get updated.

[tame geyser]

No, you shouldn't do yarn add.

Understanding npm / yarn dependencies is a bit of a topic of its own. You may want to look into how hoisting works and what the lockfile is for.

The lockfile is a snapshot of resolutions - that is, given that some packages in here ask for version A, B, C, and D, we'll actually be using version E which matches all of those

If you do yarn add, you would be adding ANOTHER new desired version X, and you'd probably doing so in the wrong place (the root package.json) which actually isn't itself interested in having that dependency

the only thing that does is to risk triggering hoisting, where dependencies diverge and are split up into the individual packages instead of sharing a single one at the root