Jack Poller
The "many eyes" myth is dead. Shai-Hulud, S1ngularity, and other attacks prove open source needs dedicated security teams, not just volunteers. AI-powered attackers are winning. Time to build something better.
Read my take here:
https://paradigmtechnica.com/2025/12/03/the-open-source-security-myth-why-many-eyes-arent-enough-anymore/
#opensource #security
Dec 3 at 2:00pmWeb
Show threadFrancesco P Lovergine Dec 3

@poller

404

Show threadJack PollerDec 3

@gisgeek should be fixed now.

Thanks for letting me know.

Show threadgreem (Graeme, not Graham)Dec 3
@poller That's a 404, skipper.
Show threadJack PollerDec 3
@greem fixed, thanks
Show threadgreem (Graeme, not Graham)Dec 3

@poller Interesting article, thanks.

In your list of "fundamental shift" items, there is one that stands above all the others: cash. As you assert, companies making billions based on OSS stacks cannot complain about insecurity if they never provide resources to deal with it.

I don't mean "pay the maintainers" necessarily, as a lot of them are already in that system/those companies anyway. What I mean is providing services back to the maintainers, for the good of all.

Show threadMcNeelyDec 3
@poller I don't think you're wrong I just don't expect anything to change for the better in the way you've identified. Too many projects and communities are just holding on right now 😕
Show threadJack PollerDec 3
@McNeely unfortunately, you're probably right, which is depressing.
Show threadFrancesco P Lovergine Dec 3
@poller
Nice read, but it's not only about security; it's also about the sustainability of FOSS projects. Too many hubs, no resources dedicated to maintaining them, and too many packages out there, often used in applications without any rationale for long-term maintenance.
Show threadFrancesco P Lovergine Dec 3
@poller And I find companies are often not better. Too many SSL-like projects out there that are maintained by a handful of people in their free time, but are used by multi-billion-dollar companies.
Show threadEpic NullDec 3

@poller Both those attacks emphasized weaknesses in Microsoft's Github Actions and NPM (also owned by Microsoft).

NPM's core design is deeply flawed, with no concept of sourcing controls and running arbitrary scripts by default.

Github has been pushing fine grained tokens for a while now, but has yet to make them actually usable - a reality which clearly would keep people from using them, and Github Actions is known to have a confusing security system.

Perhaps it's not "Open Source" that needs a security upgrade, but Microsoft.

Show threadJack PollerDec 3

@Epic_Null Yes, you're correct: NPM's core design is deeply flawed.

And that's my point. It's yet another open-source project built without any concern for security.

In the interest of space, I decided not to discuss the plethora of other open source compromises, such as the XZ / openSSH attack.

Show threadEpic NullDec 3

@poller

yet another open-source project built without any concern for security.

I think this falls apart though when you understand that it is owned by Microsoft. The "Embrace, Extend, Extinguish" company. They HAVE funding from Microsoft, which should by your argument make them immune to these issues... but yet these vulnerabilities come FROM these corporate managed components!

To make things worse, these corporate entities are engaging in adoption of LLMs - and while we aren't seeing more advanced techiques from LLMs (we are seeing developer fatigue, but that is a different topic), we are seeing lots of vulnerabilities IN LLMs.

The conversations we REALLY need to have are regarding Ownership and The Role Of Corporate Entities in Open Source. Because the roles thay Microsoft is currently playing (the single distributor of all Javascript packages?) Is not a healthy one, and having the initial checks run in Cloud rather than starting in the contributor's environment were practices that Microsoft's designs encouraged.

Show threadJack PollerDec 3

@Epic_Null Microsoft does bear some responsibility.

But recognize that NPM was born in 2010, capitalized in 2014, acquired by Github (Microsoft) in 2020.

So for the first 10 years of its life, it wasn't owned by Microsoft and it suffered from the all-too-common SOP of bolting security on as an afterthought.

And that's the major issue *I* am discussing: We -- as a community -- must focus on designing security from day 0.

Show threadEpic NullDec 3

@poller In terms of NPM's history:

NPM's problems were made worse by the impact of its response to the left-padd incident in 2016, after it was capitalized. Instead of making efforts to ensure "Same Publisher", they said "No deletions".

The "Everything" package incident was in 2024, which highlighted an issue with this model. Several issues actually, but we should focus on "If there is something critically wrong with a package, the problem cannot be resolved by the developer".

Essentially, NPM had a position of corporate control when it made mistakes and had warning - and NPM should have had the benefit of being a proprietary project at each of those times.

More importantly though

We -- as a community -- must focus on designing security from day 0.

This is probably not terribly practical (projects start because people want the ability to do things. Security gets added as understanding of the thing improves. Preferably added in a well integrated way), but perhaps more importantly - this is NOT the argument you made.

Security from day 0 is not "Hire a bunch of experts" - a very expensive task for little gain. It's security by design. It's "Understand scope", and "Be honest about what your community can handle, especially to yourself. If a major company is sending tons of security notices to you, refuse or demand payment, cause clearly they are using your tool in a way you can't support.".

Pretty much every "solution" you discussed involves a LOT of experts, and no consideration for structure (what do you expose), respecting the dependency project's scope, or being intentional about dependency upgrades (or dependencies themselves!). From my perspective, that is selling security as a product, not a mindset. Trying to turn software into corporate only, not resolving issues in Open Source.