> Upon execution, the malware downloads and runs TruffleHog to scan the local machine, stealing sensitive information such as NPM Tokens, AWS/GCP/Azure credentials, and environment variables.

That's a wake up call to harden your operations. NPM Tokens, AWS/GCP/Azure credentials have no reason to be available in environments where packages may be installed. The same goes for sensitive environment variables.

▲

junon 6 hours ago | parent [-]

That's the goal, but it's not feasible in e.g. professional settings. Much easier said than done, unfortunately.

▲

venturecruelty 38 minutes ago | parent | next [-]

Sure it is: don't do it. It's not like there isn't automated tooling for this, but you can also like... I don't know, look at your diffs and not commit secrets? I've never committed a secret before, and I've been working with AWS for ten years now. But I don't "git commit -a" and I triple-check my diffs.

	▲	junon 5 minutes ago \| parent [-]
		Shai Hulud isn't about accidentally committing secrets, nobody is suggesting that's what's happening. Not sure which comment thread you're reading.

▲

throwawayffffas 2 hours ago | parent | prev | next [-]

I agree it's hard. But it's actually easier in professional settings. There are funds and you don't have an excuse to be lazy.

At minimum whatever you are working on should be built in docker. The package installation then would happen during the image build step. Yes it's easy to break out of the isolation environment but i am betting this malware does not.

NPM tokens should exist in some configuration/secret management solution not on your home directory. Devs have no business holding the NPM tokens. Same goes for sensitive environment variables they have no business existing on dev laptops or even the pipeline build steps (where package installation should happen).

AWS etc credentials / tokens are harder to secure since there are legit reasons for existing in dev laptops.

	▲	junon an hour ago \| parent [-]
		Docker is also not a silver bullet. Again, what you're claiming to be easy is often times exceedingly difficult or frictional, especially on established teams. I don't disagree that comparmentalization is important but security solutions are only as effective as their practical feasibility.

▲

codedokode 6 hours ago | parent | prev [-]

My code editor works in a sandbox. It's difficult because Linux doesn't provide it and one has to write it manually using shell scripts, random utilities. For example, I had also to write a limited FUSE emulation of /proc to allow code editor work without access to real /proc which contains lot of unnecessary information.

And if it's a "professional" setting, the company could hire a part-time developer for writing the sandbox.

	▲	bartmr 5 hours ago \| parent \| next [-]
		could you share with us those utilities? I've tried doing the same with AppArmor, but I ended up having endless warnings and weird bugs.
	▲	junon 5 hours ago \| parent \| prev [-]
		Good luck selling that to thousands of managers. That's my point. It's easy to list things that should be done. It's harder to get them greenlit.