←back to thread

1208 points jamesberthoty | 10 comments | | HN request time: 0.001s | source | bottom
Show context
kelnos ◴[] No.45266878[source]
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware.

One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. As a maintainer, I could decide that a package that's been out in the wild for at least 6 weeks is less likely to have unnoticed malware in it than one that was released just yesterday.

Obviously this is not a perfect fix, as there's no guarantee that the delay time I specify is enough for any particular package. And I'd want the tool to present me with options sometimes: e.g. if my current version of a dep has a vulnerability, and the fix for it came out a few days ago, I might choose to update to it (better eliminate the known vulnerability than refuse to update for fear of an unknown one) rather than wait until it's older than my threshold.

replies(35): >>45266995 #>>45267024 #>>45267360 #>>45267489 #>>45267600 #>>45267697 #>>45267722 #>>45267967 #>>45268218 #>>45268503 #>>45268654 #>>45268764 #>>45269143 #>>45269397 #>>45269398 #>>45269524 #>>45269799 #>>45269945 #>>45270082 #>>45270083 #>>45270420 #>>45270708 #>>45270917 #>>45270938 #>>45272063 #>>45272548 #>>45273074 #>>45273291 #>>45273321 #>>45273387 #>>45273513 #>>45273935 #>>45274324 #>>45275452 #>>45277692 #
gameman144 ◴[] No.45267024[source]
> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies

I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators.

"Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually pretty sensible.

replies(8): >>45267054 #>>45267101 #>>45267444 #>>45268170 #>>45268880 #>>45270337 #>>45273381 #>>45273796 #
Ajedi32 ◴[] No.45267054[source]
If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.
replies(11): >>45267090 #>>45267094 #>>45267132 #>>45267222 #>>45267415 #>>45267471 #>>45268298 #>>45269164 #>>45270175 #>>45270363 #>>45270519 #
1. bennyg ◴[] No.45267471[source]
Sounds like the job for an LLM tool to extract what's actually used from appropriately-licensed OSS modules and paste directly into codebases.
replies(3): >>45267705 #>>45268191 #>>45269005 #
2. philipwhiuk ◴[] No.45267705[source]
Do you have any evidence it wouldn't just make up code.
3. shakna ◴[] No.45268191[source]
Requiring you to audit both security and robustness on the LLM generated code.

Creating two problems, where there was one.

replies(2): >>45269859 #>>45271077 #
4. const_cast ◴[] No.45269005[source]
This is already a thing, compiled languages have been doing this for decades. This is just C++ templates with extra steps.
5. bennyg ◴[] No.45269859[source]
I didn't say generate :) - in all seriousness, I think you could reasonably have it copy the code for e.g. lodash.merge() and paste it into your codebase without the headaches you're describing. IMO, this method would be practical for a majority of npm deps in prod code. There are some I'd want to rely on the lib (and its maintenance over time), but also... a sort function is a sort function.
replies(1): >>45270170 #
6. shakna ◴[] No.45270170{3}[source]
LLMs don't copy and paste. They ingest and generate. The output will always be a generated something.
replies(2): >>45270709 #>>45281752 #
7. TheBicPen ◴[] No.45270709{4}[source]
In 2022, sure. But not today. Even something as simple as generating and running a `git clone && cp xyz` command will create code not directly generated by the LLM.
replies(1): >>45288106 #
8. vFunct ◴[] No.45271077[source]
LLMs can do the audits now.
9. lgas ◴[] No.45281752{4}[source]
You can give an LLM access to tools that it can invoke to actually copy and paste.
10. boomlinde ◴[] No.45288106{5}[source]
In what way do you think this rebuts the message you responded to?