Cool down sounds good until everyone does it and the issue isn't caught until afterwards
Malicious npm packages detected across Red Hat Cloud Services
421–430 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#422About a week ago, I uninstalled Node from my laptop, which felt great. :) I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir. Cooldowns and allow-listing of installer scripts are good additions to layered security, espe…
Are you using something like Bubblewrap/Firejail/Flatpak, or what does such a setup look like? I've been entertaining a similar idea for a while but haven't gotten to it
Re: Malicious npm packages detected across Red Hat Cloud Services
#423Earlier quoted context omitted.
> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.
How often do you update your lockfiles? Where ever I have worked, it's once a year or whenever we get a critical CVE (in which case we only update the offending package and it's dependencies if required). Unless an attack is happening every day the chances of getting hit is slim.
Exactly.
Re: Malicious npm packages detected across Red Hat Cloud Services
#424Re: Malicious npm packages detected across Red Hat Cloud Services
#425In addition with my usual rant about the current situation with most devs that now want to use dependencies in prod almost the day that they are released, there is something else that I just realized.
A big part of the problem might be attributed to Github and the modern CI/CD frameworks.
Before, the source code was located somewhere, and the CI was usually located somewhere else, and slightly unrelated. At first, the CI job was to build ("privately") the artefacts, and they were manually released and deployed by maintainers and owner of software projects.
Then, it became the norm to have the CI located within the VCS file and the VCS located source code controlling the CI. For example having "script"/"description" of the CI actions located within the VCS itself.
Then, Github killed the CI/CD software market by offering "actions" almost for free and totally integrated within Github that was already widely used.
But still, for a long time people were wary to put tokens and security keys in Github and "public" CI/CD jobs and services.
And then, a few years ago, it became the gold standard also... You would look ridiculous to manually sign and deploy new releases with well guarded keys. What is expected from you is to have all your aws, github, ... secret api keys loaded in Github, and have your deployment and infrastructure provisioning automated with ("public") github accounts. All to be deployable in a second of a change being pushed.
So, obviously, the moment a hacker get control of a Github account or Github API keys, it is game over for the entire infrastructure.
Here I only referenced Github, but the bad things that it taught us became the norm and now these patterns are replicated everywhere (Gitlab, ...)
Re: Malicious npm packages detected across Red Hat Cloud Services
#426Earlier quoted context omitted.
I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
Because entire point of their work is to find the issues as fast as possible, and most importantly, before others.
You have a lot more faith than I do that companies paying security researchers will not try to cut corners by directing the researchers they employ or hire to look at stuff that they aren't even about to install.
Re: Malicious npm packages detected across Red Hat Cloud Services
#427GitHub repo (800+ stars) on a list of tips for protecting against npm supply chain attacks: https://github.com/bodadotsh/npm-security-best-practices
Re: Malicious npm packages detected across Red Hat Cloud Services
#428Earlier quoted context omitted.
What happens when everyone adopts this policy? You just change it to two weeks?
The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level. There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a t…
[dead]
Re: Malicious npm packages detected across Red Hat Cloud Services
#429Re: Malicious npm packages detected across Red Hat Cloud Services
#430Earlier quoted context omitted.
But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit o…
I don't understand why you're confident that those Github issues won't just end up coming later if literally everyone adds this cooldown
The security companies looking for and reporting the issues aren't going to use the cooldown too.