I propose that we crowdfund to purchase an AI review of the codebase for security vulnerabilities. I think we could get strong results from just a few hundred dollars of Opus 5.5. (Even if it were thousands, it would be worth it.)
Why not? Even if I’m pretty sure they have been such analysis done in the past considering the last security reports.
So to succeed it needs to have a budget setup but I would argument that such budget should also include some percentage for the resolution. Because until now I think I had to fix almost all the security issues reported by myself. Also making a security release takes time outside of the scheduled releases.
Absolutely, the core devs should be paid for resolving issues found, though it will be difficult to know in advance how much of the budget to allocate to that. Some experimentation will be necessary to learn how to work in this new world of “throwing compute” at problems.
I think the first step is to choose an ai provider and go through their verification process so that they will recognize our efforts as white hat. Otherwise, they will hobble our analysis.
I am sure either Anthropic or OpenAI would be capable. Personally, I use Anthropic Claude Code.
This could be put on the Foundation budget of 2027.
But we also need someone who is willing to do the administrative work to get access to those LLM and someone who knows how to pilot such LLM to find real security issue.
After a more research, I think we should apply for Anthropic’s free OSS Scanner program. If they accept us, then they will run and pay for automated security analysis on an ongoing basis, using their best models.
OSS Scanner was just launched on Oct. 8. To apply, a core dev needs to make a PR to the below Anthropic repo. The PR must include certain artifacts that will guide Anthropic in making the automated scans. More details below (ai summary).
There is also an alternative track called the Cyber Verification program in which we would need to prove that this is an official project by the code maintainers. This would mean providing a formal Foundation resolution. Then we would be the ones to run the testing. To me, OSS Scanner should be pursued first.
Anthropic launched OSS Scanner this month. Established open source projects can opt in, and Anthropic then runs periodic security scans with its strongest models at no cost to the project. Reports are emailed privately to the project’s verified security contact. Each report bundles candidate findings with root-cause analysis and proposed patches. The findings are double-checked by agents but not reviewed by humans, so we would treat them as candidates to triage, not confirmed vulnerabilities.
Points relevant to us:
Acceptance is at Anthropic’s discretion, based on criteria similar to OSS-Fuzz: project maturity, number of users, criticality, and so on. I think Tryton is a reasonable candidate, but it isn’t guaranteed.
Enrollment is a pull request to anthropics/oss-scanner. It contains a small project.yaml (repository and contact), a Dockerfile that builds Tryton so the scan can run offline, and an optional threat model describing what counts as a real security boundary in Tryton.
The PR has to come from a core maintainer. Anthropic also checks that the contact address is published as the project’s security contact. So this track depends on you, not me.
The contact email in project.yaml is public. We would need to agree on which address receives reports and how they get into the existing confidential-issue process.
The service says it is meant for projects that can keep up with verified high/critical reports. That ties directly to your point about paying for fixes.
Proposed next steps for OSS Scanning:
Maintainers decide whether you want this at all, starting with the tryton/tryton monorepo. python-sql and relatorio could follow as separate enrollments later.
Agree on the report recipient address and how reports become confidential issues on the tracker.
I, Jon, would use ai to prepare enrollment files (Dockerfile, project.yaml, and a draft threat model). I test the build locally and send them to you for review. Nothing gets submitted without your approval.
Ideally the docker image should be the one that we produce but the audit should be done using the PostgreSQL backend as it is the one recommended for production.
Also should we use the last series? or the development branch? or apply for all the series?
To be clear, it does not mean that I’m volunteering to fix all the security reports, but that I’m fine to set up the email and forward it to a “security” team that will manage them on a best-effort basis.
For the first enrollment I’d keep the scope focused: latest stable series plus the development branch, using the project’s official Docker image with PostgreSQL. That gives coverage before release without triaging the same issue across every supported series. Older series can be added once the report workflow and security team are working. It would also help to decide whether findings are filed against the development branch first and then backported where relevant, so duplicate reports do not pile up.