What Makes a Good Security Audit? | Electronic Frontier Foundation

Given these considerations, for the Scorecard we included not one but three columns that we believe are indicative of good code review practice, though they cannot categorically guarantee it:

We included a check mark for a recent audit. Audits have to be regular (at least yearly); conducted by individuals or teams other than the developers of the software; and they must examine the design and structure of the project as well the code itself. For the reasons discussed above, we don't require companies to publish their audits, and we don't ask the auditors to vouch for the tools they audited, though we require that the audits be conducted by an identifiable party.

We included a check mark for projects that publish a clear and technically detailed design document, which is essential for both external and internal review of the design; and

We included a check mark for projects which publish independently reviewable and buildable copies of their source code, which ensures that the maker of the software isn't also a gatekeeper for all white-box audits.

We did not review, judge, or vouch for the audits of each technology.

However, we wanted to both encourage communication software developers to regularly audit their code and give an indication to everyday users about which tools are at least making a systematic effort to review their codebases. In the near future we plan to publish a document to provide more detail regarding what the developers of each tool said about their audits.