That's true of a certain class of bugs, probably mostly in the C code. I think potential security bugs in Python code will be closer to "regular" bug fixes.
While that may be true, I think that are much more infrequent, because many attack paths (such as memory overwrites leading to remote code execution) just don't exist. In many cases, it's clear that it is the application that uses the library in an insecure manner, so many security fixes involving Python code will be in the applications, not the library.
In fact, I only recall a single security-related bug fix of Python code, advisory PSF-2005-001: XML-RPC would allow to invoke arbitrary Python code. In fixing this, valid uses might have been broken, so the patch added the allow_dotted_names attribute for such applications. Clearly, quite some time went into designing a fix for this problem, much more than for a regular bug fix. This is comparatively ok, since security fixes for Python library code are so rare.
I was thinking about preventing commits on the branch. Most security fixes of the type you describe come in through the psrt, and they may even be embargoed. For a closed branch, you'd open it for the security patches when the embargo is lifted, make the commits, then close it again. That would at least be a very strong clue that the branch is closed :).
That would be fairly easy to do. If there is consensus what branches are closed, I can come up with a pre-commit hook.
Regards, Martin