From d147de93cbc2fdd8e49be69a51e5137732612b52 Mon Sep 17 00:00:00 2001 From: W Date: Fri, 25 Nov 2016 09:51:50 +0100 Subject: [PATCH] write reflection on secure development --- report/reflection.secure_development.tex | 25 ++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 report/reflection.secure_development.tex diff --git a/report/reflection.secure_development.tex b/report/reflection.secure_development.tex new file mode 100644 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. + -- 2.20.1