GitHub code scanning now has a Mitigated dismissal reason for alerts where the vulnerable code remains but an external control reduces the risk. A web application firewall, network policy, gateway rule, or equivalent control may make exploitation harder or unreachable. That does not mean the code is fixed, and it should not become a polite label for “we do not want to work on this.”

The useful distinction is between remediation and containment. A mitigated alert records a security decision about the current environment. It should include evidence, an owner, a scope, and a review date so the decision can be reversed when the external control changes.

Decide whether the control actually reaches the vulnerable path

Start with the alert’s source, sink, route, asset, and deployment boundary. Then identify the external control that supposedly prevents exploitation. A WAF rule protecting /api/search does not mitigate the same vulnerability if the code is also reachable through an internal worker, a versioned route, a GraphQL endpoint, or a direct service-to-service network path.

Write the claim in one sentence:

The vulnerable path is reachable only through gateway G, which blocks pattern P
for requests from boundary B, and the rule is monitored by owner O.

If you cannot fill in the gateway, pattern, boundary, monitoring, and owner, the alert is not ready for a Mitigated decision.

Distinguish a real mitigation from a missing fix

A mitigation should reduce the attacker’s ability to reach or exploit the vulnerable behavior. Examples may include a network policy that removes public reachability, a gateway that rejects the dangerous input before it reaches the service, or an authentication boundary that is independently enforced.

Weak examples include an undocumented assumption that users will not send the input, a client-side validation rule, a route hidden only in the UI, or a WAF rule that has never been tested against the actual payload. These controls may lower casual exposure but do not provide strong evidence of mitigation.

Ask four questions:

Question Evidence to keep
Does the control cover every entry point? Route and service inventory
Does it block the relevant attack shape? Test request and rule result
Can an attacker bypass it through another path? Network and authentication review
Will someone know if it stops working? Alert, log, or monitor owner

Use a temporary exception, not permanent comfort

The best outcome is still to remove the vulnerable code or upgrade the dependency. Use Mitigated when the external control is part of the current risk decision, not as proof that remediation is complete.

Record a target date for code remediation or a trigger for reassessment. Triggers can include a route becoming public, a gateway rule changing, a new region being deployed, a service moving behind a different load balancer, or a new client bypassing the control.

Do not set an arbitrary expiry that no team owns. Assign the review to the service owner and security reviewer, and make the exception visible in the same system that records the alert.

Test both blocked and allowed traffic

Test the control from the paths an attacker might use. Include the public gateway, internal service network, staging environment, alternate API versions, health or debug routes, background consumers, and direct cloud load-balancer addresses where applicable.

Keep tests safe and synthetic. A useful test records request shape, gateway decision, application receipt, response class, and relevant log event. Never put real credentials, customer data, or destructive payloads into a security test merely to create evidence.

For a WAF mitigation, confirm that the request is blocked before the vulnerable application code executes. A 403 response alone is weak evidence if the service logs show the request reached the dangerous handler first.

Review changes that can invalidate mitigation

External controls drift. Infrastructure teams may replace a gateway, change a rule priority, add a region, expose a new hostname, or relax a network policy. Application teams may add a new route that calls the same vulnerable function.

Connect the exception to change review. When the service, gateway, authentication layer, or network boundary changes, require the mitigation owner to recheck the alert. This is more reliable than relying on memory six months later.

Keep a compact record:

alert: github-alert-id
status: mitigated
control: edge-waf-rule-482
coverage: public-api-v2
owner: payments-platform
review_after: 2026-09-30
code_fix_issue: SEC-1842

The identifiers should point to real systems in your organization. Avoid copying sensitive rule contents into a public issue or alert comment.

Do not confuse risk acceptance with mitigation

If the vulnerability remains reachable and the organization chooses to tolerate the risk, that is a risk-acceptance decision, not necessarily a mitigation. The reason should communicate the difference clearly so a future reviewer does not infer that the code is protected when it is merely accepted.

Likewise, a false positive should be handled with the appropriate false-positive reason and evidence. Using Mitigated because the scanner is wrong corrupts reporting and makes real external controls harder to find.

Measure whether the control is working

Monitor rule matches, blocked requests, bypass attempts, allowed traffic, application errors, and configuration changes. A control with no telemetry may still work, but it gives reviewers little confidence after an incident or deployment change.

When the code fix lands, close the underlying alert through the normal remediation path and remove obsolete external exceptions. The goal of Mitigated is accurate risk communication while the vulnerable code exists, not a permanent second status for fixed code.

Primary references

Use Mitigated when a named external control genuinely reduces exposure and the evidence can be reviewed. Keep the code-fix issue open, monitor the control, and reassess it whenever the deployment boundary changes.