check reflection

diff --git a/report/reflection.tex b/report/reflection.tex
index a43fc17..64342f8 100644 (file)
--- 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

diff --git a/report/reflection.tools.tex b/report/reflection.tools.tex
index 8666dc1..12a7f5f 100644 (file)
--- a/report/reflection.tools.tex
+++ b/report/reflection.tools.tex
@@ -1,4 +1,3 @@
-\r
 % How useful were code analysis tools?\r
 The usefulness of the Fortify Static Code Analysis tool turned out to be very limited.\r
 Since we had most verdicts ready before a license was provided we couldn't use\r
@@ -37,8 +36,8 @@ generate a clear overview of which components of the application contain detecte
 problems. This could be very useful in combination with the information about\r
 components/functions which do pass the given security check. This would allow\r
 developers to determine if they suffer from chronically malformed code \r
-(eg. all relevant code fails the check, indicating a very serious problem throughout the entire code-base) \r
-or a single error (eg. most relevant code passes the check except for a few isolated cases).\r
+(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire code-base) \r
+or a single error (e.g. most relevant code passes the check except for a few isolated cases).\r
 In the tested code-base there is a clean distinction between an installer component and the\r
 actual web application. If the installer suffers from problems not present in\r
 the web application and Fortify would be able to point out the specific check is\r