.gitignored .bak files
[ssproject1617.git] / report / reflection.tools.tex
index 1805b37..4205902 100644 (file)
@@ -1,7 +1,7 @@
 % 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
-the tool as an initial guide trough the code. This forced us to manually check\r
+the tool as an initial guide through the code. This forced us to manually check\r
 the application source which took quite some time. After the tool became available we\r
 didn't get any new insights regarding potential security risks, just more examples\r
 of problems we already detected. An example would be the use of the \code{crypt()} \PHP{}\r
@@ -18,7 +18,7 @@ In our opinion the tool could have proved very useful in pointing out certain se
 flaws in the initial stage of this project since we spent a lot of time scanning the\r
 application code-base. Since Fortify located relatively low-level problems we could\r
 have used these to locate potential hot-spots. \r
-Saving us from going trough every source file and trying to determine if they are part of the\r
+Saving us from going through every source file and trying to determine if they are part of the\r
 applications external access points. In order to improve upon the tool we suggest a larger\r
 focus on determining which parts of a application need to be secure and less on pointing\r
 out actual security flaws.\r
@@ -36,9 +36,9 @@ 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 and functions which do pass the given security check. This would allow\r
 developers to determine if they suffer from chronically malformed code \r
-(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire codebase) \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 codebase there is a clean distinction between an installer component and the\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
 relevant to both components the company would know which team or developer needs some major\r