Containers can help to prevent some attack scenarios, ie by making it easier to "re-deploy" a container that has had all of it's files deleted, but they don't "

Containers can help to prevent some attack scenarios, ie by making it easier to "re-deploy" a container that has had all of it's files deleted, but they don't "sandbox" code very effectively against a sophisticated attack. For example: If you install a package that generates a random UUID, and that package has malware added to it silently, that package can do _anything_ that your backend code can do. Would you expect your random UUID library to make a network call out to a server and then open up a Bash shell to let somebody execute arbitrary commands? Containers don't help prevent that scenario. The only way to "fix" that is to _limit_ the default permissions of a library to be something sane. Maybe this UUID library is allowed to have filesystem access to read `/dev/urandom` but not to read `~/.ssh/id_rsa`. The default Node runtime does not provide any mechanism to whitelist or filter what privileges a module requires. Adding that capability would require major changes to the entire ecosystem (like every package adding a "permissions" manifest file).