> Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)?
Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period.
For the long tail of stuff that makes it into GitHub, you need to do some combination of heuristics on the commits/maintainers and AI-driven analysis of the code change itself. Typically run that and then flag for human review.
Hmm, we just bought my wife an annual subscription at the Pro tier, largely to use Claude Code. Wonder if she'd be grandfathered in or if we'll need to get a refund.
Do any of the bug bounty programs let you filter by some scoring of the source reporter?
Seems like it’d be helpful to bury mass reporters in a de facto spam bucket (where “mass” is some absolute quantity of reports along with percent that are accepted).
Chainguard | Senior and Staff-level Product Managers and Engineers, and Engineering Managers | REMOTE (US/CAN)
We're building the safe, trusted source for open source. We created the secure Container Image market and we've recently expanded into VMs and Libraries for popular language ecosystems such as JavaScript, Python, and Java.
We're hiring quite a few PMs and engineers for our Containers and Libraries products, amongst other roles. Check out the listings here https://www.chainguard.dev/careers and if you're a highly-technical PM that wants to SHIP email me directly at patrick at chainguard dot dev.
It's the same principle as a company blocking access to domains registered in the past 30 days. Doing so eliminates a huge percent of phishing/malware as these domains are typically identified and taken down otherwise blocked in that window.
In this particular case, the bogus libraries had been out there for months. But if in addition to a delay, you mirror just the most common subset of packages with some opinionated selection criteria and build directly from source, you eliminate most of these attacks. (The same is true across whatever language ecosystems, including JS as you mention npm, etc.)
Is this 100% infallible? No, but security is a risk reduction game.
We're taking a very different[1] approach at Chainguard.
Essentially: building the world from GitHub repos on SLSA L2 hardened infra and delivering directly to our customers to bypass the registry threat vector (which is where vast, vast majority of attacks occur—we'll be blogging about this soon with more data).
We're primarily an AWS shop but some Oracle BDR assigned to cover us recently reached out on LinkedIn.
I asked for an incident report and received this terse response:
> There has been no breach of Oracle Cloud. The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data.
I remember calling Clint and Jeremy at DigiCert and asking: "hey we have this cool IP address—what are the odds you guys can issue a certificate for it?"
I'm not sure if they had to dust off some code or process to do it, but they got it done really quickly once the demonstration of control was handled.