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: #64591

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

doc/contribute/guidelines.rst

@@ -532,9 +532,18 @@ 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 of the Zephyr codebase is conducted on a bi-weekly basis. GitHub
+issues are automatically created for any issues detected by static analysis
+tools. 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 maintainer who is responsible for the affected code.
+
+A dedicated team comprising members with expertise in static analysis, code
+quality, and software security ensures the effectiveness of the static
+analysis process and verifies that identified issues are properly
+triaged and resolved in a timely manner.
 
 Workflow
 ========

doc/project/project_roles.rst

@@ -123,6 +123,8 @@ 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.
+* Responsibility to triage static analysis issues in their code area.
+  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
@@ -168,6 +170,26 @@ the latter is not possible.
 * Solicit approvals from maintainers of the subsystems affected
 * Responsibility to drive the :ref:`pr_technical_escalation` process
 
+Static Analysis Audit Team
+++++++++++++++++++++++++++
+
+The Static Analysis Audit team works closely with the release engineering
+team to ensure that static analysis defects opened during a release
+cycle are properly addressed. The team has the following rights and
+responsibilities:
+
+* Right to revert any change in a static analysis tool (e.g: Coverity)
+  that does not follow the project expectations.
+* Responsibility to inform code owners about improper classifications.
+* Responsibility to alert TSC if any issues are not adequately addressed by the
+  responsible code owners.
+
+Joining the Static Analysis Audit team
+
+* Contributors highly involved in the project with some expertise
+  in static analysis.
+
+
 .. _release-engineering-team:
 
 Release Engineering Team

doc/project/release_process.rst

@@ -94,8 +94,8 @@ At that point, the whole process starts over again.
 Release Quality Criteria
 ************************
 
-The current backlog of prioritized bugs shall be used as a quality metric to
-gate the final release. The following counts shall be used:
+The current backlog of prioritized bugs shall also be used as a quality metric
+to gate the final release. The following counts shall be used:
 
 .. csv-table:: Bug Count Release Thresholds
    :header: "High", "Medium", "Low"
@@ -109,6 +109,10 @@ gate the final release. The following counts shall be used:
    The "low" bug count target of <50 will be a phased approach starting with 150
    for release 2.4.0, 100 for release 2.5.0, and 50 for release 2.6.0
 
+The final release must not contain any static analysis 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.
 
 
 Release Milestones
@@ -269,8 +273,11 @@ 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 reports
+
+  - 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