91–100 of 191 posts
Very offtopic but this caught my eye: > Total repos cloned: 669 How big is this company? All the numbers I can find online suggest well below 100 people, and yet they have over 600 repos? Is that normal?
I beg to differ and look forward to running my own fiefdom where interpreter/JIT languages are banned in all forms.
>Running npm install is not negligence. Installing dependencies is not a security failure. The security failure is in an ecosystem that allows packages to run arbitrary code silently. No, your security failure is that you use a package manager that allows third-parties push arbitrary code into your product with no oversight. You only have "secutity" to the extent that you can trust the people who control those packag…
This is wildly circular logic!
"One person using these tools isn't bad security practice, the problem is that EVERYONE ELSE ["the ecosystem"] uses these tools and doesn't have higher standards!"
It should be no shock to anyone at this point that huge chunks of common developer tools have very poor security profiles. We've seen stories like this many times.
If you care, you need to actually care!
I have been thinking about this. How do I make my git setup on my laptop secure? Currently, I have my ssh key on the laptop, so if I want to push, I just use git push. And I have admin credentials for the org. How do I make it more secure?
> Running npm install is not negligence. I beg to differ and look forward to running my own fiefdom where interpreter/JIT languages are banned in all forms.
Earlier quoted context omitted.
I think the OP is aware of that and I agree with them that it’s bad practice despite how common it is. For example with AWS, you can use the AWS CLI to sign you in and that goes through the HTTPS auth flow to provide you with temporary access keys. Which means: 1. You don’t have any access keys in plain text 2. Even if your env vars are also stolen, those AWS keys expire within a few hours anyway. If the cloud servic…
> If the cloud service you’re using doesn’t support OIDC or any other ephemeral access keys, then you should store them encrypted. There’s numerous ways you can do this, from password managers to just using PGP/GPG directly. Just make sure you aren’t pasting them into your shell otherwise you’ll then have those keys in plain text in your .history file. This doesn't really help though, for a supply chain attack, becau…
(And that sort of ephemeral-login-for-aws-tooling-from-local-env is a standard part of compliance processes that I've gone through.)
Earlier quoted context omitted.
As mentioned in the article, good NPM package managers just do this now. pnpm does it by default, yarn can be configured. Not sure about npm itself.
Obviously blocking install scripts is a good thing, but this is just a false sense of security. If you install a package you will likely execute some code from it too, so the malware can just run then. And that is what the next attack will do as everyone starts using pnpm (or if npm blocks it too).
> Running npm install is not negligence. I beg to differ and look forward to running my own fiefdom where interpreter/JIT languages are banned in all forms.
It has nothing to do with interpreters or JIT, it has nothing to do with npm at all. All package managers have the insane security model of "arbitrary code execution with no constraints".
- a pnpm maintainer 1 year ago
Earlier quoted context omitted.
It wasn't in their product. It was just on a devs machine
I think the OP is aware of that and I agree with them that it’s bad practice despite how common it is. For example with AWS, you can use the AWS CLI to sign you in and that goes through the HTTPS auth flow to provide you with temporary access keys. Which means: 1. You don’t have any access keys in plain text 2. Even if your env vars are also stolen, those AWS keys expire within a few hours anyway. If the cloud servic…
That's not correct. The (ephemeral) keys are still available. Just do `aws configure export-credentials --profile `
Sure, they'll likely expire in 1-24 hours, but that can be more than enough for the attacker.
You also can try to limit the impact of the credentials by adding IP restrictions to the assumed role, but then the attacker can just proxy their requests through your machine.