We’re lucky to have a director who’s last job was as a manager (before that, pen tester) in the cyber-sec division of one of the big-four audit firms. His input has really shaped my understanding of the language we should use. He reviews all reports and generally manages to pick me up on something. Here’s how we work, with regards to the “secure or insecure” topic:
Generally, our wording is along the lines of “no vulnerabilities were detected”. This clearly communicates that we did not find any issues, however it leaves open the possibility that some flew under the radar. We also try and avoid the term “audit” as it tends to infer some form of official inspection abiding to some predefined set of rules, which does not exist in this space. We prefer to use “security review”.
We absolutely do not declare a system to be “secure”, “safe”, “vulnerability-free” or anything of the like. Firstly, such terms are absolute and in order to use them accurately you would need to arduously define the scope of the statement (e.g., does it extend to the management of the “owner” keys, does it include the security of a hash function, etc). Secondly, using such terms do not leave room for error on the reviewers behalf.
Of course, you could use some catch-all “best-effort” statement at the end of the document to cover a “secure” statement, but to me it does not seem very concise to declare a system to be absolutely something, then waive that absolute term later on. Sometimes you can’t avoid doing this (we do include and rely upon that waiver statement), but when it comes down to a final declaration of the system I think it should be as concise as possible.
Interestingly, I was pulled up on the statement “no known vulnerabilities are present”, as it could be interpreted that “known” includes all vulnerabilities known to humanity, meaning the contract is impossible to exploit at this point in time. Avoiding such ambiguity is important to us, so I would definitely say that calling something “not insecure” is either directly calling it “secure” or simply too ambiguous to be used in any official statement (using our methodology).