Dismissing a quality finding is a decision too.

The finding disappears. The risk may remain.

On 13 October 2026, GitHub introduced audit logging for manually dismissing and reopening Code Quality findings. The records include who performed the action, when it happened and which findings were affected. The improvement is available on GitHub Team and Enterprise Cloud, but not Enterprise Server. [1]

That makes actions easier to trace. The substantive question remains: why was the decision justified? A dashboard with fewer open findings does not establish that the software has improved. Quality Engineering connects the signal to an investigation and a decision.

Give different decisions distinct meanings

An automated check prompts investigation. Sometimes it points to a defect, sometimes context is missing, and sometimes the rule does not fit the chosen solution. GitHub describes dismissing findings that are not relevant or actionable, for example. [2]

SonarQube makes an explicit distinction: Accepted means fixing the issue is deferred, while False positive indicates that the reviewer considers the analysis mistaken. [3] Exact statuses differ between tools. Agree within the team what each status means in practice.

Use “false positive” only when you can explain why the analysis is wrong. A real problem with a low priority remains a real problem. Consciously accepting a risk requires a judgement about consequences and authority. These three situations deserve different explanations, even if the interface ultimately offers the same dismissal button.

Investigate what can actually happen

Consider a fictional example. A check flags an error being caught without further handling when saving a customer request. A developer suspects that another layer already informs the user. That assumption is a question to investigate, not a reason to dismiss the finding immediately.

Follow the execution path and simulate the storage failure. Is the request preserved? Does the user receive a message? Can the operation be recovered? If nobody makes the failure visible, work may be lost. If the other layer demonstrably provides the agreed handling, record that evidence against the finding.

This example does not describe an SBIT client project. It shows how to connect a technical finding to a concrete user expectation. Assess the potential impact and the conditions under which the problem occurs. Treat the scanner’s severity classification as input, alongside knowledge of the product and business process.

Record a small but useful decision

A sound explanation does not need to become a report. The checklist below is a proposed team agreement, not a built-in GitHub requirement. Keep it with the finding or in a linked ticket so a colleague can reconstruct the decision later.

1. Observation: which rule, code version and situation were investigated? Link to the finding and relevant execution path.
2. Evidence: which check, test or analysis supports the conclusion? Also record what remains uncertain.
3. Decision: fix, investigate further, defer or dismiss with justification. Describe the remaining risk in understandable language.
4. Ownership: who follows up the work, and who can accept the risk? Follow existing authority and escalation arrangements.
5. Reassessment: which change or date triggers another review? Connect deferred fixes to visible follow-up work.

Do not let exceptions become permanent by habit

A decision applies within a context. An internal function may later become externally available. Small data volumes may grow. An assumption about error handling may no longer hold after a refactor. Use such changes as triggers to revisit relevant exceptions.

Alongside remediation work, schedule a brief periodic review of deferred findings. Check that the owner remains involved, the reasoning still holds and the agreed deadline has not silently passed. Reopening a finding is not a personal failure; new information can justify a different decision.

For clear technical exceptions, a developer may decide within team agreements. Risks with broader business consequences require the appropriate accountable person. Quality Engineering helps clarify the risk and evidence. That does not automatically give it the authority to accept business risk.

Use the record to learn together

Review the number of dismissed findings together with their reasons. Repeated false positives can prompt an investigation of a rule or configuration. Many deferred genuine problems may raise questions about capacity, design or priorities. Look for the pattern before drawing conclusions about individuals.

Start small: choose a few recently closed findings this week and discuss with development, Quality Engineering and the Product Owner whether the decisions are understandable. Can a colleague see what was investigated, what risk remains and when follow-up is needed? Fill in missing information and make one working agreement for future findings.

This turns automation into useful feedback. For SBIT, quality belongs in how teams prepare decisions and follow through on them. Dismissing a finding can be justified. Make the reason as clear as the status.