Advisories Have to Be Automated

I wrote recently about Harden First, Don't Wait for the Exploit. That post is about when we ship. AI finds bugs quickly, a long embargo mostly helps attackers, and hardening should go out as soon as it is ready. For rsyslog we already work that way. We harden parsers, TLS paths, and limits, often before anyone has shown that the old behavior could be exploited. Main stays shippable. Daily stable is main from that day, so a hardening change can be on your systems the next day. Please do not wait for a CVE before you update.

This is the follow-up. The security world is changing, and the part that now slows me down is not writing the hardening. It is handling the advisory around it.

Advisories have to be automated

AI now finds a large number of bugs, too many to treat each report as a small manual project.

On GitHub that project is a GitHub Security Advisory, a GHSA. There is a private conversation. There is a private fork, where the change is prepared before it is public. Then a public sequence, in order: mails, the public pull request, the merge, and the public package build. Each step is ordinary. Repeating all of them by hand does not keep up.

GHSA handling has to be automated, or the process sets the pace instead of the hardening. I do not want that. Hardening helps only when it is running. If the advisory takes longer than the code change, we are waiting again, which is what the earlier post is against.

GitHub makes the automation hard

These advisories live on GitHub, and GitHub makes them very hard to automate.

There is no API access to the advisory conversation. The thread stays inside the advisory. A program cannot read the questions, the answers, or the agreement to go public. Any step that depends on that conversation needs a person to open the page and carry the result onward. I will not have a script guess at a thread it cannot see.

Private advisory forks get no CI runs. The fork is where the not-yet-public change sits, and it is where the checks we already trust ought to run. GitHub does not start CI there. A green run on the public repository says nothing about the branch the advisory is using.

I had to set up a completely private CI infrastructure just for this. The advisory fork has no CI, so the build and the tests run on systems I operate, off GitHub, only because of this workflow. That private CI is now part of handling these advisories. Without it, the change would move toward publication without a real test of the code that is about to be public.

Scheduling is the other problem

A tested change is not a finished advisory. The mail, the public pull request, the merge, and the public package build still have to happen in order, and close enough together. They live in different systems. A report with no package, or a package with no explanation, is a failed publication even when each tool succeeded.

Coordinated timing of those steps is very hard to automate. Maybe the big players can do it. I cannot do all of it. I built scheduler VMs so part of the sequence would run without me sitting there. They do some of it. Not everything is handled automatically. What they do not start, I still start, and I still check that it happened.

The same effort is hindered by OpenAI. OpenAI cannot schedule subagents with Daybreak Blue. A lot of this work is a step at a set time, then the next step. A subagent that cannot be scheduled cannot take that on. That part stays with the maintainer.

This lands on maintainers

This is a bad fit for the current speed of AI. Reports arrive in volume. GitHub will not let a program read the advisory conversation, and it will not run CI on the private fork, so I keep a private CI to compensate. The public steps still need a schedule. The scheduler VMs cover part of it. OpenAI cannot schedule a Daybreak Blue subagent for a timed step. The rest is manual, and there is a lot of it.

That manual work lands on maintainers. It is the ordinary cost of publishing hardening at the rate the reports arrive. The code can keep moving. A hand-driven advisory process cannot move with it.

None of this is a reason to hold hardening back, or to tell users to wait. The earlier post still stands. Ship the safer build. Do not wait for a proof of exploit, and do not wait for a CVE before you update.

It is a reason to be plain about the tools. Automating GHSA handling is required, and the tools fight it. There is no API for the conversation. Private advisory forks get no CI. The timing is only partly solved, except maybe for the big players. Until that changes, maintainers will keep doing coordination that software should do, while AI keeps finding bugs this fast.

Discovery got faster. The advisory path did not. The difference is manual work, and it sits with the people who maintain the code.