131–140 of 329 posts
‘No way to prevent this’, Says Only Development Community Where This Regularly Happens — https://itnext.io/no-way-to-prevent-this-says-only-developme... >
Earlier quoted context omitted.
Third parties can detect compromised packages. It’s ridiculous Microsoft doesn’t.
They can and do indeed detect those attacks, it's just from Microsoft's POV a feature of Microsoft Defender (on Windows and Cloud) they sell: https://www.microsoft.com/en-us/security/blog/2025/12/09/sha... https://azure.microsoft.com/en-us/pricing/details/defender-f... So this is presumably why they will never address this in npm itself.
What a wonderful marketing opportunity! Leave it to Microsoft to blindly ignore it.
I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few ti…
> Docker Container Escape > The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods: So even if you're running devcontainers / VMs, these worms are already trying to escape. Make sure you're running a rootless VM engine (e.g. podman instead of docker) !
Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especiall…
Earlier quoted context omitted.
Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especiall…
> Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. Solaris Zones and FreeBSD Jails (their inspiration) also share a kernel with the running system and do not seem to have as many escape vulnerabilities. (Though partly because there may not be as much scrutiny of c…
I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few ti…
It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.
I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few ti…
It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.
‘No way to prevent this’, Says Only Development Community Where This Regularly Happens — https://itnext.io/no-way-to-prevent-this-says-only-developme... >
I'm very glad I never bought into fullstack JS/TS. My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few ti…
Where does that compilation happen again? Not on the front end and it happens exactly where the exploits have been targeting (dev and build boxes).