Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

How should I document the results of a security code review?

Does anyone know of any resources for reviewers that provide guidance on how they should document their findings? Maybe a document that describes best practices or makes recommendations about the best way to do it? Or, does anyone here have any recommendations for how one should write up the results and findings from a security code review and what to include in such a writeup?

share|improve this question
1  

2 Answers 2

up vote 2 down vote accepted

I would recommend the following information be included in a security code review:

Vulnerability Overview - This should include a high level overview of what was the problem that was discovered. This may also include background information on the type of vulnerability.

Severity - Determine a scale such as High, Medium and Low or something that seems applicable to the software you are reviewing.

Vulnerability Details This should include specific details relating to the vulnerability as it pertains to the software you are testing. If you have access to to the code and you can document the function in question this would be the place to point that out.

Vulnerability Remediation This is where you suggest the solution to fix the vulnerability.

Replication Technique This may or may not be optional however you can include how the vulnerability was discovered or how it can be exploited with examples.

Of course I would include a high level summary of the entire report for the management team.

share|improve this answer

Place overview of the report in the beginning. It should summarize the whole application's security in 1-2 sentences. Provide guidance based on which factors Risk Rating was chosen.

Divide report into items based on vulnerability type. If vulnerability is presented in 20 places, writing 20 items will make document larger and harder to read.

Sort them according to risk to get more attention to more critical vulnerabilities.

Include into each item:

Details:

  • PoC of exploitation if it won't take too much time (it will help to understand vulnerability)
  • Location(s). If you found protection measures, write how they can bypassed

Impact:

  • Risk rating
  • What is the worst that can happen?

Recommendation: function, library or snippet of code. Time to fix (if you can estimate it)

There are also ASVS reporting requirements. But they require presence of verification results to each passed test and therefore reports will become very large in case of code review. There are other complains too.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.