doc: Static Analysis requirement

Sets static analysis  an indispensable requirement for our project
releases.

Static analysis is not merely a tool but a proactive
strategy to unearth and address potential issues in the early stages
of development, long before they mature into critical
vulnerabilities. By scrutinizing code at rest, static analysis unveils
latent defects and potential security risks, thus bolstering the
resilience of our software against future threats.

Fixes: zephyrproject-rtos#64591

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

doc/contribute/guidelines.rst

@@ -532,9 +532,17 @@ results you have to create an account yourself.  From the Zephyr project page,
 you may select "Add me to project" to be added to the project. New members must
 be approved by an admin.
 
-Coverity scans the Zephyr codebase weekly. GitHub issues are automatically
-created for any problems found and assigned to the maintainers of the affected
-areas.
+Static analysis in the Zephyr codebase happens bi-weekly. GitHub issues are
+automatically created for any issues detected by Coverity. These issues will
+have the same (or equivalent) priority initially defined by the tool.
+
+To ensure accountability and efficient issue resolution, they are assigned to
+the respective code owner who is responsible for the affected code.
+
+A dedicated team comprising members with expertise in static analysis, code
+quality, and software security is responsible to ensure the effectiveness of
+the static analysis process and verify that identified issues are properly
+triaged and resolved in a timely manner.
 
 Workflow
 ========

doc/project/project_roles.rst

@@ -123,6 +123,9 @@ in addition to those listed for Contributors and Collaborators:
 * Responsibility to ensure all contributions of the project have been reviewed
   within reasonable time.
 * Responsibility to enforce the code of conduct.
+* Responsability to triage static analysis issues in their code area. Improper
+  triage may lead hidden defects and potential security risks.
+  See :ref:`static_analysis`.
 
 Contributors or Collaborators are promoted to the Maintainer role by adding the
 GitHub user name to one or more ``maintainers`` sections of the

doc/project/release_process.rst

@@ -94,6 +94,12 @@ At that point, the whole process starts over again.
 Release Quality Criteria
 ************************
 
+Static Analysis results a fundamental requirement for the project. The final
+release must not contain any high-critical issues that can potentially
+compromise the functionality, security, or reliability of our software.
+High-critical issues represent vulnerabilities that, if left unresolved,
+could have severe consequences.
+
 The current backlog of prioritized bugs shall be used as a quality metric to
 gate the final release. The following counts shall be used:
 
@@ -269,8 +275,9 @@ components provided by the project:
 
 - Compliance with published coding guidelines, style guides and naming
   conventions and documentation of deviations.
-- Regular static analysis on the complete tree using available commercial and
-  open-source tools and documentation of deviations and false positives.
+- Static analysis report
+  - Regular static analysis on the complete tree using available commercial and
+    open-source tools and documentation of deviations and false positives.
 - Documented components and APIS
 - Requirements Catalog
 - Verification Plans