Skip to content

update problem resoultion to close audit findings #832

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
masc2023 merged 2 commits into from
Oct 16, 2026
Merged

update problem resoultion to close audit findings #832

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
00a45df
update problem resoultion to close audit findings
masc2023 Oct 15, 2026
03b4bed
fix review findings
masc2023 Oct 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 17 additions & 5 deletions process/process_areas/problem_resolution/guidance/problem_resolution_checklist.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ Problem Checklist
.. gd_chklst:: Problem Review Checklist
:id: gd_chklst__problem_cr_review
:status: valid
:version: 1
:version: 2
:tags: problem_resolution
:complies:

Expand Down Expand Up @@ -73,28 +73,40 @@ Problem Checklist
-

* - 9
- Does the Problem report have a category as specified?
- Is the category provided, with safety or security relevance confirmed or disconfirmed by the respective manager where applicable?
-

* - 10
- Does the Problem report have a classification as specified?
-

* - 11
- Does the Problem report have the affected release versions as specified?
- Are the detection version and affected versions, including versions derived from the faulty version, documented?
-

* - 12
- Does the Problem report have an expected closure date as specified?
- Does the Problem report have an expected closure version or milestone as specified?
-

* - 13
- Does the Problem report have the solution measures specified, verified and reported?
- Where measures are implemented, are they specified with implementation and effectiveness-verification evidence?
-

* - 14
- If the Problem report is not closed and pending solution measures are open, escalated to the :need:`rl__safety_manager` or :need:`rl__security_manager`?
-

* - 15
- Is the need for notification explained, and is any notification recorded?
-

* - 16
- Where safety is affected, does a rationale support either an implemented adequate safety measure with verified effectiveness, or an evaluation that the problem does not constitute an unreasonable risk?
-

* - 17
- Where safety is affected, is the closure rationale documented and reviewed, with the review result recorded?
-

.. needextend:: "c.this_doc()"
:+tags: problem_resolution
112 changes: 82 additions & 30 deletions process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Guideline
.. gd_guidl:: Problem Resolution Guideline
:id: gd_guidl__problem_problem
:status: valid
:version: 1
:version: 2
:complies: std_req__iso26262__management_5431[version==1],
std_req__iso26262__management_5433[version==1],
std_req__iso26262__management_5434[version==1],
Expand Down Expand Up @@ -130,9 +130,10 @@ Tracking System.

The title of the Problem Report should reflect the topic accordingly.

The description should reflect the problem root cause and impact in detail.
The description should reflect the problem root cause, if known, and its impact, including
known side effects on other functionality or dependent components.

If applicable affected parties should be notified.
Assess notification needs according to :ref:`prm_notifications`.

Further supporting information should ge given, especially how to reproduce the problem,
and what is the error occurrence rate?
Expand All @@ -142,9 +143,10 @@ If safety is affected, the ASIL classification should be added, if applicable.

The problem should be classified according minor, major, critical or blocker.

The affected versions of the release should be documented. After detection of the
problem, checking the affected versions is critical to understand the impact of the
problem. Thus document the first affected version and the last affected version.
Document the version where the problem was detected and the first and last affected
versions, including versions derived from the faulty version. Where applicable, identify
affected branches and dependent integrations. Record unknown affected versions as
"under investigation" and update them during analysis.

.. note::
| For the Problem Report Example:
Expand All @@ -167,6 +169,23 @@ When ready to review and to analyze, the author sets the status to "in review" m
| * The "Process Development Community" dashboard is added and the status must be changed to **Todo**
| * The combination of the issue**Open** and **Todo** defines the status **in review**

.. _prm_notifications:

Notification of Affected Parties
--------------------------------

Notification is needed when the problem's impact requires affected parties to assess
their use of the software or take action, such as applying a workaround or an update.
Consider affected users, integrators and feature or component maintainers, and the
Safety or Security Manager where applicable.

The :need:`Project Lead <rl__project_lead>` communicates the problem status to affected
parties. Record whether notification is needed and why in the Problem Report's notification
section. If needed, notify the affected parties through an issue comment with an explicit
mention or another appropriate channel. Record who was notified, when and how, using a
comment link or communication reference.
For suspected vulnerabilities, follow the project's confidential reporting policy.

.. _prm_analyze_problem_report:

Analyze Problem Report
Expand All @@ -188,25 +207,36 @@ If applicable, the features affected should be identified too.

The description shall reflect the result of the analysis.

Topics to checked (critical topics are marked with x):

- [x] Is the problem description clear and detailed enough to understand the problem and its impact?
- [x] Is the problem root cause clearly described?
- [x] Is the problem impact clearly described?
- [ ] Is notification of affected parties required? If yes, are the affected parties notified?
- [ ] Are there any proposed solutions provided?
- [ ] Are there any further linked issues or pull requests provided?
- [x] Is the error occurrence rate provided? If yes, is it high enough to accept the problem?
- [x] Is the problem reproducible?
- [ ] Are there any further supporting information provided?
- [x] Is the problem classification correct?
- [x] Is information for the affected version of the release provided? If yes, is it correct?
- [ ] Is the information for the expected closure version provided? If yes, is it correct?
- [x] Is the problem affecting safety or security? If yes, is the classification correct?

The analysis phase can not be closed, until all critical topics are
clarified and provided in the description. If not, the problem report should be rejected
and closed with the reason "Closed as not planned".
Where safety or security may be affected, the responsible
:need:`Safety Manager <rl__safety_manager>` or :need:`Security Manager <rl__security_manager>`,
respectively, confirms or disconfirms the relevance and records the reason.

A review **topic** is a question used to check the information and decisions in a Problem
Report. A **critical review topic** must be addressed before approving the analysis.
This is independent of the problem severity classification **critical**.
The following topics shall be checked:

* **Critical:** Is the problem description clear, including its impact?
* **Critical:** Is the root cause described, or identified as under investigation?
* **Critical:** Are the occurrence rate and reproduction information provided, as far as known?
* **Critical:** Is the problem classification correct?
* **Critical:** Are the affected versions identified, including versions derived from the faulty version?
* **Critical:** Is the safety or security relevance assessed, where applicable?
* Is notification needed, and have affected parties been notified?
* Are proposed solutions, supporting information and related issues or pull requests provided?
* Are the responsible stakeholders and expected closure version identified?

.. _prm_problem_disposition:

Disposition of Review Topics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If a critical topic is not clarified, keep the report "in review" or return it to "open"
for further information according to :need:`wf__problem_analyze_pr`. Record the open
question and the analysis result. Missing information alone is not a reason for rejection.
If the problem is rejected, document the reason. Rejection or cancellation does not mean
that a problem where safety is affected is managed to closure; see
:ref:`prm_safety_affected_closure`.

.. note::
| For the Problem Report Example:
Expand Down Expand Up @@ -291,18 +321,40 @@ the problem, until they are closed.
:need:`[[title]] <rl__committer>` checks finally if the problem Resolution is sufficient before
the status is finally closed.
To check, if it is sufficient, :need:`Problem Checklist <gd_chklst__problem_cr_review>` may used.
Further the effectiveness of the implemented measure is confirmed and the availability
of the required reports, as verification results, if applicable.
Where measures are implemented, confirm their effectiveness and record the verification

@RolandJentschETAS RolandJentschETAS Oct 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here my question; Are there any side effects of the solution mentioned somewhere ? Like performance decrease by the measures and so on ?

@masc2023 masc2023 Oct 16, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in the pushed changes. The closure guidance now asks to consider and document side effects of the implemented measure, such as reduced performance, and include them in verification as applicable.

results. Consider and document side effects of the implemented measure, such as reduced
performance, and include them in the verification as applicable.
For problems where safety is affected, apply :ref:`prm_safety_affected_closure`.

When confirmed, the author sets the status to "closed" manually, if not done automatically.
Closure follows :need:`wf__problem_close_pr` and :need:`gd_req__problem_check_closing`.

.. note::
| For the Problem Report Example 2:
| * The status of the issue is provided by the Issue Tracking System as: **Closed**
| * The combination of **Closed** and any "Process Development Community" status **Done** and the Pull Request status **Merged** defines the status **closed**

:need:`[[title]] <rl__committer>` has the freedom to reject it at any time by setting the status
to "reject".
If the resolution is insufficient, keep the status "in implementation".

.. _prm_safety_affected_closure:

Closure of Problems Where Safety Is Affected
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For a Problem Report classified as **Safety affected**, closure shall be supported by
one of the following:

* An adequate safety measure has been implemented to resolve the problem, based on a
rationale, and its effectiveness has been verified.
* An evaluation concludes that the problem does not constitute an unreasonable risk,
supported by a rationale.

For either condition, document the rationale and its review result in the Problem Report.
Include effectiveness-verification results for an implemented measure, or the risk
evaluation for the second condition. A software fix or fixed version is not required
for the second condition.

Without a documented and reviewed rationale, the problem is not managed to closure.
These conditions do not change the responsibilities defined in :need:`wf__problem_close_pr`.

.. needextend:: "c.this_doc()"
:+tags: problem_resolution
62 changes: 54 additions & 8 deletions process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ Problem Attributes
.. gd_req:: Problem attribute: description
:id: gd_req__problem_attr_impact_description
:status: valid
:version: 1
:version: 2
:tags: manual_prio_1, problem_resolution, attribute, mandatory
:satisfies: wf__problem_create_pr[version==1],
wf__problem_analyze_pr[version==1],
Expand All @@ -80,10 +80,26 @@ Problem Attributes

Exact description of the Problem, including potential cause and impact of the problem.

Record especially, if functional safety or cybersecurity may affected here.
Record especially whether functional safety or cybersecurity may be affected.

Record affected parties, whether notification is needed and why, and who was notified
and when. See :ref:`prm_notifications`.

.. gd_req:: Problem attribute: affected versions
:id: gd_req__problem_attr_affected_versions
:status: valid
:version: 1
:tags: manual_prio_1, problem_resolution, attribute, mandatory
:satisfies: wf__problem_create_pr[version==1],
wf__problem_analyze_pr[version==1],
wf__problem_initiate_monitor_pr[version==1],
wf__problem_close_pr[version==1]
:complies: std_req__aspice_40__SUP-9-BP2[version==1]

Record potential affected parties, and if it may required to notify them about the potential
problem.
Each Problem shall record the detection version and the first and last affected versions,
including versions derived from the faulty version. Identify affected branches and
dependent integrations where applicable. Record unknowns as under investigation and
update them during analysis.

.. gd_req:: Problem attribute: analysis results
:id: gd_req__problem_attr_analysis_results
Expand Down Expand Up @@ -133,7 +149,7 @@ Problem Attributes
.. gd_req:: Problem attribute:: safety affected
:id: gd_req__problem_attr_safety_affected
:status: valid
:version: 1
:version: 2
:tags: prio_1_automation, problem_resolution, attribute, mandatory
:satisfies: wf__problem_create_pr[version==1],
wf__problem_analyze_pr[version==1],
Expand All @@ -146,12 +162,15 @@ Problem Attributes
* Yes
* No

Note: If neither security or safety relevance is set the bug is always quality relevant.
Where safety may be affected, the responsible :need:`Safety Manager <rl__safety_manager>`
shall confirm or disconfirm safety relevance and record the reason.

Note: If neither safety nor security is affected, the problem is quality relevant.

.. gd_req:: Problem attribute:: security affected
:id: gd_req__problem_attr_security_affected
:status: valid
:version: 1
:version: 2
:tags: prio_1_automation, problem_resolution, attribute, mandatory
:satisfies: wf__problem_create_pr[version==1],
wf__problem_analyze_pr[version==1],
Expand All @@ -164,7 +183,10 @@ Problem Attributes
* Yes
* No

Note: If neither security or safety relevance is set the bug is always quality relevant.
Where security may be affected, the responsible :need:`Security Manager <rl__security_manager>`
shall confirm or disconfirm security relevance and record the reason.

Note: If neither safety nor security is affected, the problem is quality relevant.

.. gd_req:: Problem attribute: milestone
:id: gd_req__problem_attr_milestone
Expand Down Expand Up @@ -219,5 +241,29 @@ Problem Resolution Checks
ISSUEs related to Problem Reports shall not automatically closed, if linked ISSUEs or PRs are closed or merged and
these ISSUEs shall be closed only manually from the :need:`Committer <rl__committer>`.

.. gd_req:: Closure conditions for problems where safety is affected
:id: gd_req__problem_check_safety_closure
:status: valid
:version: 1
:tags: manual_prio_1, problem_resolution, check
:satisfies: wf__problem_close_pr[version==1]
:complies: std_req__iso26262__management_5433[version==1]

A problem classified as Safety affected shall be considered managed to closure only
when a rationale supports either an implemented adequate safety measure whose
effectiveness has been verified, or an evaluation that the problem does not constitute
an unreasonable risk.

.. gd_req:: Documentation and review of closure rationale where safety is affected
:id: gd_req__problem_check_safety_rationale
:status: valid
:version: 1
:tags: manual_prio_1, problem_resolution, check
:satisfies: wf__problem_close_pr[version==1]
:complies: std_req__iso26262__management_5434[version==1]

For either safety-specific closure condition, the rationale shall be documented and
reviewed. Record the review result. See :ref:`prm_safety_affected_closure`.

.. needextend:: "c.this_doc()"
:+tags: problem_resolution
Loading
Loading