alt.hn

1/13/2025 at 10:38:27 PM

Snyk security researcher deploys malicious NPM packages targeting cursor.com

 https://sourcecodered.com/snyk-malicious-npm-package/

by arkadiyt

1/14/2025 at 2:48:07 AM

[EDIT: See the response by a Cursor dev below — looks like it was not authorized by them]

Sounds to me like Cursor internally has a private NPM registry with those packages. Because of how NPM works, it's quite easy to trick it to fetch the packages from the public registry instead, which could be used by an attacker [0].

Assumably, this Snyk employee either found or suspected that some part of Cursor's build is misconfigured as above, and uploaded those packages as a POC. (Given the package description "for Cursor", I'd think they were hired for this purpose.)

If that's the case, then there's not much to see here. The security researcher couldn't have used a private NPM registry to perform the POC if the point is to demonstrate a misconfiguration which skips the private registry.

.

[0] In particular, many proxies will choose the public over the private registry if the latest package version is higher: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

by n2d4

1/14/2025 at 3:26:53 AM

cursor dev here. reasonable assumptions, but not quite the case. the snyk packages are just the names of our bundled extensions, which we never package nor upload to any registry. (we do it just like how VS Code does it: https://github.com/microsoft/vscode/tree/main/extensions)

we did not hire snyk, but we reached out to them after seeing this and they apologized. we did not get any confirmation of what exactly they were trying to do here (but i think your explanation that someone there suspected a dependency confusion vulnerability is plausible. though it's pretty irresponsible imo to do that on public npm and actually sending up the env variables)

by ArVID220u

1/14/2025 at 4:56:33 AM

> "pretty irresponsible"

Wouldn't it be more like "pretty illegal"? They could have simply used body: JSON.stringify("worked"), i.e. not sent target machines’ actual environment variables, including keys.

by nomilk

1/14/2025 at 7:56:05 AM

It's an unfortunate incentive structure. If you're doing offensive security research, there's two ways you can go about it: you can report the potential vulnerability without exploiting it, in which case you risk the company coming back to you and saying "thanks but we don't consider this a vulnerability because it's only exploited through misconfiguration and we're too smart for that". Maybe you get some token reward of $50.

Or you can exploit it and say here's the PoC, this many people at your company fell for it, and this is some of the valuable data I got, including some tokens you'll have to rotate. This puts you into actual bug bounty territory. Certainly the PR side of things alone will incentivize them to pay you so you don't make too much of a noise about how Cursor leaked a bunch of credentials due to a misconfiguration that surely every good programmer knows about and defends against (like so many vulnerabilities seem so dumb in hindsight).

by reubenmorais

1/14/2025 at 11:45:42 AM

Cursor does not have a bug bounty though, and its hard to see how this constitutes anything other than a direct attack on them, their users, or both. "The incentive structure made me do it" does not justify acting like a criminal.

by xmodem

1/14/2025 at 1:22:33 PM

Cursor asks researchers to report vulnerabilities to their GitHub security page.

The same incentive to show impact applies even without a paid bounty.

by grajaganDev

1/14/2025 at 1:12:26 PM

> Cursor does not have a bug bounty

Shouldn't this alone be considered criminal negligence at this point? Cursor isn't some random open source project. It's a company that has funding, and subscriptions. Hell, I pay Cursor for a monthly subscription. Pretty incredible that they have no bounty program.

by px43

1/14/2025 at 1:35:09 PM

The lack of a bug bounty program doesn't prohibit them from rewarding reported vulnerabilities.

by britannio

1/14/2025 at 5:19:12 PM

do they though?

by taskforcegemini

1/14/2025 at 10:43:18 AM

You can also console.log those credentials as a PoC, and then show that the console.log could trivially be replaced by a fetch().

Kind of like a lot of exploit PoCs just "pop a calc" (AKA open the Calculator app), not because opening the calculator is valuable to an attacker, but because if you can open calculator, you can do anything.

by miki123211

1/14/2025 at 1:00:25 PM

The problem there though, is that with PoCs like this, as an attacker you want to have a ping back to your system so that you know the attack has been successful (in this case they probably expected/hoped someone at Cursor to install the package, that's the usual objective in a dependency confusion attack). But what they could have done, is send a less sensitive thing like just the current working directory or current effective user, instead of the whole environment.

by objectified

1/14/2025 at 2:50:08 PM

What actually changes though in your scenario? Potential bad actor gets RCE on your dev machines, it doesn't really matter what they sent home, you're rotating keys and doing your due diligence either way.

by fkyoureadthedoc

1/14/2025 at 9:14:50 AM

I wonder how viable it would be to find a public key your target owns and use it to encrypt the data you send back. Then you could prove to them that you exfiltrated real data without exposing it to anyone outside the company.

Alternatively, you could hash it and say “Look, it’s a sha of your database password hyphen “yougotpwnd””

by mistercow

1/14/2025 at 11:59:56 AM

HTTPS certificates should already have that public key for you, so it should be trivial.

by necovek

1/14/2025 at 12:03:16 PM

wouldn't capturing only env names without values be ideal middle ground?

look we had access to your Aws tokens, we could take over your account but we didn't steal actual token, we just got proof that we could access it

by Szpadel

1/14/2025 at 5:37:44 PM

Yes I agree names only would have been a better approach here.

by reubenmorais

1/14/2025 at 8:27:17 AM

Yeah, I agree the incentive structure is broken for bug bounty hunters. Until the BB platforms themselves create some rules for their customers and researchers, we are gonna continue to have the sh*t show that we do now. The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.

by 6mile

1/14/2025 at 9:42:30 AM

> The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.

I don't actually think that is a bad thing.

The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was large enough that they could practice more often. The system could improve if it had actual feedback on how accurate and effective it was. And instead of agents overreacting or underreacting they could tune their responses to an appropriate level.

The same applies to supply chain attacks. The REAL ones are rare, dangerous, and performed by experts; having a chance to practice catching them, to assess our detection rates, and to adjust our reactions is healthy.

by mcherm

1/14/2025 at 4:02:59 PM

a prerequisite of “offensive security research” is that it is solicited, no ifs or buts.

what they did was absolutely wrong and frankly likely illegal

by whimsicalism

1/14/2025 at 9:14:31 AM

Yeah, it sucks, but that's the way it is. It is super common for bug bounty findings to be ignored or downgraded unless you show actual code exec on their machines or dump some of their creds.

by peanut-walrus

1/14/2025 at 10:29:02 AM

It may interest you that Guy Podjarny, one of the Snyk founders, now has an AI coding company (https://www.tessl.io/about) that looks like a competitor of yours

by DigitalNoumena

1/14/2025 at 4:37:37 AM

[flagged]

by IAmGraydon

1/14/2025 at 5:32:00 AM

It was a thing back in the late 90s. I still do it in casual conversations with friends, less so in professional settings.

It's a gen X thing, like using "lol" to mean literal laughter

by not_a_bot_4sho

1/14/2025 at 5:51:21 AM

it's been a thing at least on irc for at least 20 years. i've been used to it for a long time.

by johnny22

1/14/2025 at 5:01:55 AM

I like to call it informal case.

by dovin

1/14/2025 at 5:42:50 AM

When I grew up online in the 90s, on IRC, AOL/AIM, ICQ and web forums, it was extremely common. Most of the people I know from then still do it, and I still do it with them and in many other places, although for whatever reason I don't do it here. Although it's 50/50 when on their phones now that phones auto-capitalize by default now.

by furyofantares

1/14/2025 at 6:37:11 AM

Rules are put in place to be followed, for a reason. Capital letters at the start of the sentence increase readability. People who don't bother with them are being incosiderate towards their readers.

by urig

1/14/2025 at 8:09:25 AM

not at all

by wahnfrieden

1/14/2025 at 5:33:16 AM

yes but there could be many possible reasons, for instance

- it's muuch faster on mobile

- you're aiming to convey litheness to potential target audiences who will know to recognize it as intentional litheness

- you've gotten used to minimizing the amount of keystrokes necessary for communicating things, to the point it's second nature

- you've worked a lot in the past with older nlp systems, where ignoring capitalization was a given for inputs anyhow, and just got used to treating it as syntactic cruft only strictly necessary in more formal settings ;)

by pizza

1/14/2025 at 6:46:53 AM

With the current default mobile keyboards, I'd guess it's slower, not faster.

by cjbprime

1/14/2025 at 7:08:16 AM

> it's muuch faster on mobile

This isn’t 1998. Mobile keyboards autocapitalize. You have to go out of your way to avoid capitalization on mobile.

by stouset

1/14/2025 at 6:46:24 AM

I have been thinking of this too. I find it super annoying to read and it looks unprofessional.

by Piisamirotta

1/14/2025 at 7:09:06 AM

how does this bother you, what greater meaning does it have?

by demarq

1/16/2025 at 12:27:05 AM

I tend to shy away from intentional illiteracy and laziness, both of which this is an example of. Not capitalizing does also affect readability. That said, I was honestly asking because I’ve seen it a few times on HN in the last couple of weeks and was curious if it’s coincidence or an actual trend.

by IAmGraydon

1/14/2025 at 4:43:20 AM

It’s a techbro thing.

Sama does it too

by Atotalnoob

1/14/2025 at 5:02:35 AM

You're writing in rust-inspired English it seems, omitting the punctuation mark at the end of your second sentence so it gets returned.

by benatkin

1/14/2025 at 5:07:31 AM

it's typesafe and efficient

by compootr

1/14/2025 at 5:42:49 AM

e. e. cummings, techbro. who knew?

by brookst

1/14/2025 at 5:29:44 AM

It’s a low effort flex. As in: you’re unimportant, this is unimportant, and I’m very busy, so I can’t or won’t bother to capitalize. Which is ironic because it’s more effort to not capitalize.

by mmaunder

1/14/2025 at 8:10:44 AM

it's many more keypresses, and using modifier keys is generally rsi-prone

by wahnfrieden

1/14/2025 at 8:39:44 AM

Without commenting on this subthread (I don't have an opinion), you or anyone else with this concern should look into sticky modifiers (modifiers that apply to the next key press without being held). They were a game changer for me personally as far as managing RSI, as I had a bad habit of tilting my wrist to eg type a capital T.

by maxbond

1/17/2025 at 1:06:36 AM

I use thumb keys (Glove80) which helps but I need to give that a try too

by wahnfrieden

1/14/2025 at 3:31:57 AM

[flagged]

by syndicatedjelly

1/14/2025 at 4:06:03 AM

Yeah, I strongly disagree with the way it's characterized here.

by benatkin

1/14/2025 at 4:17:32 AM

> we reached out to them after seeing this and they apologized.

How does this make it sound like they made Snyk apologize?

by TimTheTinker

1/14/2025 at 3:20:24 AM

> If that's the case, then there's not much to see here

They could have demonstrated the POC without sending data about the installing host, including all your environment variables, upstream. That seems like crossing the line

by arkadiyt

1/14/2025 at 3:30:25 AM

> If that's the case, then there's not much to see here.

Allowing someone full access to the contents of your environment (i.e. output of env command) is a big deal to most, I suspect.

by nomilk

1/14/2025 at 4:49:02 PM

If /proc is mounted you can read all of that.

by LtWorf

1/14/2025 at 8:16:44 PM

Hey there! I run DevRel & SecRel @ Snyk, we just published a piece to help dispel all the rumors, etc. This provides a lot of in-depth info on the situation: https://snyk.io/blog/snyk-security-labs-testing-update-curso...

by rdegges

1/14/2025 at 11:38:49 PM

This response doesn't make a lot of sense.

What's the justification for taking all of the environment variables? This post tries to paper over that particular problem. If your goal was to see if you could attack the dependency chain the first steps of user+hostname would have been sufficient to prove your case.

Taking the environment variables is about taking the secrets, and kind of moves this from PoC to opposition supply chain attack. Not to mention it's not only Cursor devs that would be affected by this, it could have (if your plan worked) attacked anyone using the extensions.

It's also a tough buy given the note about the Snyk cofounder moving to compete directly with Cursor (courtesy @tankster): https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...

Assuming truly innocent motivations, you guys still need to give your heads a shake and rethink your approaches here.

by BeefWellington

1/15/2025 at 3:24:27 PM

Frankly I wouldn't be surprised if this was a case of Hanlon's razor. Some "researcher" thought well ENV vars will certainly show us what we want and that's where the conversation ended without thinking a little harder into what else might be in the vars.

by bangaladore

1/16/2025 at 4:34:05 PM

That's not really plausible in the modern legislative environment (pun intended), considering your env vars will contain GDPR-controlled data like your username, at the very least. Combined with the IP address it was collected from, they know who you are and where you live.

by neonerosion

1/16/2025 at 4:32:47 PM

The few details given in this response don't match up with what happened.

Who did the GDPR review before extracting env vars from systems that were not under your control? How did actively extracting potentially private data from the environment not get flagged as Unauthorized Access?

If this "experiment" (which happened to be against a competitor, mind) was reviewed and approved internally, that is a great demonstration of Snyk's approach to (ir)responsible data collection and disclosure.

by neonerosion

1/14/2025 at 7:02:26 AM

Wasn't this supposed to be fixed in NPM? I remember a talk by the researcher behind portswigger (sorry blanking on his name) doing this a while back, with great success (apple,ms,meta, basically all faang were vulnerable at that time).

by NitpickLawyer

1/14/2025 at 3:08:38 AM

I need to get serious about doing all development inside a virtual machine. One project per VM. There are just too many insidious ways in which I can ignorantly slip up such that I compromise my security. My only solace is that I am a nobody without secrets or a fortune to steal.

IDEs, plugins, development utilities, language libraries, OS packages, etc. So much code that I take on blind faith.

by 3eb7988a1663

1/14/2025 at 3:41:30 AM

Vagrant’s popularity seems to have died down with Docker containers but it’s by far my favorite way to make dev environments.

Several years ago I worked somewhere that prohibited web browsers and development tools on laptops. If you needed to use a browser, you’d have to use one over Citrix. If you needed to code, you’d use a VDI or run the tools in a VM.

At the time I thought their approach was clinically insane, but I’m slowly starting to appreciate it.

by redserk

1/14/2025 at 6:19:27 AM

I still like Vagrant. But I believe it's yet another victim of the Hashicorp license change debacle from a year or two ago.

Unlike with Terraform/OpenBao, I know of no community effort effort to keep the open-source version of this project alive. The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.

by arcanemachiner

1/14/2025 at 1:26:44 PM

> I still like Vagrant. But I believe it's yet another victim of the Hashicorp license change debacle from a year or two ago.

The license change is irrelevant - from the licensing page:

> All non-production uses are permitted.

Devs who use Vagrant in a development environment can do it as they used to do it before.

> The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.

Hashicorp products have always been intended to be downloaded from the website, since they're statically linked binaries (I don't like that they're huge, but matter of factually, they make distribution trivial).

by pizza234

1/14/2025 at 7:23:24 AM

more so a victim of speed

by fancyswimtime

1/14/2025 at 4:05:00 AM

This is the practice in many government sites these days.

Except the vm is some old windows version without any tools on it. no shell access.

can't actually do anything useful on there at all.

VDI systems could work if implemented properly. but that's the last thing a security team actually wants to do.

by tacticus

1/14/2025 at 7:43:21 AM

VDI is actually preferred by our security teams, because they have complete deep packet inspection on literally all traffic going in and out.

On our laptops, there are still some flows that avoid the vpn etc..

by dacryn

1/14/2025 at 5:43:22 AM

A customer of mine still uses vagrant on a project, for local development. That project started in 2016. We are developing on a mix of Linux, Mac, Windows and it's not as straightforward as it could be. Linux is easier, Windows is messier.

A newer project fires up VMs from a Python script that calls an adapter for EC2 (with the boto library) when run on AWs and for VirtualBox (by calling VBoxManage) when running locally. That allows us to simulate EC2 locally: it's a project that has to deal with many long jobs so we start VMs for them and terminate the VMs when the jobs are done. That also runs better on our mix of development systems. WSL2 helped to ease the pains of developing on Windows. We call the native Windows VirtualBox, not the one we could have installed inside WSL2, but we keep most of the code that runs on Linux.

by pmontra

1/14/2025 at 10:53:59 AM

Devcontainers[1] are the new incarnation of this pattern. We use them at work and they are a dream for onboarding new developers. The only downside is the VSCode lock-in but if that's a concern there's always DevPod[2].

[1] https://containers.dev/

[2] https://devpod.sh/

by hresvelgr

1/14/2025 at 12:35:18 PM

It looks like the team behind it have been moving it towards more of an open standard over the last year. There's now a CLI reference implementation, and the Jetbrains IDE's have an implementation for it.

There's also a thread for Zed about a path to implementing it there [0]. Hopefully it'll become a bit more common over 2025.

[0] - https://github.com/zed-industries/zed/issues/11473

by bluehatbrit

1/14/2025 at 12:45:44 PM

I think vs code is the easiest way to set up dev containers, but once they are created I mostly just shell into them and use neovim!

by roland35

1/14/2025 at 7:39:07 AM

At my first job almost 10 years ago we had the concept of "X-in-a-box" using Vagrant + VMs and I miss that pattern so much ever since (multiple job skips later).

None of my jobs since have had any semblance of a better way to set up a local dev environment easily.

It was just way easier to encapsulate services or other things in a quickly reproducible state.

I digress..

by spike021

1/14/2025 at 11:52:43 AM

I started using Ansible a few years back to set up VMs (or Raspberry Pis) with a consistent environment. Once I wrapped my head around it, I've found it very nice for any situation where I need to treat systems as livestock rather than pets.

by flyinghamster

1/14/2025 at 5:39:45 PM

I use Ansible in local only mode to install/configure macOS as a development environment.

Works well with Homebrew, and copies all the config files that devs often don't set up.

by bloopernova

1/14/2025 at 7:07:20 PM

> At the time I thought their approach was clinically insane

Let’s be clear, it’s still clinically insane, even if marginally rationalized.

by jsjohnst

1/14/2025 at 4:38:04 AM

Vagrant is still kicking! But yeah not as popular as back in 2014-2016?

A hybrid(?) alternative is enroot, which is pretty neat IMO, it converts a docker container into a squashfs file that can be mounted rw or used in an ephemeral way. https://github.com/NVIDIA/enroot

by buildbot

1/14/2025 at 5:08:03 AM

The real problem is video performance in VMs. It still just...kind of sucks. Running Cinnamon in a VM is just about impossible to get GL acceleration working properly.

nvidia gates it's virtualized GPU offerings behind their enterprise cards, so we're left with ineffective command translation.

IMO: I can tolerate just about every other type of VM overhead, but choppy/unresponsive GUIs have a surprisingly bad ergonomic effect (and somehow leak into the performance of everything else).

If we could get that fixed, at least amongst Linux-on-Linux virtualization, I think virtualizing everything would be a much more tenable option.

by XorNot

1/14/2025 at 9:47:32 AM

There are ways around it. There is a community of people who use Nvidia enterprise cards with vGPU for gaming, performance is excellent, or PCI pass through an entire GPU.

If you can't do that because it's for company/corporate purposes then I can sympathise with not wanting to pay Nvidia's prices.

by alias_neo

1/14/2025 at 7:19:10 AM

You can get good security without virtualization, for example SeLinux and namespaces in Linux. Jails in BSD and zones in Solaris. We would have many viable and competing solutions if it wasn't for Microsoft monopoly.

by z3t4

1/14/2025 at 12:49:47 PM

But would it matter much for development? Either SSH into the VM and use vi/emacs or use an IDE/editor with remote support. VS Code even lets you use a container as a development environment (I know, not a VM by default):

https://code.visualstudio.com/docs/devcontainers/containers

by danieldk

1/14/2025 at 1:42:21 PM

I don't know about VS Code's dev containers extension but the SSH extension's README says:

> Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

If you're worried about extensions there's also:

> When a user installs an extension, VS Code automatically installs it to the correct location based on its kind. If an extension can run as either kind, VS Code will attempt to choose the optimal one for the situation;

https://code.visualstudio.com/api/advanced-topics/remote-ext...

by dsissitka

1/14/2025 at 6:43:29 AM

It's horrible that trust is being eroded so much, and seeing monthly GB updates to my OS doesnt reassure me at all. I like the idea of having a stable isolated VM for each project. Are there standard open-source tools to do this?

Specifically I'm transitioning my Go and Zig development environments from an old mac to an M1 with Asahi Linux and getting a bit lost even finding replacements for Truecrypt and Little Snitch. Do these VM tools support encrypted VM's with firewall rules? I saw Vagrant mentioned here and that sounds like it might cover the network isolation, but what else would you suggest?

by whitehexagon

1/14/2025 at 7:06:37 AM

I run all my dev environments under LXD. Even the IDE: full graphical Emacs (or Vim) over X11 forwarding over SSH. Host is Wayland, so security concerns with X are handled. WayPipe also works, but is jankier than X, probably because X, unlike Wayland, was designed for network transparency.

LXD, unlike Docker, doesn't play fast-and-loose with security. It runs rootless by default, and I don't allow non-root access to the LXD socket on host. Each container is a full userspace, so it's much more convenient to configure and use than Dockerfiles.

SSH from a container to a remote works transparently because I forward my SSH Agent. This is secure because my agent confirms each signing request with a GUI popup (on host).

by pritambaral

1/14/2025 at 8:37:34 AM

Can you point to a write-up somewhere that details this setup?

Part of the appeals of VMs is that they were built with security as a primary objective. I probably have to do something stupid to break that isolation. A custom ad hoc configuration makes me a bit nervous that I will unknowingly punch a Docker sized hole through my firewall and have less security than if I ran a stock workflow.

by 3eb7988a1663

1/14/2025 at 9:48:44 AM

For me, I don't use LXD, but use Proxmox containers. These are non-root Linux containers by default. Super lightweight compared to a VM. Proxmox makes managing LXC containers a little easier with a UI, compared to managing containers strictly using command line.

If you go this route, create a container template that has everything you want in every instance. And then spin out new containers whenever you need one.

by cheema33

1/14/2025 at 12:38:24 PM

you might be interested in the incus webui

by khimaros

1/14/2025 at 8:05:05 AM

I always used to do that, using Vagrant. Mostly because it was the only practical way to maintain independent environments for the tools I was using.

These days I work in JavaScript and rarely have issues with project environments interfering with each other. I've gotten lazy and don't use VMs anymore.

In theory docker type setups could work but they just seem so much effort to learn and setup.

by stevage

1/14/2025 at 8:35:56 AM

Seconding vagrant - especially because it's the only reasonable way I found so far to test linux release on my windows rig (would prefer to dev on linux, but windows-only company is windows-only company).

Basically I put a Vagrantfile in src folder, then run docker compose with db, caddy, app server and other services inside it - then I forward ports 80 and 443 from vm and use localhost.whateverdomain.igot with self-signed cert on caddy (since https is just enough different than http that I otherwise get bitten by bugs every so often).

When I start a new project I can usually just copy the Vagrantfile with minimal changes.

by smatija

1/14/2025 at 9:38:08 AM

i develop on linux, on various projects. i'm mostly concerned with all the tools, build scripts and tests that may read sensitive data, or accidentally destroy data. so i'm limiting access to files when working on a project with linux namespaces, using bubblewrap.

i've got a simple per-project dot file that describes the file system binds. while i'm working on a project, new terminals i open are automatically isolated to that project based on that dot file. it has very low (cognitive) overhead and integrates pretty much seamlessly. i suspect many developers have similar scripts. i looked for projects that did this some time ago, but couldn't find it. either because it's too simple to make a project about, or because i don't know how others would describe it. if anyone has pointers...

i don't limit network access (though i did experiment with logging all traffic, and automatically setting up a mitm proxy for all traffic; it wasn't convenient enough to use as regular user). there is still a whole kernel attack surface of course. though i'm mostly concerned about files being read/destroyed.

by mjl-

1/14/2025 at 7:53:33 AM

Time to main Qubes OS on your development machine. https://www.qubes-os.org/

by arkh

1/14/2025 at 8:07:13 AM

I actually did try to install Qubes over the holiday, but I repeatedly encountered installation failures and could not ever login to the system. Someone had posted an identical issue, but they were similarly stymied. I should revisit, but my initial foray tells me I am going to have to withstand quite a few papercuts in order to get the isolation I want.

by 3eb7988a1663

1/14/2025 at 9:07:59 AM

never had issues with qubes like that but i did pick something tested (hw). u can check hardware compat list. it has also some good links to forums for specific hw related tweaks u might need. that being said, runing qubes fully and workin with it is something else... i decided i am uninteresting enough just to use ubuntu these days :p... maybe sometime ill have the patience again.

by sim7c00

1/14/2025 at 3:33:54 AM

I think a lot of the issues in this particular example is the ease with which api keys, once leaked, are single factor passwords.

If you ran a key logger on my machine you would never get into any major site with mfa. You couldn't watch me log on to the azure console with passkey and do much with it. But if you scrape a saved key with publish abilities bad things happen.

by technion

1/14/2025 at 4:48:14 AM

What's to stop me from installing custom certs and MITM your login session proxying the info. Or an extension to harvest the data after you login. I'm pretty sure if I have root it's game over one way or another. The surface is massive.

by chrismarlow9

1/14/2025 at 6:51:06 AM

At that point you've done something much more invasive and detectable than exporting a .env file and you've walked away with a very short lived token. There's always "something more an attacker can do", I'll stand by the view that requiring further authentication to perform interactive actions and pushes is worthwhile.

by technion

1/14/2025 at 7:41:47 AM

I wonder how this is mitigated by my current workflow of running jupyter and vscode from a docker container.

I did not start doing this because of security, but just to get something more or less self managed without any possibility to break different projects. I am tired of my team spending too much time on extensions, versions, packages, ...

Docker compose files have saved our team many hours, even if it's extremely wasteful to have multiple vscode instances running alongside each other

by dacryn

1/14/2025 at 9:17:45 AM

I know where you are coming from and I considered this myself again and again. For me and for now it is not something I want to do and not primarily because of the effort.

The VM might protect me, but it will not protect the users of the software I am producing. How can I ship a product to the customer and expect them to safely use it without protection when I myself only touch it when in a hazmat suit?

No, that is not the environment I want.

My current solution is to be super picky with my dependencies. More specifically I hold the opinion that we should neither trust projects nor companies but only people. This is not easy to do, but I do not see a better alternative as for now.

by weinzierl

1/14/2025 at 5:34:02 AM

I started doing development under a separate non-admin user on my MacBook. I switch to another user for personal stuff, or the admin user to install stuff with Homebrew. Doesn't protect from zero days but it's better than nothing.

by cedws

1/14/2025 at 8:29:28 AM

I toyed around with this a bit, and it feels like it has significant merit. User separation is about the only security boundary built into Linux from the beginning. I was not totally happy with the workflow I adopted, but it is probably going to be less burdensome than the VM approach.

by 3eb7988a1663

1/14/2025 at 1:57:09 PM

With Fast User Switching on macOS it's pretty convenient too. The difficulty is remembering to switch user when changing contexts. I tried to set a different wallpaper/icon for each user to make it more obvious which user I'm on, but macOS just resets them all to be the same.

by cedws

1/14/2025 at 8:12:33 AM

I just stick to using whatever is on my distribution for personal use.

For work use I use a work machine and if it gets compromised it's not really my own problem.

by guappa

1/14/2025 at 2:21:52 PM

> For work I use a work machine and if it gets compromised it's not really my own problem.

Is that really a good mindset for a organization?

by Alifatisk

1/14/2025 at 2:34:11 PM

I guess so… there seems to be absolutely no consequences to getting hacked, so from a business perspective it makes a lot of sense.

It's not up to me to decide what policy to use, and if it was I couldn't just do whatever I wanted, I'd have to justify its cost. And every company does the same…

I can decide the policy at my home :)

by guappa

1/14/2025 at 9:37:15 AM

The security, and overall application stability attack vector, is why I now vouch for processes with OS IPC instead of shared libraries, even if it requires more resources.

It doesn't fully sort out the trust issue though, even if everything is sandboxed in some fashion.

by pjmlp

1/14/2025 at 2:12:02 PM

I know of IPC, but it has never occurred to me to view as an alternative to shared libraries. It's an intriguing viewpoint I'm having trouble wrapping my mind around. Are there battle-tested real-life examples of IPC being used where shared libs could have been used instead?

by uticus

1/14/2025 at 2:43:43 PM

VSCode would be one such example.

All the stuff using Android intents, out-proc COM extensions in Windows, XPS in macOS, are other relevant set of examples.

I assume you are kind of new to the computing world, OS IPC is how we extended applications almost 40 years before shared libraries became common feature across all major operating systems.

Naturally with them being around, shared memory in-process was much easier, and less resource intensive. IPC calls require processes, which take more kernel resources, and context switch.

Microservices isn't a new concept, rather re-branding.

Sun had as marketing quote, "The network is the computer", exactly because of how it used to be.

by pjmlp

1/14/2025 at 6:10:12 AM

I wonder how long until this is standard, and PFYs coming into the industry look at our current practices much like people now look at non-encrypted credentials being sent over the network.

by petesergeant

1/14/2025 at 5:29:13 AM

Why would you do anything but work related activities on a work machine. If you really want trust for software. Don’t use a computer.

by pinoy420

1/14/2025 at 8:11:28 AM

It is good to wind down every now and then during work time.

Also, many people here work on multiple projects for different customers. Having a security breach for one affecting the other is not something you'd be happy with.

by smokel

1/14/2025 at 8:18:27 AM

I never said anything about personal stuff on a work machine? I want my own hardware to have isolation between my email/banking/etc and side project programming.

by 3eb7988a1663

1/14/2025 at 9:56:29 AM

Then have a separate machine if you’re that paranoid. Funny how it doesn’t cause issue for the hundreds of thousands of other people in the world

by pinoy420

1/14/2025 at 2:23:36 PM

The only part of the article I disagree with is this line:

> But in general, it’s a good idea not to install NPM packages blindly. If you know what to look for, there are definite signals that these packages are dodgy. All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not.

This works -- maybe OK for top-level packages. But for transitive dependencies it's nearly impossible to vet every transitive dependency.

If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

by gortok

1/14/2025 at 2:25:58 PM

>If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area?

This would be where different security advice would apply: don't pull in a package that has 400 dependencies.

by ziddoap

1/14/2025 at 3:07:47 PM

Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."

by krainboltgreene

1/14/2025 at 5:03:51 PM

Things like this are suppose to be provenance of an organizations security engineering teams. Helping to ensure you don't ship something like this. It's also hard for them too because no one wants to force developers to re-implement already solved functionality.

by wyldberry

1/14/2025 at 5:41:16 PM

I also have never met a security engineer that was eager to do that.

by krainboltgreene

1/14/2025 at 9:47:57 PM

> never met a security engineer that was eager to do that

Of course not. We do the fun parts, and write tickets to make the dev team do the boring parts that we will later complain are not implemented to the quality standard we would have reached, had we done the work. That's the deal.

by finnthehuman

1/14/2025 at 4:26:55 PM

Out of curiosity, I've always meant to ask, are you related to the famous Geoguesser content creator in any way? It's a pretty distinctive last name.

by nightpool

1/14/2025 at 4:45:39 PM

I believe he might be a distant cousin. I've done some family tree searching myself and haven't found many things, since the Rainbolt side has mostly been scoundrels and vagabonds there aren't many details, but we do have a mountain that we named after ourselves after we stole it from natives.

by krainboltgreene

1/14/2025 at 3:42:44 PM

This is really where SELinux had the right idea overall: preclassifying files with data about their sensitivity, and denying access based on that, does adequately solve this problem (i.e. keeping npm installations away from id_rsa).

by XorNot

1/14/2025 at 4:03:56 PM

The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone.

im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.

by beardedwizard

1/14/2025 at 5:09:14 PM

I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do.

So before running any code you'd hash it and ask your peers: "what do we think this does?"

If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised.

I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens.

It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.

by __MatrixMan__

1/14/2025 at 11:33:22 PM

This both is and isn't what SELinux does though: the point of SELinux is when you execute a binary, it runs with whatever context is assigned to it and is bounded by that context (or allowed transitions).

This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works).

AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?).

Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?

by XorNot

1/15/2025 at 12:24:50 AM

As far as I'm aware it's missing the consensus part. If I run a program that's not supposed to touch the filesystem in any way, and it does, SELinux doesn't suggest a way for me to circulate this new knowledge among other users of this program--except through its maintainer or that of my Linux distro. And maintainer diligence is over-relied-on as it is.

Ideally this sort of thing would work just as well on bits for which there was no clear maintainer. Like if SETI turned up a signal which we can chmod +x and run, we could use it to crowd source an understanding of what it does.

A way to hash a file and ask:

> What is known about these bits?

If it's a popular program and yet none of your peers have seen that hash, maybe you should subject it to more scrutiny than if there's widespread consensus about it (it may have been tampered with).

by __MatrixMan__

1/14/2025 at 3:08:37 PM

Wait how in the world does a React carousel component have over 400 deps…

by chamomeal

1/14/2025 at 4:30:04 PM

Because Javascript is a drug that makes developers stupid.

It's almost trite at this point to comment on the obsession that Node has created with developers to reduce functionality to the smallest possible reusable parts, even trivial things, and publish them as packages, then to import and use those dependencies. The idea, in and of itself, is not terrible, but it's been taken to a logical extreme which is very much the definition of terrible.

by tristor

1/14/2025 at 6:15:24 PM

Nearly all of these look like demo projects. You're making inferences about an entire group of developers based on a meme plus a search over the very 'worst' offenders.

by jbreckmckye

1/14/2025 at 6:14:21 PM

Do you mean https://www.npmjs.com/package/carousel-react? By the looks of it, this was published by someone 7 years ago as part of a personal project. Nothing uses it.

Going through that list... they all look like personal projects, with no dependents, and a single release by a single person.

by jbreckmckye

1/14/2025 at 6:48:31 PM

Ok now that I’ve actually looked at the package.json, it seems like this must be a joke or something. It’s got packages for CLI arg parsing, math expression evaluation, hashing, etc.

When I’m back on my computer I may look at the source and confirm my suspicion that none of those are required for the carousel functionality lol

by chamomeal

1/14/2025 at 4:50:50 PM

History of "micro dependencies" where many flexible utilities are split up into separate packages, such that many npm dependencies are a single function (ie rather than a package exporting ten methods, its ten separate dependencies).

Then because there is no standard library, many reinventions of similar but incompatible utilities. etc.

by cloverich

1/14/2025 at 3:45:06 PM

/giphy "first time?" meme

by KuhlMensch

1/14/2025 at 4:22:01 PM

Did you think the meme about node_modules having more gravity than a star was just a meme?

It's very much based on reality. The npm ecosystem is just absolutely fucked.

by Sohcahtoa82

1/14/2025 at 5:42:43 PM

> If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area?

At my place of work we use this great security too called Snyk. Definitely check it out

/s

by loaph

1/14/2025 at 8:09:38 AM

snyk is the same company that instead of rotating oublic keys just… changes them without notice. https://github.com/snyk/cli/pull/5649

They also mark projects as "abandoned" if they move to any other forge that isn't github. And they stay abandoned even if new releases appear on npm/pypi :D

Their competence isn't as big as their fame, in my opinion.

Also one of their sales people insulted me over email, because apparently not being interested in buying their product means you're an incompetent developer who can only write software filled with vulnerabilities.

by guappa

1/14/2025 at 4:21:49 PM

They also penalize libraries that are "done," and require minimal development.

Completely backwards software that corpos only seem to buy because their insurers force them to check off some security list box.

by azemetre

1/14/2025 at 8:12:00 AM

"insulted me over email" - whoa, that's wild, do you still have the email? would be fun to see it :D

by gyoridavid

1/14/2025 at 8:28:40 AM

Sorry, I searched, it seems all my emails from before the last company rename are gone.

edit: or microsoft outlook sucks… I tried to sort in reverse my inbox to see what's the oldest email there and "the request cannot be satisfied"

by guappa

1/14/2025 at 9:15:00 AM

Ouch, I kind of trusted it.

... more than Gmail and Google

by unixhero

1/14/2025 at 11:21:20 AM

I get surprisingly many cold emails these days with a passive aggressive “shall we schedule a call, or are you a bad person who doesn’t give a shit about security?” approach.

by ceejayoz

1/14/2025 at 2:55:01 PM

Yeah. Or 'make this change to help our processes'. Um, that's not my job.

by matwood

1/14/2025 at 5:25:54 PM

That's extremely unfortunate, especially about the "abandoned" labelling. I've been looking to move off GitHub recently as well, it feels like it's got a bit too much control.

Codeberg looks interesting, and there are self-hosted ones like Forejo that also look great if you're okay with the maintenance.

by alp1n3_eth

1/15/2025 at 10:24:36 PM

I use codeberg :)

It has CI, pull requests, issues and whatnot. It also doesn't force you to use 2fa if you don't want :D

If you do corporate open source though, you're stuck on github because snyk, openssf, pypi and whatnot only interface with github.

For actual libre software codeberg is very good.

Keep in mind that debian salsa is open to everyone as well. The only annoyance is that non debian developers have a "-guest" suffix. But it's ok to use for projects that aren't debian specific.

by guappa

1/14/2025 at 8:12:42 AM

> hey also mark projects as "abandoned" if they move to any other forge that isn't github. And they stay abandoned even if new releases appear on npm/pypi :D

Well theres a sign of a good team.. /s

That's actually an interesting take, I haven't heard too much about them except that they do have an ego.

by bilekas

1/14/2025 at 12:05:35 PM

I'm sure you can provide the body of the [appropriately redacted] said email?

by Ylpertnodi

1/14/2025 at 1:03:12 PM

I was also sure until I found out that outlook refuses to search old emails.

by guappa

1/14/2025 at 12:55:12 AM

Without more context, this doesn't look great for Snyk either way: either they have an employee using NPM to live test their own services, or they have insufficient controls/processes for performing a legitimate audit of Cursor without using public resources.

by woodruffw

1/14/2025 at 2:52:57 AM

Why not? NPM behaves oddly when there is a public package named the same as one on a private repo, in some cases it’ll fetch the public one instead. I believe it’s called package squatting or something. They might have just been showing that this is possible during an assessment. No harm no foul here imo

by tru3_power

1/14/2025 at 3:06:03 AM

> They might have just been showing that this is possible during an assessment. No harm no foul here imo

You're not supposed to leave public artifacts or test on public services during an assessment.

It's possible Cursor asked them to do so, but there's no public indication of this either. That's why I qualified my original comment. However, even if they did ask them to, it's typically not appropriate to use a separate unrelated public service (NPM) to perform the demo.

Source: I've done a handful of security assessments of public packaging indices.

by woodruffw

1/14/2025 at 8:14:44 AM

Comments here seem to indicate that cursor did NOT ask them to (unless of course someone inside the company did and didn't tell the others)

by guappa

1/14/2025 at 5:10:50 AM

if Cursor is secure it shouldn't be a problem for them! (and, according to their comments, it is)

by compootr

1/14/2025 at 5:32:51 AM

It's not about being a problem or not. It's a basic responsibility when doing security research: maintaining an isolated test environment is table stakes.

by woodruffw

1/14/2025 at 6:13:06 AM

How should it have been done differently? How else is the researcher supposed to know if the attack works? "Hey random company, we have no proof it's going to work but we think maybe your system, which we can't see, is vulnerable! Go waste time and check!"

by mmsc

1/14/2025 at 9:55:50 AM

Cursor team has already stated here that they did not ask Snyk to perform a security audit. I wonder if Snyk's actions are equivalent to me coming to your house late at night and then trying to open any and all doors and windows. In the name of security research. Without an invitation from you.

How else am I to validate that your house is secure?

by cheema33

1/16/2025 at 2:17:31 AM

I don't think it's like checking the locks in this case... more like adding a landmine in an apartment complex for cursor to trip on maybe ;)

by compootr

1/14/2025 at 6:31:59 AM

Local DNS override, and two registries. One mirroring the relevant public NPM packages as they are, and one "normal" internal one. Make the mirror registry resolvable with the same name(s) as the real, public NPM registry.

Then test the behaviour.

by bostik

1/14/2025 at 7:15:57 AM

I think there's an incorrect assumption that the Snyk team has any access to Cursor's systems, or their source code.

by mmsc

1/14/2025 at 5:19:15 AM

"No Harm No Foul" in this case would be a simple demonstrative failure case, not functioning malware.

by BeefWellington

1/14/2025 at 1:06:32 AM

Looks like a white hat audit from Snyk testing. Got flagged because oastify.com is a default Burp Collaborator server.

They should be running a private npm repo for tests (not difficult to override locally) and also their own collaborator server.

by nikcub

1/14/2025 at 10:07:13 AM

It's not white hat because they actively extract data; if it was just to prove it worked they could've done a console.log, cause npm install to fail, or not extract a payload.

by Cthulhu_

1/14/2025 at 1:19:14 PM

The data they extract is nothing sensitive and this way they can see how many hits they get. The more affected the bigger the headline for them.

by that_guy_iain

1/14/2025 at 2:03:57 PM

In what world is "all environment variables" nothing sensitive?

by __jonas

1/16/2025 at 8:16:08 AM

Even just the username is sensitive because it gives hint on what to try with ssh attempts.

by guappa

1/14/2025 at 3:57:57 AM

Looks like NPM is generating jobs for those in the security field. It’s an unfixable mess, I really hope some competition like JSR will put enough pressure on the organization.

by mirkodrummer

1/14/2025 at 9:12:49 AM

It's not just NPM, it's the trust in third party libraries in general. Even though it's much rarer, you'll see exploits on platforms like Nuget. You're also going to see them on JSR. You have more security because they are immutable, but you're not protected from downloading a malicious pacakge before it's outed.

I think what we're more likely to see is that leglislation like DORA and NSIS increasinly require that you audit third party packages. This enforcing a different way of doing development in critical industries. I also think you're going to see a lot less usage of external packages in the age of LLM's. Because why would you pull an external package to generate something like your OpenAPI specification when any LLM can write a cli script that does it for you in an hour or two of configuring it to your needs? Similarily, you don't need to use LLM's directly to auto-generate "boring" parts of your code, you can have them build cli tools which does it. That way you're not relying on outside factors, and while I can almost guarantee that these cli tools will be horrible cowboy code, their output will be what you refine the tools to make.

With languages like Go pushing everything you need in their standard packages, you're looking at a world where you can do a lot of things with nothing but the standard library very easily.

by devjab

1/16/2025 at 6:52:01 AM

I think NPM makes it worse because it's common to have hundreds, or thousands of dependencies. Which makes it easier to hide a malicious one in there.

by guappa

1/14/2025 at 2:56:51 AM

OT: Has anyone ever gotten (proper) SBOMs for Snyks own tools and services? Asking because they want to sell my employee their solution (which does SBOMs).

by rettichschnidi

1/14/2025 at 3:31:48 AM

Snyk is founded by people from the Israeli Army's Unit 8200.

I wouldn't install it if you paid me to, because it feels a lot like Unit 8200 pumps out entrepreneurs and funds them so that (like the NSA) they have their foot already in the door.

by KennyBlanken

1/14/2025 at 5:39:12 AM

Wiz.io (who almost sold to Google for $25bn) also had founders from IDF Unit 8200. Dozens of other companies like Waze, Palo Alto Networks were also the same.

by alpb

1/14/2025 at 4:12:02 AM

Conspiracies and politics aside, the reasons for the prominence of 8200 are somewhat boring: it's the largest unit in the IDF, in a relatively small country. Teenagers who demonstrate just about any degree of technical savviness get funneled into it for their mandatory service.

It's the equivalent of observing that SFBA startups tend to have a lot of Stanford grads at the helm.

(I don't have any particular love for Snyk as a product suite. I think most supply chain security products are severely over-hyped.)

by woodruffw

1/14/2025 at 10:41:42 AM

> Conspiracies

Not when the dissidents put their name to paper.

  We, veterans of Unit 8200, reserve soldiers both past and present, declare that we refuse to take part in actions against Palestinians and refuse to continue serving as tools in deepening the military control over the Occupied Territories.

  It is commonly thought that the service in military intelligence is free of moral dilemmas and solely contributes to the reduction of violence and harm to innocent people. However, our military service has taught us that intelligence is an integral part of Israel's military occupation over the territories.

  The Palestinian population under military rule is completely exposed to espionage and surveillance by Israeli intelligence. While there are severe limitations on the surveillance of Israeli citizens, the Palestinians are not afforded this protection.

  There's no distinction between Palestinians who are, and are not, involved in violence. Information that is collected and stored harms innocent people. It is used for political persecution and to create divisions within Palestinian society by recruiting collaborators and driving parts of Palestinian society against itself. In many cases, intelligence prevents defendants from receiving a fair trial in military courts, as the evidence against them is not revealed.

  Intelligence allows for the continued control over millions of people through thorough and intrusive supervision and invasion of most areas of life. This does not allow for people to lead normal lives, and fuels more violence further distancing us from the end of the conflict.
https://www.theguardian.com/world/2014/sep/12/israeli-intell... (and that's from 2014)

by ignoramous

1/14/2025 at 1:59:16 PM

I don’t think this conflicts with what I’ve said. I’m not claiming Unit 8200 is moral or absolved; I’m saying only that you will run into a lot of 8200 veterans if you interact with any Israeli startup, since it’s a massive unit. Assuming that those people don’t have opinions of their own is likely incorrect, as this letter demonstrates.

by woodruffw

1/16/2025 at 8:14:44 AM

It's signed by 34 people… I guess we can say it's completely irrelevant.

by guappa

1/16/2025 at 2:04:25 PM

> 34 people ... completely irrelevant

There weren't many Oskar Schindlers either.

by ignoramous

1/14/2025 at 7:19:30 AM

Talent or skills is essential but alone is not enough. while the size and quality of the talent pool helps it is not sufficient to explain the success rate, considering that there are similar or better quality talent pools which are larger in many countries around the world, but they don't have the success rates Israeli startups and 8200 ones specifically have compared to their home market and talent pool size.

It is not some conspiracy either, success as founder has strong network effects and positive feedback loops, right mentorship, access to talent pool, or access to funding and people who can open doors all becomes easier when your network already has some success. Similar reason second time founders have it easier they can tap into their personal version of a network.

It is not unusual to Israel/8200, the valley itself benefits from this effect heavily after all.

by manquer

1/14/2025 at 4:44:44 PM

Right, it's not about talent. It's the fact that it's an extremely strong network with a flywheel between defense spending and startup tech. The same things that make the US's startup industry indefatigable.

by woodruffw

1/14/2025 at 11:10:18 AM

> benefits from this effect

"Benefits" from whose perspective? For instance, the Brazilians (the State apparatus, specifically) are also benefiting [0], but are their citizens [1]?

[0] https://www.jstor.org/stable/48595312

[1] https://idanlandau-com.translate.goog/2016/02/04/technologie...

by ignoramous

1/14/2025 at 12:31:22 PM

benefits from the perspective of the startup, i.e. chances of its success or growth.

Who in turn benefits from that in terms wealth, power, influence is whole different topic for which i have no expertise, i was only talking about frequency of successes in startup clusters.

by manquer

1/14/2025 at 8:57:17 AM

Incredibuild is on this list (at least with regard to current leadership)

by sgammon

1/15/2025 at 1:36:25 PM

Got better results with Syft

by de130W

1/14/2025 at 7:20:19 AM

Lots of false positives IME

by davedx

1/14/2025 at 7:45:43 PM

That wasn't my experience when I used Snyk at my last job, depending on your definition of FP.

For example, if you're using a multi-protocol networking library, and it says that the version you have installed is has a vulnerability in its SMTP handling, but you don't use the SMTP functionality, is that a FP?

I'd argue that it's irrelevant, but not a false positive.

I never had it get the version of a library wrong.

by Sohcahtoa82

1/14/2025 at 1:56:23 PM

Snyk Research Labs regularly contributes back to the community with testing and research of common software packages. This particular research into Cursor was not intended to be malicious and included Snyk Research Labs and the contact information of the researcher. We were very specifically looking at dependency confusion in some VS Code extensions. The packages would not be installed directly by a developer.

Snyk does follow a responsible disclosure policy and while no one picked this package up, had anyone done so, we would have immediately followed up with them.

by dannyallan

1/14/2025 at 2:32:47 PM

Spraying your attack into the public with hopes of hitting your target is the polar opposite of responsible. The only "good" part of this is that you were caught in the act before anyone else got hit in the crossfire.

In response, you suggest that you'll send a letter of apology to the funeral home of anyone that got hit. Compromising their credentials, even if you have "good intentions", still puts them into a compromised position and they have to react the same as they would for any other malevolent attacker.

This is so close to "malicious" that it's hard to perceive a difference.

edit: Let's also remind everyone that a Snyk stakeholder is currently attempting to launch a Cursor competitor, so assuming good intentions is even MORE of a stretch.

by luma

1/14/2025 at 2:20:04 PM

Cool. Why phone home the user's environment, then? The vulnerability could very much be confirmed by simply sending a stub instead of live envs.

by senorrib

1/14/2025 at 2:29:18 PM

This is grey-hat at best. Intent may have been good, but the fact is that this team created and distributed software to access and exfiltrate data without permission which is very illegal. You may want to consult with the legal department before posting about this on a public forum fyi.

by yabones

1/14/2025 at 2:24:23 PM

Seems reasonable enough, but why would it (allegedly) send environment variables back via a POST? Even if it's entirely in good faith, I'd rather some random package not have my `env` output..

by etyp

1/14/2025 at 4:39:40 PM

Upvoting this since presumably you're actually the CTO at Snyk and people should see your official response, but wow this feels wildly irresponsible. You could have proved the PoC without actually stealing innocent developer credentials. Furthermore, additional caution should have been taken given the conflict of interest with the competitor product to Cursor. Terrible decision making and terrible response.

by austinkhale

1/14/2025 at 4:19:49 PM

What is responsible about sending the environment over in a proof of concept?

by pizzalife

1/14/2025 at 2:59:14 AM

Why, after all these years, are we still doing this stupid thing of using a global namespace for packages? If you are a company with an internal package registry just publish all your packages as @companyname/mylib and then no one can squat the name on a public registry. I thought we collectively learned this 4 years ago when dependency confusion attacks were first disclosed.

by lopkeny12ko

1/14/2025 at 4:44:41 AM

The usual reasons: laziness, ignorance, poor design. Most package managers suck at letting you add 3rd party repos. Most package managers don't have namespaces of any kind. The ones that do have terrible design. Most of them lack a verification system or curation. Most of them have terrible search. None of them seem to have been exposed to hierarchical naming or package inheritance. And a very small number of people understand security in general, many fewer are educated about all the attack classes.

But all of that is why they get popular. Lazy, crappy, easy things are more popular than intentional, complex, harder things. Shitty popular tech wins.

by 0xbadcafebee

1/14/2025 at 8:31:06 AM

In the Java world, you need to prove ownership of a given namespace (group id), e.g. via a TXT record for that domain. Isn't there a similar concept for NPM? The package is named sn4k-s3c/call-home, how will a victim be tricked into referencing that namespace sn4k-s3c (which I suppose is owned by the attacker, not Cursor)? I feel like I'm missing part of the picture here.

by gunnarmorling

1/14/2025 at 10:01:47 AM

You're not really missing anything so much as adding a misguided assumption of competence to NPM.

Npm doesn't really do namespaces. There's just no ownership to prove as most packages are published like "call-home" with no namespace required. This gives exciting opportunities for you to register cal-home to trap users who miss type, or caII-home to innocuously add to your own or open source projects or whatever. Fun isn't it?

In this case the call home package is namespaced, but the real attack is the packages like "cursor-always-local" which has no namespace. Which can sometimes (?) take precedence over a private package with the same name.

It's not a pretty picture, you were better off missing it really.

by hennell

1/14/2025 at 5:27:52 PM

> Npm doesn't really do namespaces.

Yes it really does. npm has namespaces (called scoped packages) and even explicitly encourages their use for private packages to avoid this sort of attack. From the npm docs: "A variant of this attack is when a public package is registered with the same name of a private package that an organization is using. We strongly encourage using scoped packages to ensure that a private package isn’t being substituted with one from the public registry." [1]

> This gives exciting opportunities for you to register cal-home to trap users who miss type, or caII-home to innocuously add to your own or open source projects or whatever. Fun isn't it?

npm actively blocks typo-squatting attacks during the publishing process: "Attackers may attempt to trick others into installing a malicious package by registering a package with a similar name to a popular package, in hopes that people will mistype or otherwise confuse the two. npm is able to detect typosquat attacks and block the publishing of these packages." [1]

This thread is full of people demonstrating the concept of confirmation bias.

[1] https://docs.npmjs.com/threats-and-mitigations

by Vaguely2178

1/14/2025 at 8:17:13 PM

You're referring to what I described previously here... ironically back when the first dependency confusion research was published: https://www.sonatype.com/blog/why-namespacing-matters-in-pub...

by TheRealBrianF

1/15/2025 at 9:06:30 AM

Thanks, Brian! Big kudos to you and Sonatype for the service you provide to the Java community.

by gunnarmorling

1/14/2025 at 3:29:39 PM

NPM packages are the most bloated and unreadable pieces of code I've encountered. The creator of Node apparently hates all software and yet Google gave him the captain's hat and we're left with the absolute crap shoot that is web development. I feel guilty with an additional 1KB of code or 500 bytes of RAM but this is seen as an outsider opinion. I hope big tech rots and this is just a symptom. https://news.ycombinator.com/item?id=3055154

by kittikitti

1/14/2025 at 3:43:08 PM

NPM packages VS Wordpress plugins ... I think it is a head to head race there.

by zelphirkalt

1/14/2025 at 1:29:20 PM

Hopefully this makes the Cursor team reconsider security (which doesn't seem very good really).

Stopped using it for serious stuff after I noticed their LLMs grabs your whole .env files and sends them to their server... even after you add them to their .cursorignore file. Bizarre stuff.

Now imagine a bad actor exploiting this... recipe for disaster.

by fintechie

1/14/2025 at 1:36:50 PM

Security often means the opposite of scalability and growth, so why should they? The business goal is to make sure Cursor grows large enough that they have economics of scale to be a viable business.

If you want secure LLM you can use Mistral, which comes with all the EU limitations, good and bad.

by miohtama

1/14/2025 at 2:04:30 PM

Mistral (an LLM company) is not really a substitute for cursor (an IDE). Tabby is probably the closest open-source alternative. https://github.com/TabbyML/tabby

by yunwal

1/14/2025 at 3:28:16 AM

> All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not.

Wouldn't a lot of small packages consist of just these two files, meaning seeing just these two files in a package may raise an eyebrow but hardly be a smoking gun?

by nomilk

1/14/2025 at 8:35:45 AM

It's not a smoking gun. It is just one of a number of signals you look for when identifying potentially malicious packages. Other things you look for are number of collaborators, how long it existed, domains it talks to, and artifacts it pulls in.

by 6mile

1/16/2025 at 8:02:34 AM

> are number of collaborators

You have any idea how easy it is to fake it?

Also, snyk doesn't scan code that isn't on github, because they are under the impression that all the code in the world is on github, so things like gnome.org, debian salsa or codeberg are completely ignored.

So you won't get reliable data from snyk.

edit: snyk doesn't scan code at all, they rely on unrelated "metrics" to give a rating that is not very useful.

by guappa

1/14/2025 at 7:49:38 AM

A colleague of mine vendors npm dependencies to diff code between third party lib changes. Those are also covered in pull request reviews.

Helps in cases like this.

by hu3

1/14/2025 at 9:52:29 AM

Could you please explain a little more. I can use such practice in my dev workflow.

by absqueued

1/14/2025 at 10:06:21 AM

Sure. They don't include "node_modules" directory in their .gitignore file.

So any third party code changes end up in git commits and are easily visible and reviweable.

So running npm update/upgrade includes the code that changed in the dependencies in the commit.

by hu3

1/14/2025 at 10:27:55 AM

Surely there has to be better ways of “vendoring” (including hosting your own package repository that doesn’t automatically pull new versions) than adding thousands or maybe tens of thousands of files to the git repo?

by MortyWaves

1/16/2025 at 8:03:40 AM

On debian I do debdiff to see the differences between two source packages.

by guappa

1/14/2025 at 12:54:12 PM

If my podcast memory serves, that's how Isaac (the NPM guy) said it was intended.

You would `npm install` and then `git commit`. That's why npm didn't have a lock file back then. Git was the lock file.

by xdennis

1/14/2025 at 10:50:01 AM

if it's dumb and it works it isn't dumb!

another rather simple solution is a git mirror of each package, then point npm to a git url

by compootr

1/14/2025 at 11:24:28 AM

This is an option but that makes it easier to conceal malicious code within node_modules as an internal threat actor or make super sure there's a culture of actually reviewing those changes.

In cases like that it helps to do npm install on the CI and make sure you end up with identical code. Decent trade-off.

by VPenkov

1/14/2025 at 6:30:13 PM

this is an area that is top of mind for me right now. you don't have to vendor your deps to get a detailed report of what changed, and bonus, how your app calls into it. just wrote about it: https://edgebit.io/blog/code-diff-reachability/

by robszumski

1/14/2025 at 4:03:40 AM

Is there a link for the "githax" tool shown in the blog post, which seems to be quite useful? There's [1] but it's just a banner image.

[1] https://www.githax.com/

by supriyo-biswas

1/14/2025 at 5:34:19 AM

The dev is https://github.com/6mile (same as author of the article)

seems to be either a tool that isnt out yet or perhaps not available for free or the public.

by edm0nd

1/14/2025 at 7:02:57 AM

GitHax is a labour of love right now and is in heavy development. I'm going to create a small beta testing group soon. Hit me up if you want to be in that group. Contact deets are in my GH profile.

by 6mile

1/14/2025 at 8:25:46 AM

We have read this exact story before, please learn not to leak too much sensitive data with your PoCs

by bugtodiffer

1/14/2025 at 1:18:30 PM

Behind hundreds of builds Snyk has been a challenging integration that ultimately creates very low value. I recommend using a decent team that goes in for flow weaknesses as these are most responsible for significant findings...

by SebFender

1/14/2025 at 8:20:07 PM

Hey there! I run DevRel & SecRel @ Snyk, we just published a piece to help dispel all the rumors, etc. This provides a lot of in-depth info on the situation: https://snyk.io/blog/snyk-security-labs-testing-update-curso...

The TL;DR is that our security research team routinely hunts for various vulnerabilities in tools developers use. In this particular case, we looked at a potential dependency confusion attack in Cursor, but found no vulnerabilities.

There's no malicious intent or action here, but I can certainly understand how it appears when there's not a ton of information and things like this occur! As a sidenote, I use Cursor all the time and love it <3

by rdegges

1/16/2025 at 8:09:47 AM

> The packages performed HTTP requests back to our researchers containing username, hostname, current directory and (in later versions) environmental variables.

And exfiltration was needed to confirm a vulnerability why exactly?

I love how completely unaware you guys are.

by guappa

1/15/2025 at 2:25:10 AM

Sorry, but you screwed up royally. Scary to see that Snyk still does not see this.

Ethically, your work was even lower than that of those who test their AI tools on FOSS code, send in bogus reports and thus waste maintainer's time. Experimenting on unwitting humans and ecosystems is not okay.

by rettichschnidi

1/14/2025 at 8:36:27 AM

"It's a good idea not to use npm packages blindly"

Yes, but also impractical.

by stuaxo

1/14/2025 at 4:03:19 AM

npm is rife with this activity, its like wordpress plugins

by jijji

1/14/2025 at 7:36:24 AM

As much as I don't like NPM, these issues aren't limited to NPM. It's just that NPM is getting so much attention that we're more likely to find and hear about these issues when when they target NPM.

I'm fairly concerned about the state of Python packages. It's not every week, but I frequently stumble upon packages that are not what they appear to be. Sometimes not maliciously, sometimes the author just got overly ambitious and failed to deliver, other times, someone is clearly typo-squatting or attempting to get you to install the wrong thing.

by mrweasel

1/14/2025 at 6:35:03 PM

Seriously: How do we know there aren't dozens or hundreds of comprimsed npm packages installed on every other server out there at this point?

Think xz-utils but even much less sophisticated exploits.

I don't see any systematic protection against this?

by jdthedisciple

1/15/2025 at 4:48:13 AM

> I don't see any systematic protection against this?

Snyk

by cko

1/16/2025 at 8:13:39 AM

Ah yes, add malware and sell malware detection. The perfect business idea.

by guappa

1/14/2025 at 12:58:59 AM

Just a reminder that Snyk was founded by ex-IDF Unit 8200 soldiers. I would not trust them given what we've seen Israel do to supply chains.

https://en.wikipedia.org/wiki/Snyk

by bbqfog

1/14/2025 at 1:31:17 AM

I don't have a dog in this hunt. I've never worked with Snyk, I've never been a customer, and I don't think I even know anyone who works there. That said, they've built their whole company around being trustworthy and doubt they'd knowingly do anything to risk their entire business. Also, I can hardly imagine someone better positioned to protect against supply chain attacks.

Your criticism sounds to me like "just a reminder that this armed bodyguard service comprises Navy SEALs and Army Rangers". Uh, great!

by kstrauser

1/14/2025 at 4:28:27 AM

I'd give good odds it was a mistake by a staff member (or small group) who overstepped and was not part of any formal work.

Most companies where I've worked as a security researcher, you get some time as part of your job to hack on random stuff to be able to generate interesting talks / research. This feels like that.

This isn't a special cyber spooky practice, most pentesting companies do this to generate IP (rarely, lol), buzz (reasonably often) and keep the staff happy (this is really the main thing).

It's rare for management to be fully across the scope of this.

by xyzzy123

1/14/2025 at 1:51:49 AM

Maybe if you change that to "armed bodyguard services employ ex KGB assassins"

by CuriouslyC

1/14/2025 at 2:41:01 AM

I think you've missed the point: it's Americentric to assume that Navy SEALs and Army Rangers are inherently pure, good and have done nothing evil on behalf of the American government when we largely know that to be untrue.

by nullityrofl

1/14/2025 at 3:38:26 AM

That wasn't my point at all. The point was that often the best people to protect a resource are the ones who know how to attack it.

by kstrauser

1/14/2025 at 7:27:56 AM

I would say it is on similar to criticism of TikTok or Huwaei and China.

It has less to do with whether it malicious intent from the start of building an organization for explicit intent of capturing core infra. It has more to do with how the Government of Israel operates and the legal requests they can make of their citizens and/or veterans.

Perhaps concern over Israeli products should be probably higher than for China as Israel more well known incidents of exploits as a State actor like with Stuxnet, Pegasus or more recently with pagers etc.

China no doubt has their own share of operations but they either have not used them as publicly in a large scale overt operation or been more discreet about it.

Point is the concern is valid just as it would be valid for China.

by manquer

1/14/2025 at 3:14:20 PM

You mean like how we found out that China attacked and pwn3d the entire US phone system? That’s not a shining example of discretion.

by kstrauser

1/14/2025 at 11:19:33 PM

As the U.S. has done to our closest allies and their leaders, would be shocking and incompetent if they have not done much more in Russia and China and vice versa

There is no equivalence intelligence gathering or gaining the capability for sabotage (which everyone does) versus actual active sabotage which today only Israel executes like with Stuxnet or with the pagers.

by manquer

1/14/2025 at 4:07:07 AM

I have no downside to seeking alternatives. The pager incident ensured that I will always look for non-Israeli tech.

by bbqfog

1/14/2025 at 4:55:31 AM

And what does that have to do with Snyk, other than that some of their employees use to work for IDF?

I'm a US Navy veteran. Would you also stay away from my employers because they have veterans on staff?

Seriously, I get what you're trying to say, but I don't understand the broader point you're trying to make. So Snyk has some ex-IDF employees. Find a high-profile infosec firm that doesn't. They military service they were compelled to has a reputation at being really, really good at infosec. I see no reason why companies shouldn't want to hire them afterward.

by kstrauser

1/14/2025 at 5:08:43 AM

Without wanting to take a position here, the GP comment had a specific narrow point.

The claim was that Snyk was founded by Unit 8200 members.

Not that it had a few Israeli veterens, almost all Israeli's serve in the IDF after all.

https://en.wikipedia.org/wiki/Unit_8200

To be fair I have a former Unit 8200 member in my larger extended family who left and has since been vocal in opposition to Netanyahu so membership in an elite Cyber Unit alone doesn't define a person.

That aside, most Governments would keep an eye on a company started by, say, former NSA employees and watch for covert activity under any overt actions.

by defrost

1/14/2025 at 12:05:52 PM

It would correlate strongly that 8200 alumni end up being educated and working in tech, and likely living in Tel Aviv. This is a group of people who, by and large, are not big fans of the current government.

by dekelpilli

1/14/2025 at 5:17:48 AM

Based on the pager incident, I'd think you should avoid companies that don't have a publicly-known link to Israel. It's not like Hezbollah thought they were buying pagers from 8200 alumni.

by dekelpilli

1/14/2025 at 4:33:29 AM

What pager incident?

by PoppinFreshDo

1/14/2025 at 4:44:06 AM

The recent one in which Israeli techs compromised pager supply chains.

It was very widely reported across the globe.

by defrost

1/14/2025 at 2:27:25 AM

[flagged]

by myth_drannon

1/14/2025 at 2:38:52 AM

This is a tiresome motte-and-bailey argument. You are trying to conflate the OP comment with something it's not (base antisemitism).

Just like companies founded by say former operatives of the CIA, NSA, MI6, etc. would (and maybe should?) be viewed with skepticism, so too are companies founded by former members of Unit 8200.

Mentioning that Israel's military (like many others) has engaged in some less than ethical behavior is not equivalent to antisemitism. Trying to pretend otherwise is ridiculous.

by PessimalDecimal

1/14/2025 at 2:46:34 AM

Israel has mandatory military service. If anyone who has ever served in the IDF is tarnished and has that part of their life periodically dragged out as evidence that they may be untrustworthy, you're saying that the entire Jewish population of the state of Israel needs to have a giant asterisk attached to them reminding everyone that they were in the IDF.

That may not be strictly antisemitic—maybe you're totally fine with Jews as long as they were raised anywhere else—but it's still not a healthy way to treat people.

by lolinder

1/14/2025 at 3:11:26 AM

I don't understand the purpose of creating ambiguity by confusing mandatory military service and intelligence corp that operates under secrecy. Original post getting flagged is not a great sight either.

by joseppudev

1/14/2025 at 3:14:23 AM

IDF Unit 8200 consists of thousands of conscripts serving their mandatory military service. If I were in Israel subject to conscription, I would absolutely have attempted to position myself into that unit for my mandatory service, as would most here. Beats the infantry.

What exactly am I confusing by pointing that out?

Were you under the impression that this unit was something like the NSA, staffed with people who chose to spy on people as a career? Because it's not. It's staffed by kids who are very good with computers and who—when given a choice between covert intelligence and a branch that actively shoots guns at people—chose the intelligence arm. Which would you have chosen?

by lolinder

1/14/2025 at 3:27:28 AM

https://www.timesofisrael.com/hezbollah-pager-explosions-put...

Just months ago, some of those "kids who are very good with computers" caused compromised pagers to explode, with no knowledge of who would be near them. Civilians, including children, died as a result. It is right to think people who are "good with computers" in this way might not have the best intentions in their other applications of computers.

by PessimalDecimal

1/14/2025 at 3:30:02 AM

The other alternative that those kids were given was to shoot guns or missiles. Are you really comfortable blaming them for the rest of their lives for choosing the option that likely gave them the smallest chance of killing people?

Any Israeli citizen in that age bracket today is going to be running a real risk of killing people. They don't have a choice (dodging the draft doesn't count as a choice). If you're going to hold that over for them for the rest of their lives I don't know how that's distinct from racism (or countryism if you prefer).

by lolinder

1/14/2025 at 3:37:04 AM

> Are you really comfortable blaming them for the rest of their lives for choosing the option that likely gave them the smallest chance of killing people?

Yes. The "just following orders" excuse has been tried in the past. People didn't buy it then and we won't buy it now.

https://www.nbcnews.com/news/world/israel-soldiers-arrest-ab...

If the IDF wants to name the specific individuals from Unit 8200 who were involved in maiming or killing civilians including children by blowing up electronics in their faces, that might change things. Then it'd be a lot easier for people to avoid having concerns about that entire unit. Not naming them seems a lot like tacit support by the IDF for the actions of those in Unit 8200 who killed those children. Otherwise, people very well may have concerns about that entire unit. That's not "racism."

by PessimalDecimal

1/14/2025 at 4:23:05 AM

(I deleted a comment that didn't seem relevant any more now that you added a bunch.)

So it's okay to blame vets of Unit 8200 for its actions 10 years after they founded Snyk (I have no idea how long after they left the unit) on the grounds that the intelligence arm of the IDF doesn't name names? So just in case and in the face of all the facts of the timelines, we should make sure to drag out these people's former mandatory service and remind everyone they served alongside bad guys 10+ years ago?

I'm not okay with blaming soldiers for following orders. When it's that or getting shot by your own side, there isn't a real choice. But I can't even begin to understand the mindset that would blame soldiers for the orders that other, unrelated soldiers followed more than 10 years later. That's some next-level hatred.

by lolinder

1/14/2025 at 8:13:42 AM

Yes, because it's an institutional problem. I'm sure you have no issues using products developed by say, ex FSB agents just because it's been 10 years?

by mardifoufs

1/14/2025 at 1:28:11 PM

The FSB is no comparison because it's more equivalent to the NSA—it was a career path, not a place to serve out mandatory military service.

FSB agents worked there for decades and chose that instead of any number of other things they could have done. Unit 8200 conscripts worked there for at most 2 years 8 months and chose it instead of a different, more gun-blazing branch of the military.

Mandatory military service completely changes the profile of the vets in a way that makes all these comparisons totally irrational. They're founded in fear and hatred for Israelis, not any reasonable similarity.

by lolinder

1/14/2025 at 2:20:23 PM

Fear of Israelis, sure. But hatred? Come on. Israel has done a lot in the past year, and is being accused of genocide. The fact that is used a conscript army makes it worse, not better.

Also, okay then let's switch it up to the Russian army. Would you use a product with known ties to some electronic warfare russian army unit. Or rather, would you consider any doubts or hesitations over using said product to be "russophobic"?

by mardifoufs

1/14/2025 at 6:05:12 PM

> The fact that is used a conscript army makes it worse, not better.

I'm not defending the state, I'm defending the individuals who were conscripted.

The entire point of this subthread is that it's heinous to confuse the two.

> Would you use a product with known ties to some electronic warfare russian army unit. Or rather, would you consider any doubts or hesitations over using said product to be "russophobic"?

If I suddenly learned that some founding members of the JetBrains team had previously been conscripted into the Russian army and had served in a cyberwarfare unit, that would change absolutely nothing for me. And yes, I do consider the backlash against JetBrains in the aftermath of the invasion of Ukraine to have been highly rusophobic.

by lolinder

1/14/2025 at 11:47:37 PM

To be honest, I don't disagree but I see why people do care about it.

In the sense that this is just a direct result of Israel's actions. They staged an incredibly powerful intelligence coup with the blown up pagers. Now I agree that if you aren't involved in middle Eastern politics, there's no reason to be scared of Israeli products (even if made by ex-israeli soldiers). But I completely understand where the reputational damage comes from, it was such a well executed operation that it does cast more doubts on anything related to Israel.

My point about conscription was that it is worse in the sense that most Israeli citizens can be de-facto coerced into becoming an agent of the state, making Israeli products inherently more suspicious (and more tied to state policy, regardless of the individuals involved). As you say, most Israelis don't necessarily chose to be in the army. A lot of Hamas fighters are also basically conscripts, but that nuance wouldn't matter for most either.

There's also just the purely ideological angle, which is also what happened to anything touching Russia back in 2022. That's the angle that I agree is mostly unjustifiable.

by mardifoufs

1/14/2025 at 4:49:23 AM

Why doesn’t refusing the draft count as a choice?

by danenania

1/14/2025 at 4:57:00 AM

Because it means a serious risk of the end of your life as you know it. I'm not willing to hold someone else to a standard that I know that I couldn't live up to.

If you truly believe that you'd risk your government's wrath instead of just picking the least dangerous and least likely to kill people branch of your military, then feel free to throw stones. For myself, my plan if the draft were reinstated in the US while I was still of that age was to find out how to join a cyberwarfare division, which would have led me straight to Unit 8200 if I were Israeli.

by lolinder

1/14/2025 at 3:34:58 AM

Those "kids who are very good with computers" designed a black-box AI that has been designating people terrorists which the military then uses to bomb not just them but their entire family.

https://www.npr.org/2023/12/14/1218643254/israel-is-using-an...

by KennyBlanken

1/14/2025 at 3:38:54 AM

And their peers in the other branches are killing civilians in other ways. Your point?

The only way to hold this against the individuals rationally, especially for those on this forum who would absolutely have chosen Unit 8200 as the least bad option given conscription, is to blame every citizen of the state of Israel and hold them all in distrust for having ever been in any branch of the IDF. I'm personally not okay with that level of sweeping blame and distrust. Are you?

by lolinder

1/14/2025 at 3:58:33 AM

> is to blame every citizen of the state of Israel

nobody has said or even implied this

> hold them all in distrust for having ever been in any branch of the IDF

nobody has said or even implied this

> that level of sweeping blame and distrust

There has not been any such thing in this discussion.

We're done here.

by KennyBlanken

1/14/2025 at 4:02:07 AM

Yes, it was done by OP, the comment that was rightly flagged and then later resurrected:

> Just a reminder that Snyk was founded by ex-IDF Unit 8200 soldiers. I would not trust them given what we've seen Israel do to supply chains.

Given that Unit 8200 is staffed by conscripts, how is this anything other than attempting to ensure that any person who ever came of age in Israel has that held against them for the rest of their careers?

Members of Unit 8200 weren't given a choice between that and the private sector—they were given a choice between that and shooting a gun, which for a technically inclined new-adult isn't much of a choice at all. And am I seriously supposed to believe that OP would argue that choosing to be a grunt who shoots a gun at people would be the morally purer choice that would make someone more trustworthy?

by lolinder

1/14/2025 at 3:36:17 AM

Size seems to be classified. Their officers seem to be classified as well. I understand how getting into the unit might be very normal. But doubt here is the healthy thing. Especially as a goyim.

by joseppudev

1/14/2025 at 2:32:42 AM

They just recently snuck bombs into a supply chain and then remotely detonated them in positions where the caused civilian injuries. I would assume the comment has nothing to do with religion/race, and everything to do with the actions taken. Even for someone that is a supporter of that government, it's hard to deny they've taken some actions that are unsupportable.

by RHSeeger

1/14/2025 at 2:41:01 AM

Who is "they"? Are we talking about Snyk? IDF Unit 8200? The IDF as a whole? The state of Israel? Jews in general?

The reason why OP's comment feels like a racist dog whistle is because it's an enormous and dangerous generalization that seems to encompass an entire country. Israel has mandatory military service—if everyone who's ever served in the IDF is untrustworthy because they served in the IDF then you're by definition excluding nearly every Israeli citizen from trust. I guess that's not strictly antisemitism—maybe you're happy to trust Jews that don't live in Israel—but it's definitely an unsavory position to take.

by lolinder

1/14/2025 at 3:45:29 AM

Godwin's got an itch he can't scratch and doesn't know why....

"Encompassing the entire country" would be anti-zionist, not antisemitic.

There is a huge difference, and that does not change because the majority of people in that country are a particular religion, just like it's not "Anti-Protestant" if someone attacks Great Britain policies, or "Anti-Hindu" if someone criticizes India.

There is a difference, to the extent that there are plenty of jews who are anti-zionist.

Would you like to accuse them of being antisemitic because "nearly every Israeli citizen is Jewish"?

Also, it's your construct that criticizing the policies and actions of a country's military and government is "anti" that county...

by KennyBlanken

1/14/2025 at 3:52:36 AM

> Also, it's your construct that criticizing the policies and actions of a country's military and government is "anti" that county...

No, it's not—we're in a subthread where the OP said "Just a reminder that Snyk was founded by ex-IDF Unit 8200 soldiers. I would not trust them given what we've seen Israel do to supply chains."

They took the country's current policy and made it personal against specific IDF vets. That's what I'm standing against.

For the rest, I specifically said that it may not be antisemitic given that it's country-specific, so I'm not sure what you were getting at. I'm still not okay with blanket blaming an entire country's citizenry for its government actions. I wasn't okay with that when it came to Russia and Ukraine, I don't know why I should treat this differently now.

by lolinder

1/14/2025 at 3:29:25 AM

It's not just the IDF, you have a CHOICE to join the spymaster side of it, vs being a regular grunt. That unit is part of Aman, the military version of Mossad.

by Der_Einzige

1/14/2025 at 3:32:15 AM

And why would choosing to be a grunt be more morally pure?

I'm a techie, if I were forced into conscription I would absolutely choose an option that let me use computers over one that forced me to shoot a gun. There's no way on Earth I can hold it against a bunch of kids who were forced to make that choice that they chose the intelligence arm.

And frankly, I have a hard time seeing how someone on this forum could hold that against them in good faith. Nearly everyone here would make the same call given that choice. If you think you wouldn't have, you're probably deluding yourself.

by lolinder

1/14/2025 at 2:40:12 AM

How the hell that is connected to a private software company?

Nvidia, Google, Microsoft, Intel is full of ex-8200.

by myth_drannon

1/14/2025 at 9:05:49 AM

So every Israeli is now a Mossad agent and every customer is an enemy of Israel like Hezbollah? You won't buy from Snyk because you want to boycott Israel, just own up to it it's a popular position to take.

by weatherlite

1/14/2025 at 2:14:38 PM

I’d put Unit 8200 and Mossad in the same basket. I think I made it clear I’m boycotting Israeli products, I’m not hiding that.

by bbqfog

1/14/2025 at 10:09:29 AM

As the pager / radio terrorist attack showed, it's the Mossad involvement you don't know about that you should be worried about. Same with the CIA, they were behind "secure" radio communication in Europe for decades (https://en.wikipedia.org/wiki/Crypto_AG) and nobody had any idea.

by Cthulhu_

1/14/2025 at 8:42:52 AM

That's absurd. If that's your claim, do you know how many of your daily tools and hardware you should also drop?

by krembo

1/14/2025 at 2:15:19 PM

I’m dropping as many as I can as is my prerogative as a consumer.

by bbqfog

1/14/2025 at 9:58:53 PM

Do you need some help with that? I'll be more than happy if antisemites like you won't be using any of the advanced tech we're working hard to create .

by krembo

1/14/2025 at 10:56:15 PM

Sure, where do you work? I’ll be happy to add it to my list!

by bbqfog

1/16/2025 at 8:27:14 AM

Ah the old trick of calling racism if you voice disagreement with a government… At this point people like you have made the word "antisemite" completely devoid of any meaning.

by guappa

1/16/2025 at 11:10:50 AM

You are not criticizing the government but denying Israel's right to exists and protect itself, and this is the good ol' antisemitism with a brand new liberal mask.

by krembo

1/16/2025 at 12:29:14 PM

The population of Gaza has LITERALLY been decimated in the past year (10% died).

If you don't criticise this, you are a terrible human being.

Genocide is bad also if you do it on dark skinned people, FYI.

by guappa

1/16/2025 at 5:12:48 PM

So had the population of Drezden in 1945. If you can't understand that being on the evil side of history and starting a war has its price, you are a terrible human being.

by krembo

1/16/2025 at 9:48:53 PM

If a genocide supporter calls me a terrible human being, I'm clearly a good person.

Dresden was a war crime and played no part in winning the war. Same with the atomic bombs.

by guappa

1/14/2025 at 4:39:27 AM

Just a reminder that Unit 8200 is staffed mostly by conscripts who are serving out their mandatory military service and chose to accept an invitation to serve in the cyberwarfare arm of the IDF instead of choosing to shoot guns.

In other words, it's staffed by Israeli kids who made the choice most of us would have made under the circumstances. It seems a bit unfair to hold that against them more than 10 years later, no?

by lolinder

1/14/2025 at 7:09:06 AM

> In other words, it's staffed by Israeli kids who made the choice most of us would have made under the circumstances. It seems a bit unfair to hold that against them more than 10 years later, no?

You could say the same about the guy in a call center in India trying to pull a tech support scam on you over the phone. Yes, he's probably making the best choice he can for his own livelihood, probably the same thing you would do in his position. No, that doesn't mean you should trust him.

Just as you have to treat all Chinese companies as under control of the PRC government and all Australian companies as compromised by their security services, you have to treat all Israeli citizens as under the control of the Israeli military. Any adult can be conscripted and they have a history of disguising military operations as civilian ones. Someone might tell you they left the Israeli military 10 years ago and they're probably telling the truth, but if you make a habit of believing that statement you're going to get burned.

by lmm

1/14/2025 at 1:46:21 PM

> You could say the same about the guy in a call center in India trying to pull a tech support scam on you over the phone. Yes, he's probably making the best choice he can for his own livelihood, probably the same thing you would do in his position. No, that doesn't mean you should trust him.

No, you can't, because the scammer in the call center is choosing that over thousands of other options. Are they choosing to maximize their pay? Maybe. But for every scammer there are thousands of Indians who show a different option.

Choosing to dodge or resist the draft is totally different—very few people do it, and those who do get prison terms. If you sincerely believe that you'd have chosen to go to prison rather than be drafted, more power to you, but I and most others would aim to minimize the likelihood of ourselves dying and minimize the number of people I'd have to kill. For me that would have meant signing up for cyberwarfare, which in Israel would have meant Unit 8200.

The rest of your comment is totally irrational fear-based speculation. Anti-Israel sentiment may not be antisemitic, but it sure shares the same tendency towards irrational fear and aggression.

by lolinder

1/14/2025 at 2:39:10 PM

> the scammer in the call center is choosing that over thousands of other options.

No, they're the people who don't have other options (because they lack the skills and/or qualifications and/or are discriminated against). It's not malice, it's just desperation to get money to live on (or, often, to provide for people who depend on them). But of course the end result is the same.

> The rest of your comment is totally irrational fear-based speculation.

Entirely rational given the historical pattern of behaviour shown by the Israeli military, and the fact that they have no reason to change (quite the opposite).

by lmm

1/14/2025 at 1:47:03 PM

> Just as you have to treat all Chinese companies as under control of the PRC government and all Australian companies as compromised by their security services, you have to treat all Israeli citizens as under the control of the Israeli military

Got it , and are now all American companies suspect because they are managed behind the scenes by Musk and Trump?

by weatherlite

1/14/2025 at 2:34:24 PM

All American companies are suspect given the National Security Letter system yes. (Also South Korea and Kazakhstan, and obviously also any country where the "rule of law" is low enough that governments can do as they wish without formal legal powers)

by lmm

1/14/2025 at 2:18:31 PM

I feel the same way about companies with CIA founders.

by bbqfog

1/14/2025 at 2:17:52 PM

I would under no circumstance join the IDF or even live in Israel. They’re not “kids”, they are military personnel.

by bbqfog

1/14/2025 at 2:44:30 PM

key word: "conscript"

if you're born there, you have little choice in the matter.

by arccy

1/14/2025 at 2:56:07 PM

I've never met an Israeli who wasn't a dual citizen. It's a choice to stay in Israel and fight in the IDF. In fact, the Snyk founder lives in London now: https://uk.linkedin.com/in/guypo

by bbqfog

1/14/2025 at 6:01:00 PM

> I've never met an Israeli who wasn't a dual citizen.

Given that unless you are in Israel you're most likely to be meeting Israeli expats or at the very least people who travel, that's hardly surprising and not great evidence for anything.

> In fact, the Snyk founder lives in London now

So you're acknowledging that you're going to hold their country of origin against them even after they've moved. Got it.

by lolinder

1/14/2025 at 6:14:32 PM

I don’t understand your complaint. People are free to vocally denounce Zionism. These founders have not done that. Quite the opposite, Snyk has offices in Israel and has been vocal about their ties to the IDF. It’s absolutely within my agency to not use their products. Again, there’s zero downside to do that.

by bbqfog

1/14/2025 at 6:38:19 PM

Correct, you're welcome to do that, and I'm welcome to denounce you for advocating boycotting a product because of the country of origin of its founders.

People can't help where they're born, and you're wrong to hold that against them. You're welcome to work through that cognitive dissonance however you like, but in the meantime I will continue to advocate for treating individuals as individuals.

by lolinder

1/14/2025 at 6:42:09 PM

No one is entitled to my business. I have no cognitive dissonance, my business interests are aligned with my moral interests in this case. I don’t use Israeli tech whenever possible.

You “denouncing” people who make a rational calculation isn’t really helping to market the firms you are supporting.

by bbqfog

1/14/2025 at 7:02:23 PM

I'm not supporting firms, I'm supporting the right of individuals to be seen as individuals rather than as members of a group assigned to them at birth.

That said, this obviously isn't going anywhere, so have a nice day.

by lolinder

1/16/2025 at 8:31:36 AM

"being born in israel" and "Join the army and take part in genocide" aren't the same thing, despite your tryhard attempts to make them into the same thing.

by guappa

1/14/2025 at 5:29:26 AM

Don't hate the player hate the game ;)

by yard2010

1/14/2025 at 9:26:42 AM

"no one can hack us" and then "you can't hack us, how dare you" game, 25 years and more

by skirge

1/14/2025 at 9:58:54 AM

> "no one can hack us"

Did Cursor made claims to this effect and invited public to hack them?

Or are you equating someone saying they "take security seriously" to "it's an open season, please attack our systems."?

by cheema33

1/14/2025 at 12:21:22 PM

yes it is, like independent product reviews or crash tests of cars. Anyway Kim Jong Un doesn't care.

by skirge

1/14/2025 at 1:29:46 PM

[dead]

by jtdev

1/14/2025 at 9:16:33 AM

[flagged]

by justmarc

1/14/2025 at 10:01:08 AM

> Yawn.

Wrong forum perhaps? Or wrong story? But you clicked the story. Read it. And then even bothered to comment on it. You are putting a lot of effort into something that does not interest you.

by cheema33

1/14/2025 at 4:32:35 AM

I'm sure it's all part of some tiktok prank video.

by PoppinFreshDo

1/14/2025 at 7:29:16 AM

[flagged]

by raybb

1/14/2025 at 2:10:58 AM

Things like this could _synk_ their reputation...

by nathabonfim59

1/14/2025 at 8:18:10 AM

They're terrible already. If you invest enough in marketing nothing matters.

by guappa

1/14/2025 at 3:35:04 AM

Literally a test in production. The dev commit their work go to home thinking "not will happen"

by dalton_zk

1/14/2025 at 5:28:42 AM

If it was really a test, then why would it be sending environment variables via HTTP POST? There are many better ways to do this if you're legitimately deploying code remotely.

by Sophira

1/14/2025 at 3:01:54 AM

You either die as a white hat or live long enough to see yourself become a black hat.

by xyst

1/14/2025 at 5:03:25 AM

Side note: Snyk (founded 2015, computer and network security) has nothing to do with @sneak (hacking since 1998, computer and network security).

I was dismayed to learn about their choice of brand, and think it might cause confusion. :(

by sneak

1/14/2025 at 6:28:03 AM

I don’t even read those the same. To me snyk is read as snick and not sneak.

by vips7L

1/14/2025 at 8:21:48 PM

The name 'snyk' is an acronym, it stands for 'so now you know' (about security vulnerabilities) =D

by rdegges