There was always, in my mind at least, a tension with Linus's Law ("given enough eyeballs, all bugs are shallow").
It's true but the problem is assuming, just because something is open source, it has received sufficient eyeballs. AI now gives us near unlimited eyeballs so, if we survive the bumpy transition, open source should indeed become very secure compared to closed source.
Except we won't get the expected benefit, because all those eyeballs are attached to a very small number of different "brains" (LLM models.)
The original saying depends on an implicit assumption that eyeballs are proportional to minds, and that among those varied independent scans, different people will catch what others miss.
In other words, we shouldn't assume 5.5x review thoroughness when we hire 11 QA eyeballs but they all belong to Bobby the Beholder.
>and that among those varied independent scans, different people will catch what others miss.
My point was more that very few brains were looking deeply at the long tail of open source code/projects (other than the maintainers of the code themselves); and for the marquee projects that did get proportionally more varied eyeballs (e.g. postgres), it seems even that level of attention was insufficient for code deep inside the project's core.
LLMs change this. They make it much easier for maintainers and motivated users to amplify the power of their eyeballs.
I was thinking about this too, and think it will come down to incentives for attackers and defenders.
Assuming offensive and defensive capabilities are similar, and incentives scale roughly with project size but start from a non-zero value for attackers, I'd expect larger open projects to be well defended by plenty of motivated people, and smaller ones less so (depending on maintainers). Closed source will mostly just depend on maintainers.
Also assuming closed source is less exposed to AI auditing overall, I'd guess large open projects end up more secure than large closed projects, but small open projects possibly less secure than small closed projects, since attackers might have more incentive to target them than defenders do to audit them.
Attackers are always far better resourced. You get six billion if you hack a crypto exchange, you get PIP if you spend time fixing bugs rather than pushing new features.
I doubt this seriously. You're as vulnerable as your worst piece of software.
I'd lean more towards systems that only install diamond-hardened software at all - once you have one project in a class of software that has been analyzed to death, that's the one everybody is going to use.
The vast majority of the development of all projects is going to be (already is) LLM-assisted, so they're going to get analyzed every time they're touched. The odds that huge bugs are going to be lying everywhere to be exploited are bad imo.
I'm starting to rewrite an open source project just because I don't want it to be buggy anymore. I barely want to change anything about it (especially not the licensing.) All I'm doing is porting it to rust from c++ and refactoring it like crazy. I just want to make it easy to audit and extend, and hard to crash, that's it. Once I'm done, I'm already have another (buggy) project in mind to do the exact same thing to. Great UIs and usability, just thwarted by the time that the developers had to invest in them. You could think of them as almost purely security-oriented rewrites.
What does "blended $0.30 per 1M tokens" mean? Is that input or output or average across the two? (asking as am trying to benchmark that cost against public GLM providers on Openrouter)
One would still have to guess what the ratio of input tokens to output tokens is. (I would say 10:1 off the cuff, assuming this is editing an existing codebase)
Stuff made during the move fast and break things era now doesn't hold up very well in the AI era. Or to say another way: startups are very vulnerable now - this new environment is unforgiving towards cutting corners and/or having inexperienced devs
I think the ultimate fallout will be that software "engineers" will finally have to become "engineers" in the real sense, i.e. professionally licensed and personally responsible for the designs they approve and the software they build, whether the actual code is produced by LLMs or humans.
As costs and broader economic impact and perhaps even injuries/deaths related to software breaches continue to grow, there will be growing intolerace for vulnerable software, just as there was intolerance for collapsing bridges and buildings.
And I'd also at some point expect something like a "building code" that applies to software that will be exposed to the public.
If anything, I see us moving even further away from professional licensing. The field's rate of change was the main reason behind a lack of any professional body, and that's only accelerating. I expect compliance audits like SOC2 to actually get teeth, though, and for organizations to be expected to actually fix issues instead of the usual security theater.
Calif more than Chainguard, but still Chainguard too.
Calif was obviously twitching to claim credit for their findings, and what I find troubling is this eagerness was more important to them than giving users a chance to update their systems.
Even if they ended up waiting only a day post release I would still say it seems a bit too soon. Maybe a week after. Not everyone’s system have aggressive patching schedules and PHP is soo heavily used.
This is probably the future, tho. Being first to disclose a vuln is a Big Deal in some quarters. And now, the velocity of AI driven pentest swarms mean every researcher who finds something worthwhile has to think "how close is the next droog's swarm to finding what I found" and the temptation to jump the gun only gets stronger.
I can't blame Chainguard for breaching an embargo which was already nonexistent at the time. If the embargo is broken already, they have a duty to their customers to upload as soon as possible.
All parties have that duty, but it's better if they do that at the same time.
I tried to read this but it's just claude after a certain point.
It's unreadable.
I can't understand any serious writer essentially expecting other people to read stuff that they didn't write. Or if claude was actually good at formulating ideas and conducting information, fine. But the truth is that I'm just reading 80% empty prose that are forced in there by claude.
E2E encryption, but I don't know the architecture. I.e. Meta doesn't have the keys. My comment above is based on an interview I saw with Zuckerberg where he wanted to use the Signal model to ensure the data was secure "even from Meta."
It's true but the problem is assuming, just because something is open source, it has received sufficient eyeballs. AI now gives us near unlimited eyeballs so, if we survive the bumpy transition, open source should indeed become very secure compared to closed source.
reply