Ask HN: How do you check desktop apps for malicious code?

1 points by asar ↗ HN
Just wondering how people are dealing with security checks on the flurry of vibe coded apps that are coming out these days.

I've been a linux user for a long time and really enjoy the wave of new rust apps based on GPUI or similar tech to bring more polished and performant desktop apps. But with AI driven attacks becoming more advanced I'm getting more and more suspicous of projects with only one contributor, despite them being public. I know that it doesnt mean a project with many contributors is automatically safe and supply chain attacks can occur for different reasons too. But I'm just imagining someone exfiltrating files or secrets from my local machine and sending them off somewhere. This probably wouldve been easy to spot with some pattern matching in the past but nowadays an AI could split up the logic across 1000s of files and make it really hard to see??

Are there any services or tools you can recommend to perform these checks?

2 comments

[ 0.98 ms ] story [ 7.2 ms ] thread
For me, my main device is limited to (somewhat) trusted software: MacOS, Chrome, a few well-known brands like BBEdit.

All the "fun" (untrusted) stuff on that machind is behind the sandboxing of a browser and the OS itself.

Anything that needs local permission is on a separate laptop which is only got one account: Claude. Not even signed in to Apple (nor any browser) on that, despite it being a Mac.

Isnt this a general issue with any closed source software? and not just vibe-coded apps?

What is to stop even reputed closed source software from shipping a newer release with a malicious feature that ships your personal files it gets access to a remote location?

The best I've got is to have tools like firewalls highlightling any odd behaviours and perhaps the newer decision models like Jev or laya etc trained to spot such anomalies in app behavior and bubble them up for attention - because manually watching or deterministically scripting to catch those is not practical.