Something like Claude Mythos, ChatGPT Cyber and maybe V12? Not sure if latter offers free plan for FOSS projects.
Community can share some other too if they offer free plan for FOSS projects and with sources of actual findings reported by FOSS maintainers and not benchmaxxing or sloppy articles about how good it is at finding “security vulnerabilities”.
I agree. If this hasn’t been done yet, I would very much desire for this to be done.
This seems to be some very low-hanging fruit since the overall process should not take long (applying and possibly undertaking the tests) while chances are good that at least some low-severity vulnerabilities are found.
Judging from the speed that Opus 5 (in non-fast mode) moves through my Qubes test bench with dom0 access, I would say that their models are fast in their digital movements and tests with Mythos shouldn’t take too long.
To be fair though, I also judge from marketing materials in this post.
I would also like to see this. I doubt anthropic would give Qubes Team access to mythos, I think it’s more likely for open ai to give access to chatgpt cyber. Both could be attempted though ! Or maybe a rich Qubes user could provide the necessary funds to acquire the hardware needed for something like Kimi K3 !
Good idea!
Or, hire some L33T Polish / Russian H@ker lab to pentest it? 
There shouldn’t be many lines of code to review. Does anyone know how many are there, or tried to cloc the repos?
I have been doing some research about this, about the sort of organizations that get access to less restrictive models like chatgpt cyber, daybreak blue and daybreak red. And it seems that at least daybreak blue (hopefully daybreak red) would be relatively easy for a project like Qubes to get access to. There is little cost in attempting to do so and potential high gains. @adw @unman is this something one of you could do?
I asked internally about this, and while there isn’t strict opposition to it, it would have to be done in a way that doesn’t compromise the security of any other aspect of the project. In particular, there’s a concern that GitHub-integrated tools sometimes require extensive permissions, including write access to all repos and access to private repos. The other concern is about the signal-to-noise ratio, since the security team already receives many spurious LLM-generated security reports, which are significantly more difficult to triage, since they often contain large quantities of ostensibly plausible text.
Mystifying… I am having trouble imagining the benighted thought patterns that could lead someone to invent such a tool. Could it be to ensure that the tool would only be let loose on an isolated clone of a project?
That’s very true and many projects have had issues in the past, however, most of those LLM generated ‘security findings’ are done with general purpose LLMs available to the public and are more prone to that. Daybreak red can (supposedly, can’t confirm as I don’t have access to it) independently not only find security vulnerabilities but also generate working exploits for said vulnerabilities, thus proving they are indeed real issues and not simply noise. That would significantly mitigate that one concern you described. As for the first, we would have to see how those tools would be integrated in practice. I genuinely think it would help Qubes and it’s worth at least checking out. https://openai.com/daybreak/partners/
In the current setting, AIs are skilled enough to detect critical Linux vulnerabilities that remained undetected for decades. Given the never-ending AI enhanced attack runs, detecting and fixing vulnerabilities are becoming more important than ever. I would like to know if the developers of Qubes OS, which is likely the most secure OS in existence, adopt AI to uncover vulnerabilities. If yes, in which case scenarios and with what methodology?
I love to see AI checks as well, but only if it goes without adding new security risks. In the meantime i hope more and more general Linux vulnerabilities are being checked that indirectly makes Qubes OS more secure as well.
QubesOS security relies on XEN, not linux.
Absolutely, but in many situations Linux gets tested/exposed by an attack first, let’s assume majority uses Debian/Fedora based Templates. That Linux vulnerabilities are being checked by others will increase the security of Qubes users as well. And i hope Qubes can check it’s (version of XEN) as well separately without opening the door for new security risks.
dom0 relies on Fedora 41, so the TCB of Qubes OS has more attack surface than just Xen alone.
As far as qvm-/qrexec-*, etc. are concerned, dom0 is involved in communication and functional orchestration, and ‘infrastructure’ with/for the XEN subset. Correct.
However, the security mechanism that provides strong compartmentalisation relies on XEN and VT-*/iommu (or the AMD counterparts). Not Linux (i.e. the kernel and its functions). You could change the dom0 OS to something completely different at any time, as long as the QubesOS setup/scripts could run.
I really think Qubes having access to daybreak blue or red, or perhaps even mythos, would be a real asset, and quite frankly I don’t see why the team simply doesn’t apply, Qubes Project seems almost like the perfect candidate for such programs -a well reputed security focused project that has been around for quite a while.
I believe: Not using best AI models for security reviews compromises security of the project. Evidence: Linux Kernel maintainers. https://docs. kernel . org/process/security-bugs.html
If you resorted to AI assistance to identify a bug, you must treat it as public. While you may have valid reasons to believe it is not, the security team_s experience shows that bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day. In this case, do not publicly share a reproducer, as this could cause unintended harm; just mention that one is available and maintainers might ask for it privately if they need it.
Bugs discovered simultaneously. Often on the same day. Implication. When new best model released, users rush to run security scans. Previous bugs not surfaced by human or previous model instantly visible. (Same day implies day of model release. Otherwise would trickle in. “Same day 8 days after model release” scenario unlikely.)
Malicious users also run scans. Therefore, can immediately use bugs.
Therefore, immediate adoption of new best models important.
Wouldn’t these kinds of scans be better done by upstream / xen?
Bigger project, more money and more mainstream.
Where is the line between training AI on code vulns and security / hardening against LLM’s?
I think we all want to have real people / real code compared to an LLM spiders-web of ‘vibe-coding’ and chasing your tails with the same models finding vulns and providing solutions.
Its a slippery slope and some projects (I wont mention who) are just degenerating into a vibe-coded mess where even the devs have no idea what is going on.
There could be a scenario where a vuln was found and the ‘solution’ turns out to be the very malware that was needed to bring it all down.
PS: Disclaimer: I don’t trust LLM’s. Particularly the people and companies behind them, their questionable ethics and business practices. This subject just rings to me of asking M$ to do a security audit of QubesOS.