anchor.diff:  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:
  +This requires understanding the following design principles, including the 8 principles from <a href="http://web.mit.edu/Saltzer/www/publications/protection/">Saltzer and Schroeder</a>:
   <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)
  
positive.code: 
        <%= render(partial: "status_chooser", locals: {f: f, is_disabled: is_disabled,
                 criteria: "version_semver", desc: %{
  It is SUGGESTED that the Semantic Versioning (SemVer) format is
  used for releases.},
                 details: %{
  Commit IDs (or similar) MAY be used as version numbers. They are unique, but note that these can
  cause problems for users as they may not be able to determine whether or not they're up-to-date.
  
negative.code: 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
  <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).
  }}) %>
  