From 9fe8026a3344fb93c1a4876aa5ce688b1623bb6e Mon Sep 17 00:00:00 2001 From: Flavio Ceolin Date: Tue, 14 Nov 2023 23:04:51 -0800 Subject: [PATCH] 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 --- doc/contribute/guidelines.rst | 15 ++++++++++++--- doc/project/project_roles.rst | 22 ++++++++++++++++++++++ doc/project/release_process.rst | 14 ++++++++++---- 3 files changed, 44 insertions(+), 7 deletions(-) diff --git a/doc/contribute/guidelines.rst b/doc/contribute/guidelines.rst index b3dd735dd423c8..996ba5d7bb2372 100644 --- a/doc/contribute/guidelines.rst +++ b/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. 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 verify that identified issues are properly +triaged and resolved in a timely manner. Workflow ======== diff --git a/doc/project/project_roles.rst b/doc/project/project_roles.rst index 2d1a74b573fbf4..6232aed9ea54c6 100644 --- a/doc/project/project_roles.rst +++ b/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 changes 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 diff --git a/doc/project/release_process.rst b/doc/project/release_process.rst index e1e07c417c8384..68d74838bb029b 100644 --- a/doc/project/release_process.rst +++ b/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,11 @@ 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 +274,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