So strange that this is still up 5 hours later… dang, I am yet again begging you to stop trying to roll your own forum ethos. It’s okay. You’re safe now. We can modernize without losing the magic. I know I know, shh, it’s okay, don’t worry, just flip the markdown and automod switches I know you have…
I agree with the opinion that people should treasure every moment, and live as if they only have 100 days of life, that is: to have fun, to try things, to explore anything they are interested in etc..
The LLM horror, no matter unfake or not, won't change anything for a people thinking this way.
Maybe balance that with also trying not to destroy things for future generations, or even just future decades, and appreciate the farsighted choices that were made in the past that we all benefit from currently, such as the global eradication of smallpox, national parks, etc.
If people want to apply this mechanism, it shall be not much of a hassle for writers of most (modern) programming languages, as they mostly have some `src/` directory (maybe also some `tests/`) that contains all source codes for a quick `git add`.
It's not your fault that I've become unclutured. If my wife had read it she would've never thought twice about which Godot it was. Kind of fun to think about how things change though. I don't think my children will read the play in school like I did, so perhaps the game engine being named after it (I assume it is) will mean they learn about it that way?
Thanks for your explanation on the definition of "security theater"!
> But if it turns out they can’t serve as the cooldown vanguard, then we have great evidence that they shouldn’t be trusted at all.
If they cannot serve as the cooldown vanguard, we are indeed going to realize they are not trustable, but by the time the damage has already been done. Therefore, if companies want to prevent the damage as much as possible, I believe they should do the scan by themselves.
I don’t agree about the “damage being done”: there’s no evidence that a cooldown is itself harmful. The worst thing it can do to you is deliver some updates to you slower-than-instantly.
I agree cooldown is not harmful in general. What I intended to say is that people (mostly) only know a security company is not trustable because they once failed to detect a malware package, and the reason people know a package is malware is that it has caused damaged to at least someone.
> The idea of not moving quickly to new software versions has been around for decades.
There are COBOL users and CentOS 6 users. They aren't affected by this issue.
They might need to face another set of issues like vulnerability backporting and so on. People not worrying about cooldowns might still need to patch their log4j libraries, but that's another thing. This post is not for them.
> There are always early adopters and researchers looking at new, publicly available software.
I agree with that. These hacks are very unlikely to go unnoticed, especially for popular packages (although they do happen; `chalk` has 3M downloads per week when it was hacked).
> The observation that "if everyone in production has a cooldown, the benefit is gone" is an absolutist opinion.
Yes. However, I think this is eventually becoming some type of pointless arms race, as cooldown does not act actively towards reducing ecosystem attacks.
To add a somehow random example, pnpm's default cooldown time is 1 day. Yarn's 7 days. I'm not sure whether one day pnpm would also change it to 7 days because of people asking.
>think this is eventually becoming some type of pointless arms race, as cooldown does not act actively towards reducing ecosystem attacks.
The nature of some of these attacks, it does. If your developers machine with publishing rights gets rooted a cool down makes credential gathering attacks via script in npm so very much harder it's not even funny.
In some of the recent supply chain attacks the entire fiasco was only a few hours long, but in that time tens of hundreds of thousands of credentials may have been stolen.
One day timers have the weakness of weekends and holidays reducing the number of eyes/systems seeing the issue.
I also believe sandboxing will get more and more important. There might be some trade-off on user experience or convenience, but given the security enhancement and (LLM agent's) freedom I think it will be well worth it.
I do appreciate these security companies a lot (for example, Snyk), but I feel it hard to believe this is sustainable. Especially in the current world where LLM is devaluing security researchers' work.
If they cannot get enough fiat or credit, this will eventually turn to some incident like OpenSSL heartbleed or so.
It's bold to call something that has prevented real-world attacks "security theater", with the justification that one day the world might change enough that it's less likely to prevent future attacks. Was the printing press worthless, just because we have laser printers nowadays?
Anyhow, If you believe LLMs will kill security research, then surely you must also believe a cooldown of 1 week would be enough time for your favorite LLM to analyze a new package version?
What do you call the time period between "new package is released" and "automated security scanners have analyzed the package"? That sure sounds like a release cooldown to me.
I applaud you if you do setup automated security scanners, without counting on external security groups or individuals (that doesn't have a security contract with your company).
This post is based on an assumption from what I see (I would be very happy if it's wrong) that most companies do not event bother to do these scans. They are merely waiting for the free kindness.
I'm confused by this take. In general, LLMs don't replace the expertise required to use an LLM.
Knowing the right input to give the LLM is not enough, nor does it ever end. The LLMs themselves need to be continuously updated and/or specialized for use case, and the "right input" is a moving target.
Keeping both ends of this aligned is the exact same expertise we already had before LLMs. These implementation details would only impact the credibility of those researchers who don't adapt to using this new tool. Who would stumble over something as trivial as this? LLMs aren't even the most important tool in the toolbox anyway.
I agree that LLM does not (and believe it never) fully replace researchers, but it produces artifacts (e.g. writeups, PoCs) at a cheaper price.
That makes me think LLM impacts human researchers' rewards, but now I realized the result might actually go in the opposite direction according to Jevons paradox. People still need experienced and professional human security researchers after all.
LLM is only devaluing security work by competition. As in, it's making dependency scanning so easy and cheap that researchers don't have much left to do on that front. The end result is very easy and cheap dependency scanning available to everyone. It makes the next heartbleed less likely, not more (though actually the class of bugs it protects against is closer to log4shell).
I would honestly hope that the LLM usage would help with that very thing. If AI systems automatically perform security audits on brand-new NPM releases, doesn't that accomplish a similar purpose?
reply