81–90 of 145 posts
Earlier quoted context omitted.
Arguably crates.io is worse. NPM has cooldowns and has for a while, it has had Trusted Publishing for longer, it has human-approved releases that separate CI/CD from actual publishing. Ruby is probably worse in every way.
RubyGems actually adopted Trusted Publishing before both npm and crates.io. To my recollection, they were second after PyPI. (I have no opinion about the overall security posture of these indices.)
Earlier quoted context omitted.
RubyGems actually adopted Trusted Publishing before both npm and crates.io. To my recollection, they were second after PyPI. (I have no opinion about the overall security posture of these indices.)
No build script control though.
I am kind of surprised GitHub doesn't seem to have built a simple classifier for public repos to proactively lock the account of anyone uploading such obviously fishy things (for their own good, at least before the repo is publicly findable), so it can't be used as a rendezvous. Surely Github's software is good enough that an intern can slop the 80/20 together in a day? It would be an actually good use of AI spending…
GitHub announced this a while back: https://github.blog/changelog/2026-07-28-npm-publish-time-ma...
I am curious if they are still implementing the process or if this particular attacker already figured out a way around it.
Earlier quoted context omitted.
> if you want a better mitigation: don't automatically update dependencies in CI. At a minimum have a cooling-off period that you only bypass on manual review. This is not hard to implement and at least gives some time for alarm bells to be sounded before you're pwned. One of the problems a lot of companies are having right now is trying to determine a proper window size between CVE release and patching. On one hand,…
If you need quick responses to such things, you're gonna need some intelligence in the loop regardless, even if it's just deciding when it's worth pushing a new release to prod.
I mean that's a big window of time now.
Earlier quoted context omitted.
These half-measures is why everything has gone to shits. Instead of properly auditing software, reducing the quantity and increasing the quality, we keep pushing more and more garbage where all you find is 2FA that, captcha this, not supported this, app not signed, etc..
Defense in depth is the “meat and potatoes” of security. In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.
I also wrote an article (https://evertheylen.eu/p/shame-devs-without-isolation/) to flesh out my thoughts, but I'd be really happy to discuss this in the comments.
Earlier quoted context omitted.
If you need quick responses to such things, you're gonna need some intelligence in the loop regardless, even if it's just deciding when it's worth pushing a new release to prod.
What if it needs to get patched and pushed while you and everyone else in the org are asleep? I mean that's a big window of time now.
(If you find you do need updates when you're sleeping, you probably need to delegate that process or at least the process of checking the update to someone you trust, and you're probably paying for the service. This blog post is in large part an ad for just such a service).
Earlier quoted context omitted.
No build script control though.
Yep. That remains the norm with Python source distributions as well. It’s a hard thing to overcome when it’s baked deeply into packaging assumptions.
I just think the framing that npm is so bad is really flatly invalid.
Earlier quoted context omitted.
Defense in depth is the “meat and potatoes” of security. In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.
Defence in depth is not just 'throw anything in that might improve security' though. The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed. A stronger layer might be sandboxing, or separating your build and publishing steps as others have suggested (and also probably worth restricting the credentials the publishing step to just the relevant packages as well). These will…