Update links to OWASP ZAP which had rotted

config/locales/en.yml

@@ -2031,8 +2031,8 @@ en:
           it with specific inputs. For example, the project MAY
           use a fuzzing tool (e.g., <a href="http://lcamtuf.coredump.cx/afl/">American
           Fuzzy Lop</a>) or a web application scanner (e.g., <a
-          href="https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project">OWASP
-          ZAP</a> or <a href="https://w3af.org/">w3af</a>). In
+          href="https://www.zaproxy.org">Zed Attack Proxy</a>
+          or <a href="https://w3af.org/">w3af</a>). In
           some cases the <a href="https://github.com/google/oss-fuzz#introduction">OSS-Fuzz</a>
           project may be willing to apply fuzz testing to your
           project. For purposes of this criterion the dynamic

docs/criteria.md

@@ -456,7 +456,7 @@ There is an implied criterion that we should mention here:
 
 <ul>
 
-<li><a name="dynamic_analysis"></a>It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release. <sup>[<a href="#dynamic_analysis">dynamic_analysis</a>]</sup><dl><dt><i>Details</i>:<dt> <dd>A dynamic analysis tool examines the software by executing it with specific inputs. For example, the project MAY use a fuzzing tool (e.g., <a href="http://lcamtuf.coredump.cx/afl/">American Fuzzy Lop</a>) or a web application scanner (e.g., <a href="https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project">OWASP ZAP</a> or <a href="https://w3af.org/">w3af</a>). In some cases the <a href="https://github.com/google/oss-fuzz#introduction">OSS-Fuzz</a> project may be willing to apply fuzz testing to your project. For purposes of this criterion the dynamic analysis tool needs to vary the inputs in some way to look for various kinds of problems <em>or</em> be an automated test suite with at least 80% branch coverage. The <a href="https://en.wikipedia.org/wiki/Dynamic_program_analysis">Wikipedia page on dynamic analysis</a> and the <a href="https://www.owasp.org/index.php/Fuzzing">OWASP page on fuzzing</a> identify some dynamic analysis tools. The analysis tool(s) MAY be focused on looking for security vulnerabilities, but this is not required.</dd><dt><i>Rationale</i>:<dt> <dd>Static source code analysis and dynamic analysis tend to find different kinds of defects (including defects that lead to vulnerabilities), so combining them is more likely to be effective. For example, <a href="https://www.mail-archive.com/[email protected]/msg1513352.html">Linus Torvalds' "Linux 4.14-rc5" announcement (October 15, 2017)</a> notes that "(people are doing) random fuzzing... and it's finding things...  Very nice to see."
+<li><a name="dynamic_analysis"></a>It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release. <sup>[<a href="#dynamic_analysis">dynamic_analysis</a>]</sup><dl><dt><i>Details</i>:<dt> <dd>A dynamic analysis tool examines the software by executing it with specific inputs. For example, the project MAY use a fuzzing tool (e.g., <a href="http://lcamtuf.coredump.cx/afl/">American Fuzzy Lop</a>) or a web application scanner (e.g., <a href="https://www.zaproxy.org">Zed Attack Proxy</a> or <a href="https://w3af.org/">w3af</a>). In some cases the <a href="https://github.com/google/oss-fuzz#introduction">OSS-Fuzz</a> project may be willing to apply fuzz testing to your project. For purposes of this criterion the dynamic analysis tool needs to vary the inputs in some way to look for various kinds of problems <em>or</em> be an automated test suite with at least 80% branch coverage. The <a href="https://en.wikipedia.org/wiki/Dynamic_program_analysis">Wikipedia page on dynamic analysis</a> and the <a href="https://www.owasp.org/index.php/Fuzzing">OWASP page on fuzzing</a> identify some dynamic analysis tools. The analysis tool(s) MAY be focused on looking for security vulnerabilities, but this is not required.</dd><dt><i>Rationale</i>:<dt> <dd>Static source code analysis and dynamic analysis tend to find different kinds of defects (including defects that lead to vulnerabilities), so combining them is more likely to be effective. For example, <a href="https://www.mail-archive.com/[email protected]/msg1513352.html">Linus Torvalds' "Linux 4.14-rc5" announcement (October 15, 2017)</a> notes that "(people are doing) random fuzzing... and it's finding things...  Very nice to see."
 </dd></dl></li>
 
 <li><a name="dynamic_analysis_unsafe"></a>It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). (N/A allowed.) <sup>[<a href="#dynamic_analysis_unsafe">dynamic_analysis_unsafe</a>]</sup><dl><dt><i>Details</i>:<dt> <dd>Examples of mechanisms to detect memory safety problems include <a href="https://github.com/google/sanitizers/wiki/AddressSanitizer">Address Sanitizer (ASAN)</a> (available in GCC and LLVM), <a href="https://clang.llvm.org/docs/MemorySanitizer.html">Memory Sanitizer</a>, and <a href="http://valgrind.org/">valgrind</a>. Other potentially-used tools include <a href="https://clang.llvm.org/docs/ThreadSanitizer.html">thread sanitizer</a> and <a href="https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html">undefined behavior sanitizer</a>. Widespread assertions would also work.</dd></dl></li>