See if there is an update on the first dependency on that tree for the vulnerability
First, check to see if update@0.7.4 has an update that solves this issue, if it exists, update it.
There is a possibility that update@0.7.4 doesn't have an update that resolves the issue because the owners yet didn't handle that vulnerability.
If there is no update on the first dependency that resolves it. (And the dependencies are open source)
Then you can start a process:
- Fork the repo that uses update@0.7.4, see if it's easy to clean that vulnerability by updating the second dependency. If it's easy, update it and now in your repo you will be using a reference to this fork instead of the original dependency. At this point it would be nice to also send a PR to the dependency in question if it is open source.
- If at this point there is no update yet that resolves the vulnerability, you will need to go one step below. And try to replicate step 1 with a dependency on the second level. This will probably lead you to use a fork of update@0.7.4, that points to a fork of assemble-core@0.25.0. If possible, you can also send a PR to fix the changes.
- Rinse and repeat until you can update it!
If the dependencies are not open source
Complain to the dependency that doesn't have the vulnerability update :)
Sad but true.
I do not recommend using a hack to have that transitive dependency updated in your repo only
Because the dependencies that use it may conflict with new versions of it or have unexpected problems.
Especially in this case because now it will have major (0=>1) change. Which means that probably there is a bunch of new things and breaking changes.