report/reflection.secure_development.tex

   1 % Wouter:  This last question might be generalised, to (web) applications in
   2 % general, rather than this specific example of the TestCMS: ie. if you were to
   3 % develop an application that will need to be subjected to a security review,
   4 % would you do anything differently, given your experience in doing this, and if
   5 % so, what and why?
   6
   7 After our experience doing a security review of TestCMS, there are definitely
   8 lessons to be learned for development of easy{-}to{-}review applications.
   9
  10 % Mark sections of code as implementing some requirement
  11 One could, for example, mark sections of code which treat a certain security
  12 requirement clearly as such. This would allow for a speed up of the reviewing
  13 process. The reviewers would still need to check if the marked section treat
  14 what they state they do, but this would still lead to a decrease in the amount
  15 of time spent per requirement in the OWASP guidelines.
  16
  17 This would be for the reason that such an approach would clearly save time in
  18 the review, which would also increase the quality of the review and the overall
  19 security of the application. Of course every advantage come with certain
  20 disadvantages, and the disadvantage here is that such an approach would increase
  21 development time. This would also require more careful planning of the
  22 development of the application.
  23
  24 % Last section, lets try to end with some deep insight.
  25