From 8c87f17ee7258cdef41ba1df48b75b82cbbdcced Mon Sep 17 00:00:00 2001
From: "David A. Wheeler" <dwheeler@dwheeler.com>
Date: Fri, 2 Oct 2015 15:47:09 -0400
Subject: [PATCH] Change edit form so criteria short name is superscripted
 (!bold), issue #58

---
 BadgeApp/app/views/projects/_form.html.erb | 122 ++++++++++-----------
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/BadgeApp/app/views/projects/_form.html.erb b/BadgeApp/app/views/projects/_form.html.erb
index fcbf3a86e..dbf07b865 100644
--- a/BadgeApp/app/views/projects/_form.html.erb
+++ b/BadgeApp/app/views/projects/_form.html.erb
@@ -43,7 +43,7 @@
       <div class='col-md-9 criteria-desc'>
          <span>The project website MUST succinctly describe what the software does
                (what problem does it solve?), in language that potential users can
-               understand (e.g., it uses minimal jargon). <strong>[description-sufficient]</strong></span>
+               understand (e.g., it uses minimal jargon). <sup>[description-sufficient]</sup></span>
 
          <%= f.text_field :description_sufficient_justification, class:"form-control", hide_label: true, placeholder:'Please explain' %>
       </div>
@@ -64,7 +64,7 @@
       </div>
       <div class="col-md-9 criteria-desc">
          <span>The project website MUST provide information on how to: obtain,provide feedback
-              (as bug reports or enhancements), and contribute to the sofware. <strong>[interact]</strong></span>
+              (as bug reports or enhancements), and contribute to the sofware. <sup>[interact]</sup></span>
          <%= f.text_field :interact_justification, class:"form-control", hide_label: true, placeholder:'Please explain' %>
       </div>
       </div>
@@ -84,7 +84,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
          <span>The project website MUST provide information on how to: obtain,provide feedback
-              (as bug reports or enhancements), and contribute to the sofware. <strong>[contribution]</strong></span>
+              (as bug reports or enhancements), and contribute to the sofware. <sup>[contribution]</sup></span>
          <%= f.text_field :contribution_justification, class:"form-control", hide_label: true, placeholder:'Please explain' %>
       </div>
       </div>
@@ -104,7 +104,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
          <span>The project website MUST provide information on how to: obtain, provide feedback
-              (as bug reports or enhancements), and contribute to the sofware. <strong>[contribution-criteria]</strong></span>
+              (as bug reports or enhancements), and contribute to the sofware. <sup>[contribution-criteria]</sup></span>
          <%= f.text_field :contribution_criteria_justification, class:"form-control", hide_label: true, placeholder:'Please explain' %>
       </div>
       </div>
@@ -125,7 +125,7 @@
        </div>
        <div class='col-md-9 criteria-desc'>
           <span>License(s) MUST be posted in a standard location (e.g., as a top-level file named LICENSE or COPYING).
-             License filenames MAY be followed by an extension such as ".txt" or ".md") <strong>[license-location]</strong></span>
+             License filenames MAY be followed by an extension such as ".txt" or ".md") <sup>[license-location]</sup></span>
           <%= f.text_field :license_location_justification, class:"form-control", hide_label: true, placeholder:'Please explain' %>
        </div>
        </div>
@@ -148,7 +148,7 @@
           an approved license by the Open Source Initiative (OSI)
           a free license as approved by the Free Software Foundation (FSF)
           a free license acceptable to Debian main
-          a "good" license according to Fedora. <strong>[oss-license]</strong></span>
+          a "good" license according to Fedora. <sup>[oss-license]</sup></span>
        <%= f.text_field :oss_license_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -167,7 +167,7 @@
         <% end %>
       </div>
       <div class='col-md-9 criteria-desc'>
-      <span>It is SUGGESTED that any required license(s) be OSI-approved. <strong>[oss-license-osi]</strong> </span>
+      <span>It is SUGGESTED that any required license(s) be OSI-approved. <sup>[oss-license-osi]</sup> </span>
       <%= f.text_field :oss_license_osi_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -202,7 +202,7 @@
             how to install it, how to start it, how to use it (possibly with a tutorial using examples), and
             how to use it securely (e.g., what to do and what not to do) if that is an appropriate topic for the software.
             The security documentation need not be long (it is better for the software to be designed to be secure by default).
-            <strong>[documentation-basics]</strong></span>
+            <sup>[documentation-basics]</sup></span>
       <%= f.text_field :documentation_basics_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -222,7 +222,7 @@
      </div>
      <div class='col-md-9 criteria-desc'>
      <span>The project MUST include reference documentation that describes its interface.
-           <strong>[documentation-interface]</strong></span>
+           <sup>[documentation-interface]</sup></span>
      <%= f.text_field :documentation_interface_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
      <br>
      <!--span>The project MAY use hypertext links to non-project material as documentation,
@@ -248,7 +248,7 @@
        </div>
        <div class='col-md-9 criteria-desc'>
        <span>The project MUST have a version-controlled source repository that is publicly readable and has
-             a URL (the URL MAY be the same as the project URL). <strong>[repo-url]</strong></span>
+             a URL (the URL MAY be the same as the project URL). <sup>[repo-url]</sup></span>
        <%= f.text_field :repo_url_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
        </div>
        </div>
@@ -268,7 +268,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>The source repository MUST track what changes were made, who made the changes,
-            and when the changes were made. <strong>[repo-track]</strong></span>
+            and when the changes were made. <sup>[repo-track]</sup></span>
       <%= f.text_field :repo_track_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -288,7 +288,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>The source repository MUST include interim versions for review between releases;
-            it MUST NOT include only final releases. <strong>[repo-interim]</strong> </span>
+            it MUST NOT include only final releases. <sup>[repo-interim]</sup> </span>
       <%= f.text_field :repo_interim_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -309,7 +309,7 @@
       <div class='col-md-9 criteria-desc'>
         <span>It is SUGGESTED that common distributed version control software is used (e.g., git).
             Git is not specifically required and projects can use centralized version control software
-            (such as subversion) with justification. <strong>[repo-distributed]</strong> </span>
+            (such as subversion) with justification. <sup>[repo-distributed]</sup> </span>
         <%= f.text_field :repo_distributed_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -339,7 +339,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>The project MUST have a unique version number for each release intended
-            to be used by users. <strong>[version-unique]</strong></span>
+            to be used by users. <sup>[version-unique]</sup></span>
       <%= f.text_field :version_unique_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -359,7 +359,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that the Semantic Versioning (SemVer) format is
-            used for releases. <strong>[version-semver]</strong></span><br>
+            used for releases. <sup>[version-semver]</sup></span><br>
       <%= f.text_field :version_semver_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       <span>Commit IDs (or similar) MAY be used as 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.</span>
@@ -382,7 +382,7 @@
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that projects identify each release within their version control system.
             For example, it is SUGGESTED that those using git identify each
-            release using git tags. <strong>[version-tags]</strong></span>
+            release using git tags. <sup>[version-tags]</sup></span>
       <%= f.text_field :version_tags_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -404,7 +404,7 @@
       <div class='col-md-9 criteria-desc'>
       <span>The project MUST provide a "ChangeLog" (a human-readable summary of major changes in each release).
             The ChangeLog MUST NOT be the output of the version control log of every change
-            (e.g., the "git log" command is not a ChangeLog). <strong>[changelog]</strong></span>
+            (e.g., the "git log" command is not a ChangeLog). <sup>[changelog]</sup></span>
       <%= f.text_field :changelog_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -424,7 +424,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
         <span>The ChangeLog MUST identify whether the new release fixes any publicly
-              known vulnerabilities. <strong>[changelog-vulns]</strong></span>
+              known vulnerabilities. <sup>[changelog-vulns]</sup></span>
         <%= f.text_field :changelog_vulns_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -454,7 +454,7 @@
        <% end %>
       </div>
       <div class='col-md-9 criteria-desc'>
-      <span>If an issue tracker is used, please provide its URL. <strong>[report-url]</strong></span>
+      <span>If an issue tracker is used, please provide its URL. <sup>[report-url]</sup></span>
       <%= f.text_field :report_url_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -474,7 +474,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that an issue tracker be used for tracking
-            individual issues. <strong>[report-tracker]</strong></span>
+            individual issues. <sup>[report-tracker]</sup></span>
       <%= f.text_field :report_tracker_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -494,7 +494,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>The project MUST provide a process for users to submit bug reports
-            (e.g., using an issue tracker or a mailing list). <strong>[report-process]</strong></span>
+            (e.g., using an issue tracker or a mailing list). <sup>[report-process]</sup></span>
       <%= f.text_field :report_process_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -514,7 +514,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>Developers MUST respond to most bug reports submitted in the last
-            2-12 months (inclusive); the response need not include a fix. <strong>[report-responses]</strong></span>
+            2-12 months (inclusive); the response need not include a fix. <sup>[report-responses]</sup></span>
       <%= f.text_field :report_responses_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -534,7 +534,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>Developers SHOULD respond to most enhancement requests in the last 2-12 months
-            (inclusive). Developers MAY choose not to respond. <strong>[enhancement-responses]</strong></span>
+            (inclusive). Developers MAY choose not to respond. <sup>[enhancement-responses]</sup></span>
       <%= f.text_field :enhancement_responses_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -553,7 +553,7 @@
        <% end %>
       </div>
       <div class='col-md-9 criteria-desc'>
-      <span>Reports and responses MUST be archived for later searching. <strong>[report-archive]</strong></span>
+      <span>Reports and responses MUST be archived for later searching. <sup>[report-archive]</sup></span>
       <%= f.text_field :report_archive_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -576,7 +576,7 @@
       <div class='col-md-9 criteria-desc'>
       <span>The project MUST publish the process for reporting vulnerabilities on the project site
             (e.g., a clearly designated mailing address on https://PROJECTSITE/security, often security@SOMEWHERE);
-            this MAY be the same as its bug reporting process. <strong>[vulnerability-report-process]</strong></span>
+            this MAY be the same as its bug reporting process. <sup>[vulnerability-report-process]</sup></span>
       <%= f.text_field :vulnerability_report_process_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -599,7 +599,7 @@
             to send the information in a way that is kept private (e.g., a private defect
             report submitted on the web using TLS or an email encrypted using PGP).
             If private vulnerability reports are not supported this criterion is
-            automatically met. <strong>[vulnerability-report-private]</strong></span>
+            automatically met. <sup>[vulnerability-report-private]</sup></span>
       <%= f.text_field :vulnerability_report_private_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -621,7 +621,7 @@
       <span>The project MUST provide an initial reply to a security vulnerability report
             sent to the project, on average, less than 7 days within the last 6 months.
             (If a project is being spammed on its vulnerability report channel,
-            it is okay to only count non-spam messages.) <strong>[vulnerability-report-response]</strong></span>
+            it is okay to only count non-spam messages.) <sup>[vulnerability-report-response]</sup></span>
       <%= f.text_field :vulnerability_report_response_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -645,7 +645,7 @@
       <span>If the software requires building for use, the project MUST provide a working
             build system that can automatically rebuild the software from source code.
             A build system determines what actions need to occur to rebuild the software (and in what order),
-            and then performs those steps.  <strong>[build-status]</strong></span>
+            and then performs those steps.  <sup>[build-status]</sup></span>
       <%= f.text_field :build_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -667,7 +667,7 @@
       <span>It is SUGGESTED that common tools be used for building the software
             (e.g., Maven, Ant, cmake, the autotools, make, or rake), in which case
             only the instructions to the build system are required (there's no requirement
-            to teach people how to use common tools). <strong>[build-common-tools]</strong></span>
+            to teach people how to use common tools). <sup>[build-common-tools]</sup></span>
       <%= f.text_field :build_common_tools_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -686,7 +686,7 @@
        <% end %>
       </div>
       <div class='col-md-9 criteria-desc'>
-      <span>The project SHOULD be buildable using only OSS tools. <strong>[build-oss-tools]</strong></span>
+      <span>The project SHOULD be buildable using only OSS tools. <sup>[build-oss-tools]</sup></span>
       <%= f.text_field :build_oss_tools_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -710,7 +710,7 @@
        <% end %>
       </div>
       <div class='col-md-9 criteria-desc'>
-      <span>The project MUST have at least one automated test suite. <strong>[test]</strong></span>
+      <span>The project MUST have at least one automated test suite. <sup>[test]</sup></span>
       <%= f.text_field :test_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -730,7 +730,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>A test suite SHOULD be invocable in a standard way for that language
-            (e.g., "make check", "mvn test", and so on). <strong>[test-invocation]</strong></span>
+            (e.g., "make check", "mvn test", and so on). <sup>[test-invocation]</sup></span>
       <%= f.text_field :test_invocation_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -750,7 +750,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that the test suite cover most (or ideally all) the code branches,
-            input fields, and functionality. <strong>[test-most]</strong></span>
+            input fields, and functionality. <sup>[test-most]</sup></span>
       <%= f.text_field :test_most_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -779,7 +779,7 @@
       <div class='col-md-9 criteria-desc'>
       <span>The project MUST have a general policy (formal or not) that as major
             new functionality is added, tests of that functionality SHOULD
-            be added to an automated test suite. <strong>[test-policy]</strong></span>
+            be added to an automated test suite. <sup>[test-policy]</sup></span>
       <%= f.text_field :test_policy_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -801,7 +801,7 @@
       <span>The project MUST have evidence that such tests are being added in
             the most recent major changes to the project. Major functionality would typically
             be mentioned in the ChangeLog. (Perfection is not required, merely evidence
-            that tests are typically being added in practice.) <strong>[tests-are-added]</strong></span>
+            that tests are typically being added in practice.) <sup>[tests-are-added]</sup></span>
       <%= f.text_field :tests_are_added_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -822,7 +822,7 @@
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that this be documented in the instructions for change proposals,
             but even an informal rule is acceptable as long as the tests are being
-            added in practice. <strong>[tests-documented-added]</strong></span>
+            added in practice. <sup>[tests-documented-added]</sup></span>
       <%= f.text_field :tests_documented_added_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -846,7 +846,7 @@
             a "safe" language mode (e.g., "use strict", "use warnings", or similar),
             and/or use a separate "linter" tool to look for code quality errors or
             common simple mistakes, if there is at least one OSS tool that can implement
-            this criterion in the selected language. <strong>[warnings]</strong></span>
+            this criterion in the selected language. <sup>[warnings]</sup></span>
       <%= f.text_field :warnings_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -868,7 +868,7 @@
       <span>The project MUST address the issues that are found (by fixing them or
             marking them in the source code as false positives). Ideally there would be no warnings,
             but a project MAY accept some warnings (typically less than 1 warning
-            per 100 lines or less than 10 warnings). <strong>[warnings-fixed]</strong></span>
+            per 100 lines or less than 10 warnings). <sup>[warnings-fixed]</sup></span>
       <%= f.text_field :warnings_fixed_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -888,7 +888,7 @@
       </div>
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that projects be maximally strict, but this is not
-            always practical. <strong>[warnings-strict]</strong></span>
+            always practical. <sup>[warnings-strict]</sup></span>
       <%= f.text_field :warnings_strict_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -922,7 +922,7 @@
           limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
           input validation with whitelists (inputs should typically be checked to determine if they are valid before they are accepted;
           this validation should use whitelists (which only accept known-good values),
-          not blacklists (which attempt to list known-bad values)) <strong>[know-secure-design]</strong></span>
+          not blacklists (which attempt to list known-bad values)) <sup>[know-secure-design]</sup></span>
     <%= f.text_field :know_secure_design_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -946,7 +946,7 @@
           to counter or mitigate each of them. Examples (depending on the type of software)
           include SQL injection, OS injection, classic buffer overflow, cross-site scripting,
           missing authentication, and missing authorization. See the CWE/SANS top 25 or OWASP
-          Top 10 for commonly-used lists. <strong>[know-common-errors]</strong></span>
+          Top 10 for commonly-used lists. <sup>[know-common-errors]</sup></span>
     <%= f.text_field :know_common_errors_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -970,7 +970,7 @@
     <div class='col-md-9 criteria-desc'>
     <span>Cryptographic protocols and algorithms used by default in the software AND
           the delivery mechanisms MUST be publicly published and reviewed
-          by experts. <strong>[crypto-published]</strong></span>
+          by experts. <sup>[crypto-published]</sup></span>
     <%= f.text_field :crypto_published_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -991,7 +991,7 @@
     <div class='col-md-9 criteria-desc'>
     <span>Application software that is not itself a cryptographic system/library MUST NOT
           implement its own cryptographic functions, but MUST instead call on software
-          specifically designed for the purpose. <strong>[crypto-call]</strong></span>
+          specifically designed for the purpose. <sup>[crypto-call]</sup></span>
     <%= f.text_field :crypto_call_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1012,7 +1012,7 @@
     <div class='col-md-9 criteria-desc'>
     <span>All functionality that depends on cryptography MUST be implementable using
           OSS because its specification meets the Open Standards Requirement for Software
-          by the Open Source Initiative. <strong>[crypto-oss]</strong></span>
+          by the Open Source Initiative. <sup>[crypto-oss]</sup></span>
     <%= f.text_field :crypto_oss_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1038,7 +1038,7 @@
           The software MUST be configurable so that it will reject smaller keylengths.
           The software MAY allow smaller keylengths in some configurations (ideally it would not, since this allows
           downgrade attacks, but shorter keylengths are sometimes necessary for
-          interoperability.) <strong>[crypto-keylength]</strong></span>
+          interoperability.) <sup>[crypto-keylength]</sup></span>
     <%= f.text_field :crypto_keylength_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1062,7 +1062,7 @@
           It is SUGGESTED that SHA-1 not be used (we are well aware that git uses SHA-1).
           Currently-recommended algorithms include AES and SHA-256/SHA-512. Implementations SHOULD
           support multiple cryptographic algorithms, so users can quickly switch
-          if one is broken.  <strong>[crypto-working]</strong></span>
+          if one is broken.  <sup>[crypto-working]</sup></span>
     <%= f.text_field :crypto_working_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1083,7 +1083,7 @@
     <div class='col-md-9 criteria-desc'>
     <span>Any key agreement protocol SHOULD implement perfect forward secrecy so a session key
           derived from a set of long-term keys cannot be compromised if one of the long-term keys
-          is compromised in the future. <strong>[crypto-pfs]</strong></span>
+          is compromised in the future. <sup>[crypto-pfs]</sup></span>
     <%= f.text_field :crypto_pfs_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1103,7 +1103,7 @@
     </div>
     <div class='col-md-9 criteria-desc'>
     <span>If passwords for later authentication are stored, they MUST be stored as
-          iterated hashes with per-user salt. <strong>[crypto-password-storage]</strong></span>
+          iterated hashes with per-user salt. <sup>[crypto-password-storage]</sup></span>
     <%= f.text_field :crypto_password_storage_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1123,7 +1123,7 @@
     </div>
     <div class='col-md-9 criteria-desc'>
     <span>All keys and nonces MUST be generated using cryptographically random functions,
-          and not through non-cryptographically random functions. <strong>[crypto-random]</strong></span>
+          and not through non-cryptographically random functions. <sup>[crypto-random]</sup></span>
     <%= f.text_field :crypto_random_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1151,7 +1151,7 @@
           Using https or ssh+scp is acceptable. An even stronger mechanism is releasing
           the software with digitally signed packages, since that mitigates attacks on the distribution system,
           but this only works if the users can be confident that the public keys for signatures are correct
-          and if the users will actually check the signature. <strong>[delivery-mitm]</strong></span>
+          and if the users will actually check the signature. <sup>[delivery-mitm]</sup></span>
     <%= f.text_field :delivery_mitm_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1172,7 +1172,7 @@
     <div class='col-md-9 criteria-desc'>
     <span>A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and
           used without checking for a cryptographic signature, since these hashes
-          can be modified in transit. <strong>[delivery-unsigned]</strong></span>
+          can be modified in transit. <sup>[delivery-unsigned]</sup></span>
     <%= f.text_field :delivery_unsigned_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1200,7 +1200,7 @@
           in the National Vulnerability Database) or when the project has been informed and the
           information has been released to the public (possibly by the project). A vulnerability is medium
           to high severity if its CVSS 2.0 base score is 4 or higher.
-          <strong>[vulnerabilities-fixed-60-days]</strong></span>
+          <sup>[vulnerabilities-fixed-60-days]</sup></span>
     <%= f.text_field :vulnerabilities_fixed_60_days_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1220,7 +1220,7 @@
     </div>
     <div class='col-md-9 criteria-desc'>
     <span>Projects SHOULD fix all critical vulnerabilities rapidly after they
-          are reported. <strong>[vulnerabilities-critical-fixed]</strong></span>
+          are reported. <sup>[vulnerabilities-critical-fixed]</sup></span>
     <%= f.text_field :vulnerabilities_critical_fixed_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
     </div>
     </div>
@@ -1259,7 +1259,7 @@
            modes do not count as a static code analysis tool (these typically avoid deep analysis because
            speed is vital). Examples of such static code analysis tools include cppcheck, the clang static analyzer,
            FindBugs (including FindSecurityBugs), PMD, Brakeman, Coverity Quality Analyzer,
-           and the HP Fortify Static Code Analyzer.  <strong>[static-analysis]</strong></span>
+           and the HP Fortify Static Code Analyzer.  <sup>[static-analysis]</sup></span>
      <%= f.text_field :static_analysis_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
      </div>
      </div>
@@ -1283,7 +1283,7 @@
      <div class='col-md-9 criteria-desc'>
      <span>It is SUGGESTED that the tool include rules or approaches to look for
            common vulnerabilities in the analyzed language or environment.
-           <strong>[static-analysis-common-vulnerabilities]</strong></span>
+           <sup>[static-analysis-common-vulnerabilities]</sup></span>
      <%= f.text_field :static_analysis_common_vulnerabilities_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
      </div>
      </div>
@@ -1304,7 +1304,7 @@
      <div class='col-md-9 criteria-desc'>
      <span>All confirmed medium and high severity exploitable vulnerabilities discovered with static code analysis MUST be fixed.
            A vulnerability is medium to high severity if its CVSS 2.0 is 4 or higher.
-           <strong>[static-analysis-fixed]</strong></span>
+           <sup>[static-analysis-fixed]</sup></span>
      <%= f.text_field :static_analysis_fixed_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
      </div>
      </div>
@@ -1324,7 +1324,7 @@
      </div>
      <div class='col-md-9 criteria-desc'>
      <span>It is SUGGESTED that static source code analysis occur on every commit or at least daily.
-           <strong>[static-analysis-often]</strong></span>
+           <sup>[static-analysis-often]</sup></span>
      <%= f.text_field :static_analysis_often_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
      </div>
      </div>
@@ -1351,7 +1351,7 @@
             (e.g., American Fuzzy Lop) or a web application scanner (e.g., OWASP ZAP or w3af).
             For purposes of this criterion the dynamic analysis tool MUST vary the inputs in some way to
             look for various kinds of problems or be an automated test suite with at
-            least 80% branch coverage. <strong>[dynamic-analysis]</strong></span>
+            least 80% branch coverage. <sup>[dynamic-analysis]</sup></span>
       <%= f.text_field :dynamic_analysis_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -1375,7 +1375,7 @@
             detect memory safety problems MUST be used during at least one dynamic tool use,
             e.g., Address Sanitizer (ASAN) or valgrind. If the software is not application-level,
             or is not in a memory-unsafe language, then this criterion is
-            automatically met. <strong>[dynamic-analysis-unsafe]</strong></span>
+            automatically met. <sup>[dynamic-analysis-unsafe]</sup></span>
       <%= f.text_field :dynamic_analysis_unsafe_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -1396,7 +1396,7 @@
       <div class='col-md-9 criteria-desc'>
       <span>It is SUGGESTED that the software include many run-time assertions
             that are checked during dynamic analysis.
-            <strong>[dynamic-analysis-enable-assertiions]</strong></span>
+            <sup>[dynamic-analysis-enable-assertiions]</sup></span>
       <%= f.text_field :dynamic_analysis_enable_assertions_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>
@@ -1418,7 +1418,7 @@
       <span>The analysis tool(s) MAY be focused on looking for security vulnerabilities, but this is not required.<br>
             All confirmed medium and high severity exploitable vulnerabilities discovered
             with dynamic code analysis MUST be fixed. A vulnerability is medium to high
-            severity if its CVSS 2.0 base score is 4 or higher. <strong>[dynamic-analysis-fixed]</strong></span>
+            severity if its CVSS 2.0 base score is 4 or higher. <sup>[dynamic-analysis-fixed]</sup></span>
       <%= f.text_field :dynamic_analysis_fixed_justification, class:"form-control", hide_label: true, placeholder:'Please Explain' %>
       </div>
       </div>