That is neither simple nor does it prevent some of the most common npm supply chain attacks (I think, no export with appamore). The most common attacks is to m

That is neither simple nor does it prevent some of the most common npm supply chain attacks (I think, no export with appamore). The most common attacks is to mess with thinks you build for release in ways which then allow attacking the consumer. For example by tweaking package, package lock, or even the source code. Only the last one is prevented here. Then there is also the thing that installing (user wide or even global) system utilities with npm is a thing, and wouldn't work with your apparmore profile (all need their own profile) Similar locally running node programs are an attack vector and your profile allow modifying the `node_modules` of such programs even if they don't use npm... Also you need root rights for loading profiles which can make having a profile for each project a problem as the dev doesn't necessary has root rights. (E.g. in a company with company managed desktop systems this is the default.) Don't get me wrong. I'm not saying you shouldn't use apparmore and other sandboxes. I even think it's the future of Linux. My point is appamore isn't simple and it's one of the most simple solutions out there. Or in other words we still have quite a way to go. And it's not just about doing sand-boxing, but also about managing sandboxed programs, e.g. last time I looked the app stores of both snap and flatpack where a horror-house of not-properly maintained packages with security vulnerabilities, as well as doggy potentially malicious "unofficial" packages. Even if you sandbox is perfect you still care about security, e.g. you don't want a openoffic package to send copies of all documents you use somewhere else... and that's if the sandbox if used (... flatpack ... facepalm).