Add "next time..." reflection

diff --git a/report/reflection.tex b/report/reflection.tex
index dc643ce..fced269 100644 (file)
--- a/report/reflection.tex
+++ b/report/reflection.tex
@@ -28,3 +28,23 @@ some components, like input escaping, are just not present.
 %   - Daan:    If you would have to do something like this again, what would you do differently? Eg. about organising things within the group: i.e., in retrospect, what do you think the best approach is to organise and divide the work in a team? (Dividing the verification requirements over the team members? Or by dividing the code? Or letting everyone look at everything, because different people will spot different things? Or work in pairs where one person confirms the findings of the other? ...)
 %   - Kelley:  About the TestCMS code: are there important aspects that could (or should) be changed to improve security? Or aspects that could be changed to facilitate doing a security review?
 %   - Wouter:  This last question might be generalised, to (web) applications in general, rather than this specific example of the TestCMS: ie. if you were to develop an application that will need to be subjected to a security review, would you do anything differently, given your experience in doing this, and if so, what and why?
+
+
+% Daan: If you would have to do something like this again? (...)
+We have noticed that, when doing an audit in a team, it is not feasible for
+everybody to have read all source code. Henceforth, trying this is just a bad
+idea. We are happy to have divided the project by ASVS category, instead of
+program component. For each requirement the the ASVS, the
+team had to verify that there were no mistakes in the code. This would have
+taken a lot of time if we had to verify each component for each requirement.
+Furthermore, the ASVS is an easy guide for dividing the work\footnote{The
+categories in the ASVS are all of similar size. We settled on giving each team
+member two categories to check.}. Dividing by component would have been a lot
+harder to do fairly, especially because when beginning the project we had
+little knowledge of the internals (and component sizes) of the CMS.
+
+We haven't experimented by working in pairs. This might be a good idea to
+experiment with. We are confident however that, because we have all checked
+each other's finished work (and the final product), we did not miss any
+problems.
+In the end, we are satisfied with the way we have done things.