I think it's really good to have a stated security policy of maintenance, and that you have the engineering resources to do the release -including testing.
I think you ought to make clear to all downstream that even security fixes are "best effort" and if compatibility issues surface you may not update a transient dependency with known CVEs. This is a real problem: what if there's an update to some library "random-12.0" which needs to be upgraded to "random-13.1" to fix a CVE, but that needs major code changes and could potentially break application code. What to do? Issue a potentially incompatible release or say "can't fix". Then there's the actual project's own code. A security only branch is going to make clear that when a patch goes in, it'll be security, so the changelog may prematurely leak information about a CVE which is not yet public. Saying a branch is "security and other critical stability fixes" gives you some cover, even if it is security only really. I'm thinking of a talk on this issue at the ASF conference in glasgow in october, "Open Source and CVEs -the forever war" where I want to raise this problem and discuss issues. Which i think comes down to "every lightbulb on the planet will soon needs a security update every month, whether or not that was the goal" https://news.apache.org/foundation/entry/community-over-code-europe-2026-announced-for-glasgow-scotland
