Merge branch 'master' of gitlab.science.ru.nl:mlubbers/ssproject1617

diff --git a/TODO.txt b/TODO.txt
index 5648089..2d13f6d 100644 (file)
--- a/TODO.txt
+++ b/TODO.txt
@@ -27,10 +27,10 @@ Reflect on the whole process, including
    and possibly also the TestCMS code.
 
 For example, questions to consider are:
-   - Kelley:  How good (useful, clear, ...) is the ASVS? How could it be improved?
-   - Charlie: How useful were code analysis tools? How could they be improved? How did you experience the rates and amounts of false and true positives? How might that be improved?
-   - Wouter:  What were the bottlenecks in doing the security review in your experience?
-   - Mart:    Maybe in the points above you can distinguish different (types of) security flaws or verification requirements. E.g., are some (categories of) verification requirements easier to check than others?
-   - 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?
+   - [x] Kelley:  How good (useful, clear, ...) is the ASVS? How could it be improved?
+   - [/] Charlie: How useful were code analysis tools? How could they be improved? How did you experience the rates and amounts of false and true positives? How might that be improved?
+   - [x] Wouter:  What were the bottlenecks in doing the security review in your experience?
+   - [ ] Mart:    Maybe in the points above you can distinguish different (types of) security flaws or verification requirements. E.g., are some (categories of) verification requirements easier to check than others?
+   - [x] 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?

diff --git a/report/reflection.secure_development.tex b/report/reflection.secure_development.tex
new file mode 100644 (file)
index 0000000..b190d8e
--- /dev/null
+++ b/report/reflection.secure_development.tex
@@ -0,0 +1,25 @@
+% 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?
+
+After our experience doing a security review of TestCMS, there are definitely
+lessons to be learned for development of easy{-}to{-}review applications.
+
+% Mark sections of code as implementing some requirement
+One could, for example, mark sections of code which treat a certain security
+requirement clearly as such. This would allow for a speed up of the reviewing
+process. The reviewers would still need to check if the marked section treat
+what they state they do, but this would still lead to a decrease in the amount
+of time spent per requirement in the OWASP guidelines.
+
+This would be for the reason that such an approach would clearly save time in
+the review, which would also increase the quality of the review and the overall
+security of the application. Of course every advantage come with certain
+disadvantages, and the disadvantage here is that such an approach would increase
+development time. This would also require more careful planning of the
+development of the application.
+
+% Last section, lets try to end with some deep insight.
+

diff --git a/report/reflection.tex b/report/reflection.tex
index 25a2043..9b3f7d1 100644 (file)
--- a/report/reflection.tex
+++ b/report/reflection.tex
@@ -48,3 +48,6 @@ some components, like input escaping, are just not present.
 
 \subsection{On the code \& streamlining subsequent security audits}
 \input{reflection.code_and_auditing.tex}
+
+\subsection{On the general development of secure software}
+\input{reflection.secure_development.tex}