X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=report%2Freflection.tex;h=64342f8b9faca99c736ad08ae0bec025f1a1ff86;hb=0a9f94d402cf35d7c6f8bf4252a45ce03884919a;hp=fced26953cf9c460586ab5429e0bd83fd404eb81;hpb=4061af99d661ef8dd22657957f76bdc44495769c;p=ssproject1617.git

diff --git a/report/reflection.tex b/report/reflection.tex
index fced269..64342f8 100644
--- a/report/reflection.tex
+++ b/report/reflection.tex
@@ -1,8 +1,3 @@
-Some categories in the ASVS are easier to check than others. For example
-Section~\ref{sec:v6}. A lot of possible attack vectors were not available just
-because the were not used. In other cases the verdict was an easy fail since
-some components, like input escaping, are just not present.
-%
 %TODO
 %- Vandaag verdict (puntjes) uploaden (iedereen)!
 %- Na morgen heeft iedereen de resultaten van Fortify een keer bekeken
@@ -30,21 +25,24 @@ some components, like input escaping, are just not present.
 %   - 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}
+
+\subsection{On the bottlenecks}
+\input{reflection.bottlenecks.tex}
+
+\subsection{On the ASVS checklist}
+\input{reflection.asvs.tex}
+
+\subsection{On HP Fortify / automated code analysis tools}
+\input{reflection.tools.tex}
+
+\subsection{?}
+(TODO: Mart)
+
+\subsection{TestCMS code security}
+\input{reflection.testcms_code.tex}
+
+\subsection{On the general development of secure software}
+\input{reflection.secure_development.tex}