Package Managers need global hooks

>Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive.

Defense in depth and multiple redundant layers is a legitimate technique.

But it should usually be 2 virtually unbreachable layers, like 99.999% effective, because there may be a memory leak somewhere and it will be exploited once per year or so. Because 1 layer is just shy of 100%, 2 layers is already overkill, we would do 1.1 layers if possible (but of course it's not)

Maybe if it's a multibillion dollar product you'd add a third or more impenetrable layers.

And once you have those two redundant security layers, then you add deterrents and monitors, if you want.

But relying on security measures that will maybe catch 20% of attacks or 40% of attacks as a main mechanism will lead to what some have described as swiss-cheese models. https://en.wikipedia.org/wiki/Swiss_cheese_model

So yes, sometimes you can add a cheap measure that might make things more difficult to an attacker, on top of your main line of defense, then do it. But keyword cheap, if it takes 2 minutes like using a custom port, yeah for sure do that, but if you have to write an article and invent a new theory of hooks, then it's not it.

Antivirus techniques are not used by serious development professionals that I know of, I've seen it used in IT contexts were there's non technical users that might download stuff, but even then it's not really a central technique, just something that security firms sell to non-technical execs. And it's in the context of sys admins trying to control the security environment of hundreds of employees whose actions they cannot control. In the context of developers who have to ensure the security of systems they have code for, you do not need these faith based techniques, you are importing the code, you have access to it, and you have the time resources to inspect it. These antivirus technologies are used either by personal end users that don't have the ability to verify the software or audit its source, or for IT departments that cannot even inspect the contents and packets of the software their employees are using for security reasons.

> No one looks at Debian and is saying "well maybe we should do what they do"...

You mean that having mature community with maintainers checking subscriptions and a "testing" channel where stuff only lands after few weeks of no problems is useful ? Who could possibly imagine!?

Industry's gonna NIH

> Ok big problem is lots of stuff installed for campaigns wasn't flagged in any feed. If maintainer access is taken over you still don't have any feed info, maybe it will be a bit faster to publish so if maintainer finds out.

Technically at the very least company could throw their feed to AI and at least get some automated screening on the changes between versions

Let's not forget, in the majority of cases in Debian, the packager is not the software author. It's an independent volunteer, vetted by a community of such volunteers.

This is an incredibly useful, I'd say essential, firewall. I really don't like the Windows/macOS approach of "just do everything yourself, we'll do nothing", and likewise the npm et al approach of there being a fully automated package registry which merely distributes packages to millions of people, and leaves the onus on the software author for when to publish and what to publish.

A drive-by script could trigger some CI via a developer's credentials to publish a new version. If the outcome of that is it merely sends an email to a second person, who might get around to looking at it, and will likely look at the diffs, have to write up what the changes are, and might email back... that's a hell of a lot better than push straight to prod

We still have the problem of Debian developers being free to push their own changes, and a suitably knowledgeable one could hide stuff from the various automated testing and analyses they face, but even then they face pushback from real testers, and if caught pushing malware they'd lose their prestigious volunteer position of trust instantly.

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...

People are disregarding model where registry is responsible for what they publish.

Your solution does exactly that. Giving hooks to end users just pushes the responsibility to the users.

Yes all issues were publicized and marked in hours. Sorry but hours is not good enough when there is countless CI pipelines running in a single hour.

Only solution is not allowing to publish malicious stuff. Cooldowns are also not the solution because possibilities to publish malicious code is still there if no one reviews it.