michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: Static Analysis requirement

Browse source 
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>
This commit is contained in:
Flavio Ceolin 2023-11-14 23:04:51 -08:00 • committed by Carles Cufí
commit dd58f80fe2
3 changed files with 45 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

22
doc/project/project_roles.rst
View file

@ -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

15
doc/project/release_process.rst
View file

@ -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