issues #31 #32 #33 #34 #35 #36

content/06.quality_criteria.md

@@ -9,7 +9,7 @@ The criteria in this document complements the criteria described in the "Softwar
 baseline" [@https://digital.csic.es/handle/10261/160086], while following the same pragmatic DevOps
 approach of automation.
 
-## 6.1. Automated Deployment [SvcQC.Aud] {#aud}
+## 6.1. Automated Deployment [SvcQC.Dep] {#dep}
 
 The automated deployment of **Services** implies the use of code to install and configure them in
 the target infrastructures. Infrastructure as Code (IaC) templates allow operations teams to treat
@@ -19,16 +19,16 @@ Consequently, IaC enables the paradigm of immutable infrastructure deployment an
 **Services** are never updated, but deprovisioned and redeployed. An immutable infrastructure
 simplifies maintenance and enhances repeatability and reliability.
 
-* **[SvcQC.Aud01]** A production-ready **Service** **SHOULD** be deployed as a workable system with
+* **[SvcQC.Dep01]** A production-ready **Service** **SHOULD** be deployed as a workable system with
   the minimal user or system administrator interaction leveraging IaC templates.
 
-* **[SvcQC.Aud02]** Any future change to a deployed **Service** **SHOULD** be done in the form of a
+* **[SvcQC.Dep02]** Any future change to a deployed **Service** **SHOULD** be done in the form of a
   new deployment, in order to preserve immutable infrastructures.
 
-* **[SvcQC.Aud03]** IaC **SHOULD** be validated by specific (unit) testing frameworks for every
+* **[SvcQC.Dep03]** IaC **SHOULD** be validated by specific (unit) testing frameworks for every
   change being done.
 
-  * **[SvcQC.Aud03.1]** IaC (unit) tests **MUST** be idempotent.
+  * **[SvcQC.Dep03.1]** IaC (unit) tests **MUST** be idempotent.
 
 ## 6.2. API Testing [SvcQC.Api] {#api01}
 
@@ -70,9 +70,9 @@ of a system that cooperate to achieve a given functionality.
 * **[SvcQC.Int01]** Whenever a new functionality is involved, integration testing **MUST** guarantee
   the operation of any previously-working interaction with external **Services**.
 
-  * When using APIs, contract testing **MUST** detect any disruption in the communication between
-    provider and consumer endpoints, through the validation of the API specification
-    [SvcQC.Api01](#api01).
+  * **[SvcQC.Int01.1]** When using APIs, contract testing **MUST** detect any disruption in the
+    communication between provider and consumer endpoints, through the validation of the API
+    specification [SvcQC.Api01](#api01).
 
 * **[SvcQC.Int02]** Integration testing **MUST NOT** rely on non-operational or out-of-the-warranty
   services.
@@ -98,7 +98,7 @@ exposes, leaving apart any internal design analysis or side-effects to external
     specification. [SvcQC.Api01](#api01).
 
   * **[SvcQC.Fun01.2]** Functional tests **SHOULD** include the Web Interface or Graphical User
-    Interface (GUI)) of the **Service**.
+    Interface (GUI) of the **Service**.
 
 * **[SvcQC.Fun02]** Functional tests **SHOULD** be checked automatically.
 
@@ -143,9 +143,9 @@ Elasticity is based on how quickly **Services** in an infrastructure are able to
 Security assessment is essential for any production **Service**. While an effective implementation
 of the security requirements applies to every stage in the software development life cycle (SDLC)
 --especially effective at the source code level, as discussed in
-[@https://digital.csic.es/handle/10261/160086], section [SQA-QC.Sec]--, the security testing of a
-**Service** is also --similarly to the diverse testing strategies previously covered-- a black-box
-type of testing. Hence, this section focuses on the runtime analysis of security-related
+[@https://digital.csic.es/handle/10261/160086], section *Security **[SQA-QC.Sec]***--, the security
+testing of a **Service** is also --similarly to the diverse testing strategies previously covered--
+a black-box type of testing. Hence, this section focuses on the runtime analysis of security-related
 requirements, as part of the _Dynamic Application Security Testing_  (_DAST_) as well as the
 _Interactive Application Security Testing_ (_IAST_).
 
@@ -207,7 +207,7 @@ deployments.
     Assurance Requirements for Linux Application Container Deployments [@doi:10.6028/NIST.IR.8176]
     **MUST** be considered for this task.
 
-* **[SvcQC.Sec07]** IaC testing, from [SvcQC.Aud02](#aud) criterion, **MUST** cover the security
+* **[SvcQC.Sec07]** IaC testing, from [SvcQC.Aud02](#dep) criterion, **MUST** cover the security
   auditing of the IaC templates (_SaC_) in order to assure the deployment of secured **Services**.
   For all the third-party dependencies used in the IaC templates (including all kind of software
   artifacts, such as Linux packages or container-based images):

content/07.ops_quality_criteria.md

@@ -59,13 +59,13 @@ from the infrastructure(s), where the **Service** is foreseen to be integrated.
   * **[SvcQC.Mon01.2]** The **Service** public APIs **MUST** be monitored. Use functional tests of
     criteria [SvcQC.Fun01.1](#fun).
 
-  * **[SvcQC.Mon01.3]** The **Service** Web interface MAY be monitored. Use functional tests of
+  * **[SvcQC.Mon01.3]** The **Service** Web interface **MAY** be monitored. Use functional tests of
     criteria [SvcQC.Fun01.2](#fun).
 
 * **[SvcQC.Mon02]** The **Service** **MUST** be monitored for security-related criteria:
 
   * **[SvcQC.Mon02.1]** The **Service** **MUST** be monitored for public endpoints and APIs secured
-    and strong ciphers for encryption. Use Security tests of criteria [SvcQC.Sec01].
+    and strong ciphers for encryption. Use Security tests of criteria [SvcQC.Sec01](#security).
 
   * **[SvcQC.Mon02.2]** The **Service** **SHOULD** be monitored with DAST checks. Use Security tests
     of criteria [SvcQC.Sec06.1](#security).