\CMS{}. This was easy, because one of us had made a \code{Dockerfile} for the
others to use. This made running and installing the application trivially
easy. Running the application made us understand the outline and components of
-the application. We could also find some spots were easy to find vulnerabilities
+the application. We could also find some spots where easy to find vulnerabilities
could be expected. However, looking at the source code was more effective,
especially when verifying that the \CMS{} \emph{passes} a requirement. Buggy code
is easy to find. Bugless code is not.
and move on.
This went well, because with five people the individual workload is just not
-that big. Furthermore, finding vulnerabilities is a lot easier that verifying
-the security in a lot of cases. This speeds up the auditing process, because
+that big. Furthermore, finding vulnerabilities is a lot easier than verifying
+the security in a lot of cases. This sped up the auditing process, because
the \CMS{} turned out to not satisfy the ASVS in most cases.
% Use of Fortify
Because we were on track early, most of the audit was already done by when we
were introduced to the Fortify tool. Nonetheless, we used it to verify our own
verdicts. Some of us have installed and used the Fortify tool itself. These
-students have exported a PDF report, which the others could then use.
+students exported a PDF report and described the results, which the others
+could then use.
% Double-checking process
-When we finished the report, each of us has reread each others' parts to check
+When we finished the report, each of us reread the other parts to check
if things had been missed or reported incorrect. This may not have thorough, but
because in the end five pairs of eyes have read all verdicts, we trust that, in
-the end, all verdicts are sufficiently checked.
+the end, we feel all verdicts are sufficiently checked.
repositories / ssproject1617.git / blobdiff