Virtually every non-trivial program pulls in third-party libraries. As we, as software/security engineers, have no time to carefully review every third-party library (and its dependencies, and transitive dependencies), we implicitly put a lot of trust in these third-party libraries.
This doesn’t always work out well: think of the event-stream disaster.
If an application can access the filesystem, then the third-party libraries can too, because the filesystem is virtually always globally available.
It is typically not possible to give restricted access to a third-party library.
Sandboxing doesn’t solve this problem, because if your application has access to the filesystem, all (transitively) dependent packages automatically have access to the filesystem as well.
A solution would be to not make the filesystem globally available, but only in the application’s entry point, and allow a reference to the filesystem to be passed to functions (including ones in third-party libraries) that need it.
This is dependency injection used from a security angle.
This way, a third-party library would only be able to access the filesystem when it is explicitly passed in. A third-party library wouldn’t by default be able to encrypt your hard drive or read your Bitcoin wallet.
This could be made more fine-grained: rather than injecting a reference to the entire filesystem, a reference to a directory or to a specific file could be injected. This way, a third-party library could be granted limited access to exactly what it needs to operate properly.