the tool as an initial guide trough 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
\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
-(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire code-base) \r
+(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire codebase) \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
+In the tested codebase 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