doc: security: Avoid confusion with code guideline

Security documentation contains a code guideline section that is more
about security principles than code guidelines itself. Just removing
the mention do code guideline to avoid possible confusions with
upcoming project code guideline based on MISRA-C.

Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>

doc/security/secure-coding.rst

@@ -1,7 +1,7 @@
 .. _secure code:
 
-Secure Coding Guidelines
-########################
+Secure Coding
+#############
 
 Traditionally, microcontroller-based systems have not placed much
 emphasis on security.
@@ -15,7 +15,7 @@ uncontrolled access can be devastating [#attackf]_.
 
 This document describes the requirements and process for ensuring
 security is addressed within the Zephyr project.  All code submitted
-should comply with these guidelines.
+should comply with these principles.
 
 Much of this document comes from [CIIBPB]_.
 
@@ -49,8 +49,8 @@ project.
 Finally, the document covers how changes are to be made to this
 document.
 
-Secure Coding Guidelines
-************************
+Secure Coding
+*************
 
 Designing an open software system such as Zephyr to be secure requires
 adhering to a defined set of design standards. In [SALT75]_, the following,

doc/security/security-overview.rst

@@ -25,7 +25,7 @@ in detail. As depicted in Figure 1, these main steps are:
 
 1. **Secure Development:** Defines the system architecture and
    development process that ensures adherence to relevant coding
-   guidelines and quality assurance procedures.
+   principles and quality assurance procedures.
 
 2. **Secure Design:** Defines security procedures and implement measures
    to enforce them. A security architecture of the system and
@@ -174,7 +174,7 @@ maintainer. The main goals of the code review are:
 
 -  Reviewing the security relevant code for potential issues
 
-The current coding guidelines focus mostly on coding styles and
+The current coding principles focus mostly on coding styles and
 conventions. Functional correctness is ensured by the build system and
 the experience of the reviewer. Especially for security relevant code,
 concrete and detailed guidelines need to be developed and aligned with
@@ -272,8 +272,8 @@ basis for the security architecture. Please refer to the
 :ref:`Zephyr subsystem documentation <api_reference>` for
 detailed information.
 
-Secure Coding Guidelines
-========================
+Secure Coding
+=============
 
 Designing an open software system such as Zephyr to be secure requires
 adhering to a defined set of design standards. These standards are
@@ -282,7 +282,7 @@ included in the Zephyr Project documentation, specifically in its
 accepted principles for protection mechanisms are defined to prevent
 security violations and limit their impact:
 
--  **Open design** as a design guideline incorporates the maxim that
+-  **Open design** as a design principle incorporates the maxim that
    protection mechanisms cannot be kept secret on any system in
    widespread use. Instead of relying on secret, custom-tailored
    security measures, publicly accepted cryptographic algorithms and
@@ -364,10 +364,10 @@ Quality Assurance
 
 The quality assurance part encompasses the following criteria:
 
--  **Adherence to the Coding Guidelines** with respect to coding style,
+-  **Adherence to the Coding Conventions** with respect to coding style,
    naming schemes of modules, functions, variables, and so forth.
    This increases the readability of the Zephyr code base and eases
-   the code review. These coding guidelines are enforced by
+   the code review. These coding conventions are enforced by
    automated scripts prior to check-in.
 
 -  **Adherence to Deployment Guidelines** is required to ensure
@@ -462,7 +462,7 @@ for detailed information.
 
 The software security process includes:
 
--  **Adherence to the Secure Development Guidelines** is mandatory to
+-  **Adherence to the Secure Development Coding** is mandatory to
    avoid that individual components breach the system security and
    to minimize the vulnerability of individual modules. While this
    can be partially achieved by automated tests, it is inevitable to