I'm the guy that built the antimiasma discovery and mitigation tool [1] and has seen a lot of the evolved and ever-changing malware samples (17 unique deobfuscated samples with different code branches and adapters/functions/features), so I feel somewhat qualified to respond to this.

The problem of everchanging malware isn't fixable by global policies and global rulesets. Package managers need to change to different workflows in the package publishing process.

1. Reproducible builds have to be mandatory

2. Deployed packages have no execution or network capability at install time

3. If package artifacts differ from source artifacts, block it temporarily

4. In order to defend against credentials harvesting: Package managers need to have mandatory container or sandbox isolation (mandatory bubblewrap, podman, or whatever isolation that segregates filesystems and networking)

5. In order to defend against github being abused as a C2 infrastructure: Package managers need to have locked behavioral rulesets of packages, "allow filesystem" or "allow networking" is useless, and needs to be per-resource. Additionally, it needs to be a mandatory allowlist-only enforcement. If it's allowed by default, it won't help with the transitive dependencies problem

6. Introduced transitive dependencies need to be locked and signed by the package repository authority.

7. In order to defend against eBPF Rootkit: Sorry, you're just f'cked. The only EDR on the market that defends against this attack surface is literally my own product (that I won't advertise here). Every other available tooling is just too outdated in how it has been developed, and too outdated how it's doing behavioral analytics of malware.

---

My personal take on this:

Pretty much every developer thinks this isn't necessary and is probably gonna downvote me for telling the security perspective here. This is not about what's necessary, this is about what's broken.

Our existing DevOps and DevSecOps culture and the involved incident response/supply chain security/GRC/etc workflows are absolutely broken against these reoccurring supply chain attacks, and the tooling that promised to catch this is also absolutely broken and useless against mutating malware that's co-generated by LLMs.

The only ones actually re-identifying the malware implants as miasma malware samples correctly were the socket.dev folks. Every other supply chain tool vendor was just bragging about a new malware campaign because they weren't up to speed and seemingly didn't know about the initial miasma campaigns (and the prototype campaign targeting RedHat's NPM packages with the gyp bindings).

Microsoft was so useless in its incident response workflow that they tried to mitigate the problem by making VSCode extension installs with a required delay time, not even having understood how the malware implants work, and not even having understood what the actual spread vector was.

It's like Microsoft had to press a red button just for the sake of having done anything, instead of openly communicating and advising to ongoing malware attacks, sharing intelligence and samples; and in consequence leaving every customer of Microsoft in the dark, getting compromised in the process, too.

[1] https://github.com/cookiengineer/antimiasma

[2] https://cookie.engineer/weblog/articles/malware-insights-mia...

1. Seems hard but doable (assuming there is some way to inject "inputs" into the build process, that can be recorded). However, I'm not sure exactly what you mean by a build here? Many package managers do not distribute binaries at all, so what is being reproduced?

2. Codegen is extremely common (serialisation, reflection, bindings, etc.) to the extent that even requiring a whitelist of packages that can do code-gen seems like a non-starter (because everyone will just whitelist everything). Sandboxing build-time execution seems like a more practical approach than denying it.

3. It's not clear to me that this distinction is meaningful for many package managers. Crates.io for example distributes a packaged set of sources. What are you comparing these against? There's no requirement that the original sources be hosted anywhere public, and I definitely don't think it should be mandating use of GitHub or anything.

4. Needs to be a whitelist rather than mandatory, but yes.

5. Yes, with the caveat below.

6. What do you mean by "locked"? You cannot lock transitive dependencies and still have a usable package infrastructure. If I have packages A and B that both depend on C, then it's critical that the version of C used is maximally flexible, otherwise it becomes impossible for downstream packages to find a version of A and B that are inter-compatible.

In my experience there's a danger for security experts to neglect the practical consequences of the limitations they enforce. This is because they incorrectly place security as the most important requirement, when by definition it cannot be:

Without a product, there is nothing to secure. When a policy becomes too onerous, people don't simply stop doing their work, they work around it. It's a mistake to judge a security policy on what it prevents: a security policy should be judged on what it allows, because an unused or bypassed security policy is less effective than a weak one.

This is why I think thinks like sandboxed execution far more effective than trying to blanket deny things: it enables people to work in a more secure way rather than pushing them towards less secure alternatives. It's why the best way to get people to use secure cryptographic libraries is not just to berate them for doing things themselves, it's to build secure libraries that they want to use because they work well and are ergonomic.