Skip to content
Furl Docs

Remediation Scopes

A remediation scope is a standing policy that defines what should be kept healthy. Think of it as a rule: “keep Chrome updated on all Windows laptops in the engineering department.” Scopes are declarative — you define what you want, and Furl continuously works to make it true.

How scopes work

Section titled “How scopes work”

A scope is defined by three filters that together describe a remediation policy:

FilterQuestion it answersExample
Subject filterWhat to remediate?Chrome, Firefox, all software by Mozilla
Endpoint filterWhere to remediate?Windows laptops, endpoints tagged “engineering”
Finding filterWhat triggers remediation?Critical and high severity vulnerabilities only

All filters are optional. An empty filter means “match all” for that dimension. A scope with no filters would remediate everything everywhere — valid, but unusual.

Creating a scope

Section titled “Creating a scope”

When you create a scope, you specify the three filters above plus a few other settings.

  1. Pick the subject filter — choose specific subjects (e.g., Google Chrome), a vendor (e.g., all software by Mozilla), or leave empty to match every subject.
  2. Pick the endpoint filter — narrow to OS family, hostname patterns, tags, owners, or other endpoint attributes. Use this to start small (e.g., one team) before expanding.
  3. Pick the finding filter — limit the trigger to specific finding types (vulnerability, compliance) or severities. A common pattern is “critical and high vulnerabilities only” until you’ve built confidence.
  4. Optionally attach an update ring policy — partition matched endpoints into ordered stages so the rollout is gradual.
  5. Activate the scope.

When a scope activates, Furl evaluates every existing target against its filters and starts remediation for matches. New targets discovered later are matched on arrival.

Start narrow. A scope filtered to a small endpoint group (a canary tag, a single team, a few owners) lets you observe outcomes before broad rollout.

Scope lifecycle

Section titled “Scope lifecycle”
active → paused → archived
StatusBehavior
ActiveContinuously matching new targets and creating executions
PausedStops creating new executions; in-flight executions continue to completion
ArchivedRead-only; preserved for audit history

You can pause a scope at any time — useful during change freezes or when you want to halt new work without disrupting in-flight remediations.

Event-driven matching

Section titled “Event-driven matching”

Scopes don’t run on a schedule — they react to events:

  1. Scope activation — when a scope is created or activated, it evaluates all existing targets against its filters.
  2. Target discovered — when a new target appears (from a scanner sync), it’s matched against all active scopes.

This means new vulnerabilities are picked up automatically as soon as scanner data flows in.

What happens when a target matches

Section titled “What happens when a target matches”

When a target matches a scope’s filters:

  1. Deduplication check — is there already an active execution for this scope + endpoint + target?
  2. Validation check — is the target confirmed to exist? (See target validation.)
  3. Governance evaluation — should this auto-execute, require approval, or be blocked?
  4. Strategy selection — pick the best strategy based on confidence score.
  5. Execution creation — create a strategy execution record and dispatch to the agent.

If the scope has an update ring policy, the target is only dispatched when its endpoint belongs to the currently active ring.

Section titled “Related”