Mitigated, Remediated, and Fixed Are Different Security States

Three security releases from the last three days use the word “action” in materially different ways.

On 21 August, Cloudflare added CASB remediation policies. A matching Microsoft 365 or Google Workspace file-sharing finding can now trigger a first-party API action, such as revoking public access, and send a webhook without waiting for manual triage.

One day earlier, GitHub added Mitigated as a code-scanning dismissal reason. The vulnerable condition remains in code, but an external control such as a web application firewall or network policy reduces its risk. Also on 20 August, Cloudflare expanded leaked-credentials detection to Basic Authentication credentials in the Authorization header. That change finds an attempt; it does not itself decide whether to block the request, reset the credential, or close an account incident.

These are not three versions of the same workflow. They are three different transitions: detecting a condition, changing an exposed asset, and recording that a compensating control exists. A fourth transition—removing the underlying defect—may still be open after the dashboard says the alert is closed.

The repeated angle to avoid

The ten most recent posts here covered soft-navigation measurement, agent authorization loops, credential isolation, cross-border payment routing, MCP traffic detection, encrypted handshakes, deployment authentication, checkout-field experiments, plugin trust, and agent context copies. Older overlapping posts covered security-alert playbooks, scan freshness, public secret monitoring, code-quality gates, and central scanning configuration.

The weak version of this article is the old X needs Y formula: security findings need better remediation. That would repeat the existing advice to route alerts to owners and collect closure evidence.

The sharper thesis is that one closed-alert count compresses incompatible technical states. A WAF rule can mitigate exploitable code without changing it. A CASB action can remove one exposed share without preventing another. A detector can expand its coverage without changing the application. A source fix can ship while an old deployment or branch remains exposed. Operators need a state vector, not a success boolean, or the queue will erase exactly the residual risk that matters.

Fresh evidence and background context

The source map separates this week’s product changes from the current documentation that exposes their mechanics:

Source	Freshness	What it contributes
Cloudflare CASB remediation policies	21 August 2026	Automatic first-party remediation and webhook actions for matching SaaS findings
GitHub’s Mitigated dismissal reason	20 August 2026	A distinct disposition for vulnerabilities that remain in code behind external controls
Cloudflare leaked-credentials detection for Authorization headers	20 August 2026	Automatic expansion of detector coverage to Basic Authentication credentials
Cloudflare remediation-policy documentation	Updated 21 August 2026	New-instance scope, permission requirements, runtime logs, vendor failures, and policy limitations
Cloudflare finding-state documentation	Updated 21 August 2026	The pending, processing, validating, completed, failed, and rejected lifecycle
GitHub code-scanning alert documentation	Current primary documentation	Dismissal effects across branches, alert-count removal, suppression on later scans, comments, and reopening
Cloudflare leaked-credentials documentation	Current primary documentation	Detection fields, rule actions, origin header, custom locations, and the distinction between attackers and legitimate users

The new information surplus is the operating model between the sources. One vendor documents a validated remediation state machine; another adds a more precise risk disposition; a third detector silently widens what it observes. Joined together, they show why security reporting must preserve the treatment used, the control still carrying risk, and the evidence that can reopen the finding.

A finding has more than one state

The common model is too small:

open -> closed

A useful model separates at least six questions:

State	Question	Positive evidence	What can still be open
Detected	Did a named detector observe the condition?	Rule, asset, location, scan version, timestamp	Whether the result is real or exploitable
Mitigated	Is a control reducing reachability or impact?	WAF rule, network policy, feature disable, rate limit, access restriction	The vulnerable code or configuration still exists
Remediated	Was the affected live object changed?	Share revoked, token disabled, permission removed, account isolated	The process that created the exposure may remain
Fixed	Was the source defect or unsafe default changed?	Merged code, corrected template, safer role, policy change	Old deployments, copies, branches, or objects may remain
Validated	Did a later check prove the intended state?	Rescan, negative test, API readback, independent probe	Recurrence after the validation time
Closed	Did the workflow decide that no more queue work is due now?	Disposition, owner, rationale, review date	Any residual risk explicitly accepted or carried by a control

The states can arrive in different orders. A team may mitigate first because a WAF rule takes minutes, remediate exposed records next, fix the source in a later release, and validate after deployment. For an accidental public file share, remediation may come first; prevention may require a separate policy later. For a false positive, detection is invalidated and the other states do not apply.

The key is not to force every incident through every label. It is to stop closed from pretending to answer all five technical questions above it.

Mitigation leaves a live dependency

GitHub’s new dismissal reason is valuable because “won’t fix” and “mitigated” communicate different operating commitments. In a mitigated finding, the code condition is still real enough to matter. Safety depends on another control continuing to intercept the exploit path.

GitHub’s current alert documentation makes the queue consequence important. When an alert is dismissed, it is removed from the project’s current-alert count, moved to the closed list, dismissed across all branches, and the same code does not generate an alert on the next scan. A dismissal comment can preserve context, and the alert can be reopened later.

That means a mitigation record must carry more than “protected by WAF.” It should identify:

• the exact control and rule ID;
• the routes, hosts, methods, deployments, and branches it covers;
• the exploit fixture or request the control rejects;
• the owner who can inspect and restore the control;
• monitoring that detects bypass or disablement;
• an expiry or review date;
• the source-fix plan, if one exists;
• the event that automatically reopens the finding.

A WAF rule covering www.example.com may not cover an origin hostname, preview deployment, regional API, mobile endpoint, internal route, or a newly added method. A network policy may not cover off-network clients. A feature flag may be re-enabled. A rate limit can reduce exploit volume without making one successful request harmless.

Mitigation is therefore a lease on another control’s reliability. It should expire unless revalidated.

Remediation changes the object that is risky

Cloudflare’s CASB policies demonstrate a stronger transition than notification. For supported file and folder findings, Cloudflare can call the Microsoft 365 or Google Workspace API and revoke a sharing configuration. The active object changes.

The documentation exposes a useful lifecycle:

pending
  -> processing
  -> validating
  -> completed
  |-> failed
  |-> rejected

Validating means the action completed and CASB is waiting for confirmation that the finding was resolved. Completed means the system says it both performed the action and validated the result. Failed can represent a vendor error. Rejected means the integration lacks the required permission. Runtime policy logs include the triggering finding, affected asset, success or failure, and errors such as 401 Unauthorized or rate limiting.

That is a better model than closing the ticket when an API call is queued. It distinguishes intent, execution, and readback.

It also exposes four trade-offs:

1. Write authority is required. Automated remediation needs a read-write integration, so the system that reduces exposure can also change business data and collaboration state.
2. The action can be correct and disruptive. Automatically revoking a legitimate external share may interrupt a customer, contractor, accountant, or partner workflow.
3. Coverage is prospective. New or edited policies apply to newly discovered matching instances, not the existing backlog.
4. Object repair does not prevent recurrence. Revoking one share removes that exposure. A separate Gateway or application policy may be needed to stop users creating the same exposure again.

The rollout pattern should reflect those trade-offs. Start with webhook-only observation for a narrow finding type. Inspect how many matches are legitimate, who owns the affected files, and how recovery works. Then enable automatic remediation where exposure cost is high, false-positive cost is bounded, and restoring an approved share is straightforward.

Detection coverage can change without an application release

Cloudflare’s Basic Authentication change was applied automatically to zones that already had leaked-credentials detection enabled. No application configuration changed, but the detector gained another default scan location.

That creates a measurement boundary. More matches after 20 August may mean more credential-stuffing attempts, more legitimate users reusing leaked passwords, or simply that previously invisible Authorization: Basic ... requests became visible.

The detector populates fields such as cf.waf.credential_check.password_leaked. Operators can use those fields in custom or rate-limiting rules to challenge or block traffic. A managed transform can also pass an Exposed-Credential-Check header to the origin so the application can warn a legitimate user or initiate a reset path.

Those are separate decisions:

credential observed in a scanned location
  -> match classified
  -> request allowed | challenged | rate-limited | blocked
  -> account warned | credential reset | incident reviewed
  -> future login tested

A match does not prove an attacker owns the account; Cloudflare notes that a legitimate user may simply be reusing a leaked password. Conversely, allowing the request and showing a warning does not make the credential safe. The appropriate response depends on account consequence, confidence of the match, available recovery flow, and whether stronger authentication exists.

Keep a detector-version or coverage-change annotation beside the volume chart. Otherwise an automatic improvement in visibility can be reported as a sudden attack surge, while a quiet chart can be mistaken for safety on authentication paths the detector never parsed.

Disposition should describe treatment, not appearance

Use a narrow disposition vocabulary and require evidence appropriate to each choice:

Disposition	Condition	Required evidence	Reopen trigger
False positive	Detector’s claim does not hold	Reproduction, data-flow explanation, scanner limitation	Query or code path changes
Mitigated	Condition exists; compensating control reduces risk	Control ID, coverage test, owner, expiry	Control disabled, bypass found, scope changes, review date passes
Remediated	Affected live object or credential was changed	API outcome plus readback or rescan	Same object or identity becomes exposed again
Fixed	Source defect or unsafe default was removed	Code/config diff, deployment evidence, regression test	Vulnerable path reappears in any supported deployment
Accepted	Residual risk is consciously retained	Business owner, impact, reason, expiry	Exposure, threat, value, or regulation changes
Ignored/hidden	Queue visibility changed	Rationale for reduced visibility	New instance, severity change, scheduled review

“Ignored” is not a synonym for any treatment. Cloudflare’s CASB documentation makes this explicit operationally: ignored and hidden findings continue to be scanned and reported in separate tabs. Visibility moved; the underlying object did not necessarily change.

Likewise, a webhook is transport, not treatment. A successful request to send a notification proves that the event entered a delivery path. It does not prove the destination processed it, a human acted, an API mutation succeeded, or a later check found the asset safe.

Keep a security treatment receipt

A compact receipt can join the queue state to the technical states without storing credentials or sensitive payloads:

security_treatment_receipt:
  finding_id: codeql-alert-481
  detector:
    product: github-code-scanning
    rule: example-query-id
    analysis_configuration: default-setup-v4
    observed_at: 2026-08-23T02:14:00Z
    affected_surfaces:
      - api.example.com/import
      - preview-api.example.com/import
  condition:
    confirmed: true
    summary: untrusted archive path can escape extraction directory
  queue:
    state: dismissed
    disposition: mitigated
    rationale: emergency control while source fix is reviewed
  mitigation:
    control: cloud-waf-custom-rule
    control_id: waf-rule-7f2c
    coverage:
      - production-custom-domain
    known_gaps:
      - preview-origin
    owner: web-operations
    enabled_at: 2026-08-23T03:01:00Z
    expires_at: 2026-08-30T03:01:00Z
  remediation:
    affected_objects_changed: false
  source_fix:
    pull_request: owner/repo#842
    merged: false
    deployed_versions: []
  validation:
    exploit_fixture: tests/security/archive-traversal.zip
    mitigation_test: passed
    uncovered-preview-test: failed
    checked_at: 2026-08-23T03:12:00Z
  reopen_when:
    - mitigation_disabled
    - new_host_or_route_added
    - mitigation_expired
    - exploit_fixture_reaches_application

This receipt correctly permits an uncomfortable state: the GitHub alert is dismissed while one preview path remains exposed and the source fix is unmerged. A dashboard that shows only closed would hide that fact. The receipt makes it queryable and gives automation a reason to reopen the work.

For a CASB remediation, the same shape would record the file ID, policy invocation, vendor API outcome, validation status, and prevention policy. For a leaked Basic Authentication credential, it would record the detection class, edge action, account recovery result, and whether the credential failed on a controlled subsequent attempt—never the username or password itself.

Metrics should preserve the transitions

Do not reward a security programme for closing alerts quickly if “closed” mixes false positives, accepted risks, temporary mitigations, completed remediations, and source fixes.

Track separate clocks:

• time to confirm: detection to verified finding;
• time to contain: confirmation to active mitigation;
• time to remediate: confirmation to affected-object change;
• time to fix: confirmation to source change deployed everywhere relevant;
• time to validate: action to independent evidence;
• mitigation age: how long residual safety has depended on a compensating control;
• recurrence rate: how often the same condition returns after remediation or fix.

These metrics answer different operational questions. Fast containment with slow source repair can be an honest, safe temporary posture. Fast queue closure with rising mitigation age is a backlog being hidden. Fast remediation with high recurrence means the team repairs objects but not the process producing them.

Report counts by disposition and technical state. Never combine them into one “resolved vulnerabilities” total without showing the composition.

A rollout sequence for automated security action

A small team can apply this model without building a security operations platform:

1. Choose the five finding types with the highest business consequence. Include authentication, public sharing, production secrets, checkout or booking code, and administrative access where relevant.
2. Define the treatment vocabulary. Decide what mitigated, remediated, fixed, accepted, and false positive mean in your environment.
3. Require a validation step. Prefer API readback, a rescan, a negative request, or a business-system query over a successful command response.
4. Observe before granting write authority. Send findings to a webhook or review queue first; measure false positives and recovery cost before automatic mutation.
5. Automate narrow, reversible remediations. Start with one vendor, integration, finding type, and recovery owner rather than every available policy.
6. Give every mitigation an expiry. Test the control on each hostname, route, deployment class, and network path it claims to cover.
7. Reconcile the existing backlog. A new policy that applies only to future findings must not create an empty dashboard while old exposures remain.
8. Wire reopening to control drift. A disabled WAF rule, expired exception, new route, failed vendor action, or recurring share should create work automatically.
9. Review disposition metrics monthly. Rising mitigations, repeated remediations, and long validation delays deserve more attention than a falling open-alert count.

The decision rule for automation is practical: automate when the finding is high-confidence, the action is narrow and reversible, the validation is machine-checkable, and business interruption has a named recovery path. Keep a human decision where context determines whether the exposure is legitimate or the action is difficult to undo.

Failure modes worth testing

The policy exists, but the backlog never moved

A CASB remediation policy applies only to newly discovered matching instances. Existing public or external shares remain active. Run a one-time backlog review and record the cutoff time before treating the policy as coverage.

Invocation is mistaken for completion

The automation emits a webhook or starts a vendor action, then closes the ticket. A 401, rate limit, expired grant, or asynchronous failure leaves the object exposed. Close the remediation state only after the runtime outcome and validation readback succeed.

A mitigated dismissal outlives the control

The code-scanning alert is dismissed across branches and suppressed on later scans. Months later, a WAF rule is removed during cleanup, but no alert reopens. Connect control deletion and expiry events to the finding register, and keep the exploit fixture runnable outside the scanner.

Automatic revocation breaks legitimate work

A high-confidence file-sharing detector revokes an approved customer or partner share. Begin with notification, keep asset ownership in the event, define an exception path, and test how quickly an authorised share can be restored without disabling the whole policy.

The source is fixed, but old surfaces remain

The vulnerable code is merged on the default branch while an old deployment, release branch, preview, desktop client, or regional service still runs it. Record deployed versions and test reachable surfaces before moving from fixed to validated.

Detection coverage grows and incident volume appears to spike

Authorization-header scanning activates automatically and newly visible attempts flood the chart. Annotate the detector change, separate authentication location and action, and compare stable coverage cohorts before declaring a threat trend.

Hiding becomes accidental risk acceptance

A finding or instance moves to an ignored tab, removing urgency without an owner, expiry, or treatment. Require the same rationale and review date for visibility changes that you require for explicit risk acceptance.

The practical conclusion

The fresh releases improve three useful parts of security operations. Cloudflare can now remove certain SaaS exposures without waiting for a person. GitHub can distinguish a real vulnerability behind a compensating control from a generic refusal to fix it. Cloudflare’s WAF can detect leaked credentials in an authentication location that was previously outside default coverage.

Their value depends on preserving what each action actually proves. Detection says a named observation matched. Mitigation says another control currently reduces risk. Remediation says an affected object changed. A fix says the producing defect changed. Validation says a later check observed the intended result. Closure says the team decided what work remains due.

Keep those states separate, link them in one receipt, expire compensating controls, and reopen findings when evidence drifts. Then automation can shorten real exposure instead of merely moving alerts out of the active queue.