Recently I get involved in a security code review.
I found many format string, buffer overflow and dangerous libc function call.
Right now I need to write down a report with all the stuff founded in a clear and useful way.
I want to know your experience in how you organize this kind of report .
I need to caveat this with - there are a million different ways to do this, and most organisations have their own. Most of my experience in global professional services firms aims to deliver these sort of reports to heads of IT Security, CISO's and Executive boards, so your mileage may vary. A quick summary:
First: think about your audience
If delivering to IT devs and support teams, all they are going to want is a prioritised list of issues, the steps to fix, and a link to the vendor description (eg MS KB page)
If delivering to heads of department, they will want a prioritised list with an estimate of risk and likelihood of exploitation, time to fix each one, and possibly issue owners (although that may not be your responsibility)
There are other audiences, but those two are probably the most common. So it is often useful to deliver a report that is suitable for both.
What I usually prepare is an executive summary listing why the work was done (eg for an audit), high level implications of the results (usually Red/Amber/Green indicators for the board) and an estimate of time to fix. This helps senior management prioritise budget and resource. Wording here needs to be suitable to take to the board if necessary, so no technical detail!
In addition I'll include a technical appendix which has the information the remediation team will actually need in order to make the relevant fixes. This may be as simple as an excel spreadsheet.
What's the goal of the report?
Some organizations run such reports because people tell them to, have no idea what to do with them, and promptly throw it away.
Some organizations wrongly use such reports to judge the fitness of code. That's wrong, because most of the reported issues are "false positives", simple warnings of dangers, but not of practically exploitable bugs.
Some organizations, the smart ones, include this in their development process. They run such reports on a regular basis, and track over time the reductions in warnings as they go into the code and fix the problems.
Once you figure out the goal, put that as the top item, and organize things to support it.
