% - 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.
+
+\subsection{On our auditing process}
+\input{reflection.auditing_process.tex}
+
+(TODO: Wouter)
+
+\subsection{On the ASVS checklist}
+\input{reflection.asvs.tex}
+
+\subsection{On HP Fortify / automated code analysis tools}
+(TODO: Charlie)
+
+\subsection{?}
+(TODO: Mart)
+
+\subsection{On the code \& streamlining subsequent security audits}
+\input{reflection.code_and_auditing.tex}
repositories / ssproject1617.git / blobdiff