What is true is already so.
Owning up to it doesn't make it worse.
Not being open about it doesn't make it go away.
And because it's true, it is what is there to be interacted with.
Anything untrue isn't there to be lived.
People can stand what is true,
for they are already enduring it.
I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
I get that the rate of vulnerability discovery can be a burden, especially for people doing FOSS in their spare time, but the sustainability problem with that has always existed and only gets exacerbated by the vulnerability stuff, but the latter isn't the cause you need to make go away.
- A bug exists and nobody knows
- A bug exists and some people know
- A bug exists and everyone knows
As an outside observer, there is no way for you to determine if a bug is in state one or two, you only know once it's in the third state.
Which is the entire problem here. Having the bug be known to everyone is a vastly improved state over being known to a few. Yes, the bug being completely unknown is better than being known to a few, but there is no way to ever know if that's the case.
From the outside, known to none and known to a few are indistinguishable, and thus both states are the worst possible case. The only remedy is to make the bug known to everyone such that it cannot be covertly exploited.
Is your assertion that, since you specifically didn't know about the bugs that nobody, not in Russia or anywhere else did?
Obviously if bugs are out there existing in software and you don't know about them, or the CVE system doesn't know about them, or whatever ... this does not preclude bad guys from knowing about them. In the era of agents, knowing the bug exists is equivalent to having a PoC, so the distinction completely collapses.
Sweeping things under the rug is how we get insecurity. Sunshine is the best disinfectant.
Is this supposed to be hard to imagine? I can completely imagine this, especially if the mathematician is a celebrity in their field.
In practice, how much effort it is to find vulnerabilities matters a lot. We're in a time where things that used to be quite hard are now easy and the rate of discovery will change.
This rate of discovery matters a lot -- for OSS maintainer burnout if nothing else.
Burnout means that no more fixes come - ever - and that things sit vulnerable until everyone relying on that tool takes the time to build and switch to a replacement.
Maintainer burnout is perhaps the single biggest threat to the ecosystem right now.
And if the capacity is overshot (which I believe is happening as we speak), users end up in extended states of being insecure.
I'm also one of the unwashed rabble who believes there is a large practical difference between a vulnerability that exists but isn't found and one that is widely known and exploitable.
I don't think anyone is saying that here.
I think the net result is "wow, we're going to end up a lot more secure in several months, but things are going to feel sucky because stuff just got A) way easier for the average bad guy, and B) way busier on the fixing side."
I think it's likely we end up with an equilibrium with a lower rate of bug discovery than we're used to, but we need to experience an above average rate for a long while first...
The philosophy in this subthread may be too deep for me.
Me and the Jedi at the ends of the bell curve are just thinking "It's bad when your attackers know your code is vulnerable"
The patching cycle can become a problem for certain operations / industries.
Everybody hates the work, and security is often seen as a barrier and a cost center, not a driver or revenue.
Try binge-watching old Star Trek episodes, to see how Spock deals with the illogical 99.9% of humanity?
It's gotten much easier to reverse engineer binaries in general, and security patches in particular. Basically, an LLM can turn binaries into 'readable' code, and then reason about said code.
But yeah, if you're distributing binaries publicly, then you're going to have very similar problems.
*that was two entire weeks ago, what I'm seeing now makes that guy's binary crack look like a toy, it's becoming systematized now
I do think security is going to require more, not, less human investment as attackers may be running automated vulnerability screens from the outside that you must counter, as well. Without rigorous internal processes to manage and screen all changes and upgrades, companies risk leaving themselves open.
One design change which limits exposure is to have more local-first apps or experiences so there's less cloud / server to computer interactions to secure.
One of the benefits of Open source has been that there are more eye balls on the source, leading to more secure code/better quality. I think given enough time the bug reports will plateau and we will be back to a normal cadence - once the tsunami is over, hopefully things will settle at a more manageable cadence .
OSS has always had tradeoffs and I sadly think this one is going straight to the "Cons" column. We still think the Pros outweigh the Cons, but this is NotGreat.
Source that is unmaintained is dead. Nobody is looking at it, even the maintainer has something better to do.
Do you know whats even more powerful than "eyeballs"? Money.
Won't matter if is closed source, signed, and or obfuscated. =3
I take it that Metabase is both not paying bug bounties and not using these tools internally?
If that's the case, Metabase is not going to get meaningful investment from researchers who want to fix issues, but they'll get increased attention from malicious attackers who have no qualms exploiting the vulnerabilities for profit.
LLMs have made it a lot easier for people to find vulnerabilities in software. Open-source makes it easier, but we already have non-AI tooling (IDA Pro, Ghidra) that's good at binary reverse engineering, and LLMs can use that output to find vulnerabilities as well.
This year, as I select products to use for sensitive data, I've been paying a lot more attention to whether they offer bug bounties and for how much. For example, I like Kagi for search and thought about trying Orion, their web browser. Then, I saw that Kagi's been paying $100 for UXSS vulnerabilities.[0] For comparison, Firefox pays $8-10k,[1] and Chrome pays up to $10k for the same class of bug.[2]
[0] https://help.kagi.com/kagi/privacy/bug-bounty-program.html
[1] https://www.mozilla.org/en-US/security/client-bug-bounty/
[2] https://bughunters.google.com/about/rules/chrome-friends/chr...
The interesting thing is that the business model seems to have changed. Why collect a 10k bounty when you can advertise a 3k/month scanner?
* I presume I'm not the only one to find the agents tasked with adding unit tests will sometimes try to sneak through "open source code and apply regex to confirm presence or absence of specific string literal".
They can speed you up significantly, but you absolutely do need to pay attention to what they produce.
I'm sure what they have is awesome, but it's clear that there are people out there with some decent prompts that are getting results out of widely available models as well.
The big thing we're sharing is: bulk scanning by random people in random geographies got a _lot_ better around January, it's widely distributed, and it's going to get a lot better regardless of whether that specific version of Mythos becomes widely available or not.
Absolutely, and the "false-positive" issue people keep citing as why Mythos is so good is easily solved in the harness, simplest solution is starting fresh context with another prompt to evaluate if it's a false-positive or not, just adding that drastically cuts down the rate.
Besides that, hiring a beefy GPU instance at Vast.ai or similar places then running your own uncensored models on it, I've had great success with AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-NVFP4, smart + uncensored, but there are lots of options, probably some are already tailored for security research.
I have dog-fooded it heavily on my own projects, client projects and friends projects. It finds things that are really quite clever and not obvious. It really helps me.
But when I try to do the obvious thing for sales of using an OSS project to get hype, show off etc. I find that it becomes really hard to really know that I am helping and not just spamming.
To be clear - I think for an AI tool like mine to actually give you clever results that finds not obvious issues and security flaws - it needs to have some level of false positives.
I find myself struggling to justify the approach of firing off defects to an OSS maintainer without verifying them - which takes considerable time if I am going to do a good job. Even with tools to help pull apart the code, the core problem is always you don't know what you don't know.
The same process working on my own projects I can eat through a ton of defects and find some really great stuff. But that's only possible because I can tell at a glance what is real, what is fake, and also what is an oh ** issue.
So I think this is true, but the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing.
This stuff is more complicated than people give credit - and it's so easy to kid yourself into thinking any bug report is helpful.
And you're surprised OSS projects are pivoting towards "open source does not mean open contributions"?
How do you get that from:
> the risk is that people who don't understand the projects just point scanners at OSS blindly and ruin the good work maintainers are doing... and it's so easy to kid yourself into thinking any bug report is helpful.
Or you know, provide the security companies and businesses using your software for free with all the fix timelines and out of hours support they’ve paid for (none).
In theory, nothing.
In practice, it's in our long term interest that bad things don't happen to them.
How sustainable all of this is, I have my doubts?
Umm... no? It's called OPEN source. Expecting people to cancel their plans to make your free software more secure is pretty audacious. Luckily, many WILL, but the expectation is just foolish.
These alerts are absolutely not being shared publicly before we have a fix for them.
At the risk of repeating myself -- this is targeted at other OSS maintainers, not random people who might have done a git pull of some random project a couple years ago.
Defining an "era" as a "summer" is short-sighted. Calling an industry-wide efforts to find and fix security vulnerabilities with better tools "strip mining" is backwards thinking, from where I sit.
People who prefer 0days in their code baffle me.
Ignore (admittedly low-effort LLM generated) reports at your own peril.
Fact is that Mythos found only one issue in curl and nothing at all in most code bases. It is getting quiet around Mythos, and the AI companies will move on to the next scam.
In most open source projects, Mythos or similar tools have found nothing. The AI people only contact the projects where they find something, because it would be bad for marketing otherwise.