Skip to main content
A Group (asset group) is a named collection of assets used to scope discovery runs and workflows to a subset of your attack surface. Instead of scanning everything every time, you define groups that represent the parts of your infrastructure you want to target — then run discovery and workflows against exactly that scope. You can reach the module from the console sidebar under Attack surface → Groups (/groups).
Groups are workspace-scoped and operate only on assets within the same workspace.

​
Why use groups

  • Targeted operations — run discovery or workflows against a specific subset of assets instead of the whole inventory
  • Scoped automation — scheduled workflows run only against the assets in the group
  • Operational segmentation — mirror your environments (production, staging, development) or business units
  • Reusable scope — define the collection once, reuse it across manual runs and schedules
A group acts as the bridge between “these assets belong together” and “run this discovery/workflow only here”.

​
Groups vs targets

Groups and targets are complementary — they are not alternatives: A target is where discovery starts; a group is where you assemble the results for targeted operations.

​
Groups table

The Groups page lists all groups in the workspace: Use the Create button to start a new group, or click a group name to open its detail page (/groups/:id).

​
Create a group

1

Open the create form

On the Groups page, click Create to open the creation form (/groups/create).
2

Name the group

Enter a descriptive name that reflects its purpose, for example production-hosts or staging-services.
3

Create the group

Submit the form. The new group appears in the list with zero hosts and no runs yet.
4

Add assets

Open the group and add assets from your existing asset inventory. Assets inside the group define the scope of every run against it.

​
Manage group assets

The assets inside a group define the scope of every run against it:
1

Open the group

From the Groups page, click the group name to open its detail page (/groups/:id).
2

Add assets

Add assets from your existing asset inventory. Only assets that exist in the workspace can be added — groups operate on discovered assets, not raw inputs.
3

Review the scope

Check the Total Hosts counter to confirm the group contains exactly the intended scope before running anything.
4

Remove assets

Remove assets from the group when they no longer belong to its scope. Removal only affects the group membership — it never deletes the underlying asset.

​
Run discovery against a group

With a group in place, you can execute discovery scoped to its assets:
  1. Open the group’s detail page
  2. Trigger a discovery run — either manually or through a scheduled run
  3. Monitor the run’s progress in the Jobs module
Each run is recorded as either a manual run (started by you) or a scheduled run (started automatically by a schedule). This distinction appears in the job registry, so you can tell at a glance whether a run was an explicit action or part of the automation schedule.

​
Run workflows against a group

Groups scope workflows as well as discovery. This lets you bind automation to a group: define a workflow once, attach it to the group, and trigger it manually or on a schedule — always against exactly the group’s assets.
1

Attach a workflow to the group

Associate a workflow with the group.
2

Run it

Trigger the workflow scoped to the group — on demand, or through a scheduled run. The run executes against exactly the group’s current assets.
3

Monitor the run

Track progress and results in the Jobs module, where the run shows whether it was manual or scheduled.
Use scheduled runs for recurring checks (daily or weekly) and manual runs when you change infrastructure and want immediate coverage. See Jobs for run history and status.

​
Common questions

Groups are independent collections of workspace assets. Design them with a clear purpose — for example one group per environment — so a run scoped to a group only affects that group’s members, and there is no ambiguity about what a job covered.
No. Deleting a group removes the group and its configuration only; the underlying assets remain in the inventory. A deleted group’s workflows are no longer scoped to anything, so recreate the group if the scope is still needed.
The name should make the scope obvious from job history alone — for example production-hosts, staging-services, or customer-a-edge. A reviewer should understand what a run covered without opening the group.
Both execute the same discovery or workflow logic against the group’s assets. The difference is the trigger: scheduled runs are started automatically by the schedule, manual runs are started by a user. The job registry records the trigger type for every run.

​
Best practices

  • Segment by environment — create separate groups for production, staging, and development so scans and workflows never mix scopes
  • Scope scheduled scans — attach schedules to groups instead of scanning the entire inventory, reducing noise and load
  • Keep names descriptive — production-hosts is clearer than group-1 when you review job history later
  • Review Total Hosts — watch for unexpected jumps in the Total Hosts column, which can signal new exposure added to the scope
  • Reuse workflows — bind a workflow to several groups when the same checks apply, rather than duplicating configuration

Targets

Define the discovery scope that populates assets before grouping them.

Assets

The inventory that groups collect and scope.

Notifications

Get notified when group-scoped discovery and automation runs finish.

Jobs

Track manual and scheduled runs triggered for groups.
Everything available in the console is also available through the API — see the API Reference tab.