It's aliiiiiive! Documenting for security as a process
There's something about the standard practice of how we document security assessments that's been bothering me for a while now. If I had to summarize it, I'd say it's about treating the documentation of a security audit as a final product rather than an input to an ongoing process. Let me illustrate what I mean. Pretty much any report template that I've ever been given was structured around listing the vulnerabilities identified during the audit. On some engagements, there was no expectation of a final report. Instead, the work products were issues filed in a bug tracker. In these cases, the number and severity of issues filed were also used as a measurement of productivity. But when I document my security assessments, my process looks fairly different in that I also keep copious notes on coverage: What have I looked at (even if I didn't find anything there)? What were the attack vectors that I investigated, including the ones that didn't pan out? Why did th...