-\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
-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 \emph{crypt()} \PHP\r
-function which uses the outdated \emph{DES} algorithm in order to encrypt data. The\r
+of problems we already detected. An example would be the use of the \code{crypt()} \PHP{}\r
+function which will, on some platforms, use the outdated \code{DES} algorithm in order to encrypt data. The\r
use of this function would pose a security risk and results in a failed check. Since\r
we where only interested in providing a verdict for each check a single occurrence of\r
this function allowed us to back-up our verdict. Fortify provides a full list of all\r
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
\r
% How did you experience the rates and amounts of false and true positives?\r
As far we where able to verify the tool didn't produce any false positives.\r
-However Fortify was not able to detect all problems we found.\r
+However, Fortify was not able to detect all problems we found.\r
Fortify concluded the application passed all checks in the \r
Error reporting and Logging (V8) section, however we detected a number of severe\r
problems in this area.\r
Since some problems occur multiple times it might be nice if Fortify was able to\r
generate a clear overview of which components of the application contain detected\r
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
+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
-(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
-In the tested code-base there is a clean distinction between an installer component and the\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
-relevant to both components the company would know which team/developer needs some major\r
+relevant to both components the company would know which team or developer needs some major\r
reeducation and who would be the best person to teach them.\r
repositories / ssproject1617.git / blobdiff