This was triggered by a post on security audits at https://mailman.stanford.edu/pipermail/liberationtech/2013-July/009795.html.
While we have reasonably good documentation on our security architecture, we have various security critical classes/functions scattered all over the place with nothing tying them together in a way that an auditor (or interested person) could identify this code and understand/test it.
My suggestion would be to consider adding a @security doxygen tag to all the "critical path" security related classes/functions. By "critical path" I mean code that if an auditor is satisfied is secure, their only other task is to ensure that all other code is using that API/system for that function. So, we don't need to identify every function that calls check_plain - but we should tag check_plain itself. This can include code related to authentication, authorization, https, sessions, random numbers, password hashing, output filtering and so forth.
Once we have this code identified, a good second step would be to ensure the documentation is sufficiently detailed (from a security point of view - see the great checklist at https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet for the kind of questions we might want to pre-empt) and also carefully review the test coverage, and add more if needed. I am not sure if there is a way of tagging tests also (without grouping them together, which might be overkill), but that might also be worth considering.
We might also consider moving any critical functions that are floating around in "miscellaneous" code (common.inc, I am looking at you) to there own include files or classes. I think that is lower priority though, and perhaps a 9.x task.