I keep coming back to the same conversation when I talk to people who run open source projects. They get more pull requests from strangers than they used to. The issues look like they were typed by a language model in a hurry. The clever ones do not know whether the patch in front of them is a gift or a probe. That context drain is the part nobody puts in the AI security launch announcement, and it is the part that is breaking maintainers.
GitHub closed out the fourth round of its Secure Open Source Fund earlier this summer. The shape of the program is what interests me, because the cohort results suggest that even small, structured grants change maintainer behavior at scale. The published post is worth reading once, slowly, with a notebook.
The numbers that actually moved
Across the four rounds of the fund so far, participating projects have disclosed hundreds of new CVEs, run more than a thousand automated dependency patches, and cleaned up exposed secrets at a rate the maintainers themselves did not expect. In the most recent reporting window, the cohort collectively closed out thousands of code quality and security findings, almost all of which were the kind of default that a project knows it should turn on and keeps putting off.
The single number I keep quoting is the one about defaults. Ninety-two percent of the projects in the most recent round finished the program with their core security features turned on. That is not a marketing number. That is the rate at which a focused cohort, with cash and mentorship in the same room, converts “I should” into “I did”. For open source security, that conversion is the whole game.
Why programs like this usually fail
Most security grants for open source do not produce much. The pattern is easy to spot in retrospect. Cash arrives, the maintainer spends it on hosting, and the project goes back to the same habits. Or mentorship arrives without cash, the maintainer learns a lot, and the next incident still costs them their weekend. Both halves matter, and almost no program funds them together.
What I think the fund gets right is the pairing.
- Cash without control change. The money flows through the maintainer’s existing sponsorship setup. No equity, no governance shift, no advisory board seat. For a one-person weekend project, that is the only structure that does not scare them off.
- Cash alongside named mentors. The cohort is paired with people from the GitHub Security Lab. The named relationship is what turns “you should turn this on” into “let us sit here and turn it on with you”.
- Cohort rhythm instead of one-off grants. The peer loop between maintainers doing the same unsexy work is the part most accelerator-style programs leave out, and it is the part that turns the defaults on permanently.
The lesson generalizes. If you are funding open source work, the unsexy answer is to fund the boring defaults with the boring checklist and the boring mentor pairings. The flashy answer is to fund a security moonshot. The flashy answer does not change default settings ninety-two percent of the time.
The checklist that does not need a grant
Here is the part that matters for everyone reading this who did not get into the cohort. None of the cohort’s published playbook requires a grant. None of it requires a security expert in the room. It is a list of defaults you can turn on this weekend, and the only thing it costs you is the willingness to stop telling yourself you will check the leaks later.
- Turn on the leak scanners. Secret scanning and code scanning are free on public repositories. They will not catch every leak, but they will catch the obvious ones before they ship, which is the part that actually keeps you out of the incident report.
- Enable automated dependency patching. If your platform offers it, turn it on. The pull requests will arrive while you sleep and most of them will be fine. You do not have to merge them all by hand.
- Require a quiet channel for reports. A security email in the README is not the same thing as a private disclosure workflow. Anyone running production code needs the second one.
- Audit your CI tokens every quarter. Most of the leaks that turn into incidents come from a token that should have been read only and quietly drifted to write access. Look at the audit log, not the readme.
- Write a one page incident response plan. On paper. That short. Future you at two in the morning will be very grateful past you did the boring thing.
Where AI helps and where it quietly makes things worse
One under-reported piece of the cohort’s reporting is what AI was actually used for. The pattern that worked was triage. A summarization tool can read a raw vulnerability report, suggest a likely owner, and route the report into a queue a human actually picks up. That is real time saved. The pattern that did not work was unsupervised routing. Anything that touches vulnerability details, untrusted code, or external assignment needs a person in the loop with a clear accountability path.
That distinction is the one most teams get wrong. AI-assisted triage with a human reviewer is fine. AI auto-routing of vulnerability reports to external assignees is how you wake up to a CVE that was already half-fixed in the wrong direction. The cohort projects that shipped useful AI integrations all put the reviewer step in writing. The ones that did not, did not ship the integration at all.
Trade-offs
The cohort results are real, but the selection effect is real too. Fifty projects that applied, got in, and had time to spend a quarter learning and shipping are not a random sample of the millions of public repositories a platform hosts. The ninety-two percent figure reflects what a motivated cohort produces, and a self-selected motivated cohort will outperform a random one. That is also the lesson, but it is worth holding both halves at once.
The playbook is free, but it is not free in time. The five-item checklist above is roughly a weekend for a maintainer who already knows their repository. It is longer for someone who is learning the settings for the first time. The audit step in particular is the kind of work that keeps finding more once you start, and you should budget two or three weekends instead of one if your CI is large.
Cohort artifacts do not all transfer. Mentorship pairings, the peer loop between projects, the named experts in the room. Those do not download. Defaults do. Habits do. The relationships that turn a one-time grant into long-term posture are not transferable, and a project that copies only the checklist will get a fraction of the benefit.
If you maintain anything other than a personal sandbox, the AI security question is not coming. It is already here. You can wait for a grant program to do the defaults for you, or you can turn them on this weekend. Both paths lead to the same place. The grant path adds mentorship and a peer loop. The weekend path adds nothing but the defaults. Pick the one that fits your calendar.
What to do this weekend
Pick three defaults from the checklist that you have been avoiding. Turn them on before Monday. That is the entire game. The cohort results show what a focused program can produce. The same defaults work for the projects that did not apply, did not get selected, and do not have time to wait. The cost is a weekend. The upside is the same defaults that ninety-two percent of the cohort now ship by default.