GitHub shipped a Mitigated dismissal reason on 20 August 2026 that its own REST API cannot set

Summary. GitHub published three application-security changelog entries on 20 August 2026: a new Mitigated dismissal reason for code scanning alerts, three new audit-log events for GitHub Code Quality, and a dedicated GitHub Actions path that separates Code Quality runs from code scanning runs. Two of the three land with a documentation gap you will hit within a day of trying to adopt them. The Mitigated reason does not appear on the documentation page the changelog links to, and the REST API reference for API version 2026-03-10 still lists dismissed_reason as one of false positive, won't fix, used in tests, null. Separately, GitHub tells admins to rewrite Actions billing filters against the string dynamic/github-code-quality/codeql, which appears in the changelog and nowhere in GitHub Docs. Meanwhile the reference page for Code Quality still states the product "is currently in public preview" and "will not be billed", one month after billing began on 20 July 2026 at $10 per active committer per month.

What shipped on 20 August 2026

Three entries, all dated 20 August 2026, all tagged application security.

The first is labelled a Release: "You can now dismiss a code scanning alert with the reason Mitigated when a vulnerability remains in the code but external controls, such as a web application firewall or network policy, mitigate its risk." GitHub frames the value as process alignment: the reason "helps you distinguish mitigated vulnerabilities from alerts marked Won't fix, align dismissals with formal exception and risk-acceptance processes, and reduce the need to track these decisions outside GitHub."

The second adds audit-log coverage to GitHub Code Quality: "GitHub Code Quality now writes an audit log event whenever someone enables, disables, or changes its settings on a repository." The three events are repo.code_quality_enabled, repo.code_quality_disabled and repo.code_quality_updated. The billing rationale is stated outright: "Because Code Quality billing counts active committers on enabled repositories, you can now see exactly when a repository entered or left that scope."

The third splits the Actions path: "Code Quality analysis runs on dynamic/github-code-quality/codeql and shows github-code-quality as the actor, instead of sharing the dynamic/github-code-scanning/codeql path and the github-advanced-security actor with code scanning."

Taken together these are unglamorous governance plumbing, and that is the point. All three exist to make an expensive product auditable. What makes them worth an hour of your time is that two of them are not yet documented well enough to act on.

The Mitigated reason has no documented API

This is the gap that will stop an appsec team cold.

The changelog's only "for more information" link points at GitHub's page on resolving code scanning alerts. That page does not contain the word "mitigated". It does not enumerate the dismissal reasons at all. Its entire guidance on the subject is: "Review the alert, then click Dismiss alert and choose, or type, a reason for closing the alert. ... It's important to choose the appropriate reason from the drop-down menu as this may affect whether a query continues to be included in future analysis."

The only enumerated list of dismissal reasons anywhere in GitHub Docs is in the REST reference for updating a code scanning alert, at API version 2026-03-10, and it has not changed: "dismissed_reason string or null — Required when the state is dismissed. The reason for dismissing or closing the alert. Can be one of: false positive, won't fix, used in tests, null". The string "mitigat" does not appear on that page.

For a two-person team clicking Dismiss in the UI, none of this matters. For anyone dismissing at scale, it is the whole story. If you close alerts through PATCH /repos/{owner}/{repo}/code-scanning/alerts/{alert_number} from a ticketing integration, a risk-register sync or a compliance script, there is no documented value to send. You can guess at mitigated, but a guess against an undocumented enum is not something to put in a control that an auditor will read.

Dismissing as Mitigated behaves exactly like Won't fix

The second thing to know is that the new reason changes the label, not the mechanics. GitHub's dismissal behaviour is documented once and is reason-agnostic: "When you dismiss an alert: It's dismissed in all branches. The alert is removed from the number of current alerts for your project. The alert is moved to the 'Closed' list in the summary of alerts, from where you can reopen it, if required. The reason why you closed the alert is recorded. ... Next time code scanning runs, the same code won't generate an alert."

So an alert dismissed as Mitigated leaves your current-alert count and stops re-firing, in every branch, exactly as Won't fix does. No GitHub page states any differential treatment for mitigated in security overview counts, required status checks or branch protection. That is not a criticism of the feature. It is a caution against the natural assumption that a reason invented for risk acceptance carries a review cadence with it. It does not. If your policy is that a WAF-mitigated finding gets re-reviewed when the WAF rule changes, that re-review lives in your risk register, not in GitHub.

One mechanism does carry forward and is worth using: "The dismissal comment is added to the alert timeline and can be used as justification during auditing and reporting. You can retrieve or set a comment by using the code scanning REST API. The comment is contained in dismissed_comment". Since the reason itself is not yet settable through the API, dismissed_comment is where the compensating-control reference belongs, whichever way you close the alert. Teams standardising this alongside their scanner tooling will recognise the pattern from Codex security CLI in CI compared with Semgrep and CodeQL.

The Actions path change is a billing-report break

The third entry is the one with a deadline-shaped cost, even though no deadline is stated.

Code Quality runs used to share both the workflow path and the actor with code scanning. They no longer do. GitHub is direct about the consequence: "Change Actions usage and billing reports that filter on dynamic/github-code-scanning/codeql so they also account for dynamic/github-code-quality/codeql" and "Update scripts, dashboards, or workflow run filters that identify Code Quality runs by the github-advanced-security actor."

If you have a FinOps dashboard that attributes Actions minutes by workflow path, it silently under-counts from 20 August 2026 onward. Nothing errors. The minutes are still billed; they are just filed under a path your query does not select. The first sign will be an Actions bill that no longer reconciles with the sum of your per-workflow attributions.

The awkward part is that dynamic/github-code-quality/codeql and the github-code-quality actor exist only in the changelog. The reference page for Code Quality's CodeQL detection describes the same subject and says only: "You can see all the workflow runs for Code Quality on the Actions tab for your repository. The dynamic workflow is called 'Code Quality'." Admins are being asked to hard-code a string into billing logic on the authority of a one-minute changelog post. That is workable, but write the source URL into a code comment, because there is nothing in the docs to point a successor at.

A generally available product whose reference page says it is free

The sharpest contradiction in this cluster is not in the 20 August entries at all. It is what those entries sit on top of.

GitHub Code Quality reached general availability on 20 July 2026. The GA changelog states the price: "$10 per active committer, per month. A committer is considered active when they've pushed a commit to a repository with Code Quality enabled in the last 90 days. Each active committer is counted only once across your organization no matter how many repositories they contribute to. Bot accounts are not charged." It also states "Billing begins automatically at general availability (July 20, 2026)."

Yet the live reference page for Code Quality's CodeQL detection, read on 21 August 2026, still carries this: "GitHub Code Quality is currently in public preview and subject to change. During public preview, Code Quality will not be billed, although Code Quality scans will consume GitHub Actions minutes."

An engineering manager who enables Code Quality after reading GitHub's own reference documentation would conclude the product is free. It has been billed for a month.

The billing documentation is where the price should live, and it carries no dollar amount for the committer licence at all. It describes the structure clearly: "Use of Code Quality incurs three types of costs for an organization: GitHub Actions minutes / GitHub AI Credits / Active and unique committers", that "Code Quality scans run as GitHub Actions workflows and consume GitHub Actions minutes, unless you use self-hosted runners", and that AI features "consume AI credits from your shared AI credits pool, rather than a separate Code Quality allowance. Each interaction is priced based on the number of tokens consumed, where 1 AI credit = $0.01 USD." It also notes that "Model switching is not supported, as changing the model is likely to compromise the reliability and accuracy of analysis results."

What it does not do is tell you what a seat costs. The only primary source for $10 is a changelog from a month ago. Third-party blogs repeating the figure are downstream of that same post, not independent confirmation of it.

What to do this week

Four concrete actions, in the order they pay off.

Rewrite your Actions cost attribution to include dynamic/github-code-quality/codeql alongside dynamic/github-code-scanning/codeql, and stop keying on the github-advanced-security actor for Code Quality runs. This one is a silent under-count and it started on 20 August 2026.

Turn on the three audit-log events as a billing control, not just a security one. GitHub's own framing is the right one: because licences are counted by active committers on enabled repositories, repo.code_quality_enabled is the event that tells you when your seat count moved. Query them through the audit log API from the organisation or enterprise audit log.

Reconcile your licence count against the 90-day window. A committer counts as active if a commit of theirs "has been pushed to the repository within the last 90 days, regardless of when it was originally authored." Pushing an old branch full of a departed colleague's commits can re-activate a licence. GitHub also documents an escape: "Unique committers is the number of active committers who contributed only to one repository, or only to repositories in one organization. You can free up this number of licenses by disabling Code Quality for that repository or organization."

Hold off on wiring Mitigated into an automated risk-acceptance flow until the REST enum catches up. Use it in the UI, put the compensating control in dismissed_comment, and revisit when the API reference lists a fourth value. This is the same sequencing discipline that governs GitHub Code Quality GA billing and audit.

India-specific considerations

For Indian services firms and GCCs running GitHub Enterprise Cloud, the committer-based licence is the line item to model before enabling Code Quality broadly. At $10 per active committer per month, a 200-engineer delivery organisation is looking at roughly $2,000 a month, about ₹1.75 lakh at current rates, before Actions minutes and AI credits. The 90-day activity window makes that number lag headcount changes by a quarter, so a bench-heavy month still bills. The audit-log events shipped on 20 August 2026 are the first primary mechanism for tying that spend back to a specific repository and a specific person who enabled it, which is exactly what an internal audit under a client's security addendum will ask for.

What is still unknown

GitHub has not published a documented API value for the Mitigated reason, nor said when the REST reference will list one. There is no stated cutover date after which the old dynamic/github-code-scanning/codeql path stops carrying Code Quality runs, because the change appears to be immediate rather than phased. Whether repo.code_quality_enabled and its siblings appear in the audit-log events reference could not be confirmed. And GitHub has not corrected the reference page that still describes a billed, generally available product as an unbilled public preview.

FAQ

How eCorpIT can help

Adopting a per-committer security product is a licence-modelling exercise before it is an engineering one, and the audit trail matters as much as the scan results. Our senior engineering teams set up code scanning and CI security gates for regulated buyers, including the cost attribution that a split Actions path quietly breaks. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised, and we design pipelines aligned with client audit requirements. Reach the team through /contact-us/.

References

1. Separate GitHub Actions path for GitHub Code Quality. GitHub Changelog, 20 August 2026.

1. Track GitHub Code Quality enablement changes in the audit log. GitHub Changelog, 20 August 2026.

1. Code scanning adds a mitigated alert dismissal reason. GitHub Changelog, 20 August 2026.

1. GitHub Code Quality is now generally available. GitHub Changelog, 20 July 2026, pricing and GA date.

1. About GitHub Code Quality. GitHub Docs.

1. GitHub Code Quality billing. GitHub Docs, AI credit rate and committer definition.

1. Code Quality CodeQL detection reference. GitHub Docs, the public preview statement.

1. REST API endpoints for code scanning. GitHub Docs, dismissed_reason enum at API version 2026-03-10.

1. Resolving code scanning alerts. GitHub Docs, dismissal behaviour and dismissed_comment.

1. About code scanning alerts. GitHub Docs, required status checks.

1. Audit log events for your organization. GitHub Docs.

Last updated: 21 August 2026.