anchor.diff:  The ChangeLog MAY be implemented in a variety of ways. The ChangeLog MAY be a separate file
   (e.g., "ChangeLog" or "changelog") and the filename MAY be followed by an extension such as
   ".txt", ".md", or ".html". The ChangeLog MAY instead use version control system mechanisms
  -such as the GitHub Releases workflow.<br>
  +such as the
  +<a href="https://github.com/blog/1547-release-your-software">GitHub Releases workflow</a>.<br>
   <b>Rationale</b>: ChangeLogs are important because they help users decide whether or not they
   will want to update, and what the impact would be (e.g., if the new release fixes vulnerabilities).
   }}) %>
  
positive.code: At least one of the primary developers
  MUST know how to design secure software.},
               details: %{
  This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:
  <ul>
  <li>economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
  <li>fail-safe defaults (access decisions should deny by default)
  
negative.code: to high severity if its <a href="https://nvd.nist.gov/cvss.cfm">CVSS 2.0</a> base score is 4 or higher.
  <br><br>
  <b>Note</b>: this means that users might be left vulnerable to all attackers
  worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in
  <a href="http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html">Rebooting responsible disclosure</a>, because Google recommends that the 60-day period start when the project is notified <em>even</em> if the report is not public.<br>
  <b>Rationale</b>: We intentionally chose to start measurement from the time of public knowledge,
  and not from the time reported to the project, because this is much easier to measure and
  verify by those outside the project.
  