wholeheartedly yes; this addresses nearly all the concerns i had in my comment.
the only other concern is the ability and the added time to make changes to these dependencies. what this sometimes means in practice:
in terms of time: you may have to wait for upstream to accept your change. alternatively, one could maintain a fork of the package and replace the dependency to point to the fork while waiting for changes to be accepted, however doing so adds back-and-forth work.
in terms of ability: upstream may reject a change.
after the change is merged upstream, you are required to vet commits in the dependency between the last previously vetted commit and your currently merged commit, all at once, before you can upgrade the dependency in your original project.
the only other concern is the ability and the added time to make changes to these dependencies. what this sometimes means in practice:
in terms of time: you may have to wait for upstream to accept your change. alternatively, one could maintain a fork of the package and replace the dependency to point to the fork while waiting for changes to be accepted, however doing so adds back-and-forth work.
in terms of ability: upstream may reject a change.
after the change is merged upstream, you are required to vet commits in the dependency between the last previously vetted commit and your currently merged commit, all at once, before you can upgrade the dependency in your original project.