Every scan you launch needs a target. Every report you generate needs a scope. Every dashboard tile that reads “critical web assets” needs a definition of which assets qualify. If your team rebuilds that target list by hand each time, two things happen. The selection drifts out of date the moment inventory changes, and the chance of pointing a scan at the wrong machines climbs with every manual pick.
Asset groups solve this by turning a one-time decision into a reusable, named scoping layer. In PMAP, you define a group once and reference it across scans, reports, and dashboards by ID. There are two ways to build one. A static group is a curated list you control by hand. A dynamic group is a rule that gets re-evaluated against your live inventory every time someone opens it. This guide explains when each model fits, how dynamic membership stays current without anyone touching it, and how the live rule preview lets you see exactly which assets a rule matches before you commit.
If you are still working out how to consolidate scattered scanner output and manual records into one clean source of truth, start with our pillar on attack surface and asset inventory management. This article assumes you already have an inventory and now want to slice it into reusable scopes.
Why Hand-Picking Assets Per Scan Does Not Scale
Manual asset selection feels fine on a small estate. You have forty servers, you know them by name, and ticking boxes in a list takes a minute. The problem is that vulnerability management is not a one-time exercise. You scan the same scope again next week, next month, and after every change window. Each repetition is another chance to select the wrong set.
There are three failure modes that show up at scale. The first is drift. You hand-pick a scope today, and tomorrow three new cloud instances spin up that belong in it. Nobody adds them to your saved selection because the selection is frozen in time. Your next scan quietly skips assets that should have been covered, and you do not find out until something in that blind spot gets exploited.
The second is error. When you select assets by clicking through a long table, it is easy to miss one, include a decommissioned host, or grab a similarly named machine from the wrong business unit. A scan pointed at the wrong target wastes capacity at best. At worst it triggers alarms on systems you were never authorised to touch.
The third is duplicated effort. A pentest scope, a monthly compliance scan, and an executive dashboard might all care about the same set of internet-facing assets. If each one carries its own hand-built list, you maintain the same definition in three places, and they fall out of sync the first time the estate changes.
Asset groups remove all three. The definition lives in one place. Scans, reports, and dashboards all point at the same group, so they share one source of truth. Dynamic groups go further and keep that definition current on their own. The rest of this article walks through how that works.
Two Group Models: Static and Dynamic
PMAP gives you exactly two group types, and the choice between them is the most important decision you make when creating a group. The type is set at creation and is immutable afterward, so it pays to understand the difference before you click save.
A static group is a hand-curated list. You add and remove individual assets through explicit operations, and the membership stays exactly as you left it until you change it. Behind the scenes, a static group stores actual membership rows that link the group to each asset. When you open the group, PMAP joins those rows against the asset table and shows you the members you put there. Nothing else gets in, and nothing falls out on its own.
A dynamic group is a rule, not a list. Instead of storing member rows, the group stores a set of criteria as a JSONB rule. Every time someone opens the group, PMAP evaluates that rule against the live asset inventory and returns whatever currently matches. No member rows are ever written. The membership is computed fresh on read, which is exactly why a dynamic group never goes stale.
The practical question is how often the underlying set changes. If your scope is fixed and deliberate, like the precise machines in scope for a contracted penetration test, a static group gives you the control you want. The auditor agreed to a list, and you want that list to stay frozen for the duration of the engagement. If your scope is defined by a property rather than a roster, like “every critical asset in the payments business unit,” a dynamic group expresses the intent directly and keeps up with reality.
You do not have to pick one model for the whole organisation. Many teams run both. Static groups pin down regulated or contractually fixed scopes, and dynamic groups cover the parts of the estate that change often, such as cloud workloads that scale up and down through the day. On the group detail page, the two are easy to tell apart. A type badge marks each group, and a dynamic group shows its rule conditions as chips so anyone can read the logic at a glance.
How Dynamic Membership Stays Current
The defining behaviour of a dynamic group is that membership is resolved at query time. There is no nightly job that recomputes membership, no cache that can drift, and no member table to fall out of sync. The rule is the membership.
Here is the mechanism. When you create a dynamic group, PMAP stores your criteria as a DynamicRule in a JSONB column. When anyone opens that group, the stored rule is evaluated inline against the assets table at read time, and the matching assets are returned as the group’s evaluated members. Because evaluation happens on every read, the answer always reflects the inventory as it stands at that moment. An asset that was provisioned an hour ago and matches the rule appears immediately. An asset that was decommissioned drops out the next time the group is opened. Nobody has to maintain anything.
This self-healing property is what makes dynamic groups worth the setup. Consider a rule that selects every asset with criticality set to critical and an asset type of web application. As your team onboards new public-facing services and tags them correctly in the inventory, they flow into the group automatically. As old services are retired, they leave. The scan that targets this group always hits the current set, not a snapshot from whenever someone last remembered to update a list.
To keep evaluation fast, PMAP caps dynamic rule results at 500 assets in the detail view. A rule that matches more than 500 assets still works as a scope, but the detail page shows the first 500 to bound query latency. If you are building a dynamic group whose match set is genuinely huge, that cap is a signal to tighten the rule so the group stays meaningful and readable.
The Rule Fields You Can Combine
A dynamic rule is built from a fixed set of criteria, and you combine the ones you need. Each field maps to a specific filter against the asset table.
- Asset type matches an exact asset type, so you can scope to web applications, network devices, or whatever classifications your inventory uses.
- Asset class matches an exact class for a broader cut than type.
- Criticality matches an exact criticality level, which is how you build the “all critical assets” style of group.
- Tags (any) matches assets that carry at least one of the tags you list, using array overlap. This is the inclusive option.
- Tags (all) matches assets that carry every tag you list, using array containment. This is the strict option for narrowing to assets that satisfy several conditions at once.
- Location matches an exact location, useful for geographic or data-centre scoping.
- IP in CIDR matches any asset whose IP address falls inside a CIDR range. This is the network-based selector, and it evaluates by checking whether an asset’s IP sits within the supplied range.
- Name search matches a substring against the asset name, which is handy when your naming convention encodes meaning into the hostname.
These fields work together. A rule can say criticality is critical and IP falls within 10.0.0.0/8 at the same time, and only assets that satisfy both conditions match. The combination is where the expressiveness comes from. You are not picking assets. You are describing them, and the inventory tells you which ones fit.
One detail worth understanding about CIDR matching is what it actually checks. The ip_in_cidr criterion looks at an asset’s IP addresses and includes the asset if any of them falls within the supplied CIDR range. That means a host with multiple interfaces is captured as long as at least one of its addresses lands inside the range. This is the behaviour you want for network-segment scoping, where membership in a subnet defines whether an asset belongs in scope.
Previewing a Rule Before You Commit
The hardest part of writing any rule is trusting that it does what you think. A criticality filter is obvious. A combination of tags, a CIDR range, and a name substring is less so, and a rule that is slightly too broad or too narrow produces a group that scopes scans incorrectly. PMAP handles this with a live preview that runs your rule against real inventory without creating anything.
When you build a dynamic group, the create and edit modal opens a two-panel layout. The left panel holds the rule field inputs, where you set asset type, criticality, tags, CIDR, and name search. The right panel is a live preview of the assets that currently match. You press an explicit preview button, the rule is evaluated against your inventory, and the matching assets appear on the right. Nothing is saved. No group exists yet. You are looking at exactly what the rule would capture if you committed it.
This is more than a convenience. It changes how you author rules. Instead of guessing, saving, opening the group, checking the membership, and editing if it is wrong, you tune the criteria and watch the result update in place. If the preview returns more assets than you expected, you add a condition to narrow it. If it returns too few, you loosen one. You converge on the right rule with no side effects and no half-built groups left behind.
The preview is powered by a dedicated endpoint that evaluates a rule body without persisting a group. The same capability shows up again on the static group detail page. When you enter a CIDR in the member picker there, the picker uses the same preview mechanism to show you which assets fall in that range before you add them, complete with an option to add the whole matching set at once. The preview, in other words, is not a one-off feature bolted onto the create flow. It is the consistent way PMAP lets you see a match set before you act on it.
Building a Fixed Pentest Scope With Static Groups
Dynamic groups shine when membership is defined by a property. Plenty of scopes are not. A penetration test runs against a list that a client and a testing firm agreed on, and that list must not change midway. A compliance scan covers a defined set of regulated systems. For these, you want a static group that holds exactly the assets you chose and nothing else.
Static groups are built by adding members explicitly. You can add a single asset at a time, but the efficient path for a large scope is bulk addition. PMAP lets you attach up to 5,000 assets to a static group in one operation. If a payload exceeds that limit, the API rejects the request rather than partially applying it, so you always know whether the full set landed. Duplicate members are handled gracefully. If an asset is already in the group, adding it again is a no-op rather than an error, and the response reports how many rows were actually inserted.
The detail page also supports network-based bulk addition for static groups. When you open the member picker and enter a value the system recognises as a CIDR range, the picker switches into CIDR mode and offers an add-all toggle. This runs the same live preview described earlier, shows you the assets in the range, and lets you attach the whole set with one action. It is the fastest way to bring an entire subnet into a fixed scope. The difference from a dynamic group is important and deliberate. Here, the CIDR is used once to select members, and those members are then frozen into the static list. A dynamic group with a CIDR rule keeps re-evaluating the range forever. A static group built from a CIDR captures the assets that were in the range at the moment you added them, and it does not change afterward.
There is one safety boundary on bulk addition that matters for multi-tenant deployments. Assets that belong to a different company cannot be attached to a group. The system enforces same-company membership at the database level, so a bulk payload that mixes in cross-tenant asset IDs simply excludes them, and the inserted count reflects only the assets that legitimately belong. You cannot accidentally pull another tenant’s machines into your scope.
The detail page rounds out the static workflow with context. A criticality breakdown card shows how many critical, high, medium, and low assets sit in the group, so an analyst can gauge risk exposure before scheduling a scan. Each member row carries a remove action for pruning stale entries. The result is a curated scope you can read, understand, and trust to stay exactly as you set it.
Where Groups Get Reused: Scans, Reports, Dashboards
A group is only worth building if you can point things at it, and this is where the reusable scoping layer pays off. Once a group exists, it becomes a scope selector that other parts of PMAP accept by ID.
Scans accept group IDs as their target. Instead of selecting individual assets each time you launch a scan, you choose the group, and the scan runs against its membership. For a static group, that is the curated list. For a dynamic group, it is whatever the rule matches at the moment the scan is scoped, which means a recurring scan against a dynamic group always covers the current set without anyone updating the target. This is the mechanism that connects asset groups directly to the scan coverage you can verify afterward, since a group that stays current is the first condition for coverage that stays honest.
Reports accept group IDs the same way. When you scope a report to a business unit’s assets, you point it at the group rather than rebuilding the asset list inside the report. The report and the scan that feeds it can share the same group, which keeps the scope consistent across the scan-to-report path.
Dashboards and analytics consume groups as aggregation units. Group-level rollups let a dashboard tile summarise findings, criticality, or progress for a defined slice of the estate. Because the slice is a group, the same definition that targets your scans also drives the numbers your managers watch, and the two cannot disagree about what counts as in scope.
This downstream reuse is the entire point of the feature. The group is defined once, in one place, and every consumer references the same definition. Asset segmentation stops being something you redo per scan and becomes a stable layer that the rest of the platform builds on. Groups also feed naturally into the way PMAP structures assessment runs and scan campaigns inside a project, where a group serves as the reusable scope a whole campaign targets.
Guardrails: Unique Names, Tenant Scope, Immutable Type
Reusable scopes carry a risk that hand-picked lists do not. Because a group is referenced by other things, a mistake in the group definition propagates to every scan, report, and dashboard that points at it. PMAP puts several guardrails in place so the reusable layer stays trustworthy.
Unique names per tenant. A database constraint prevents two groups in the same company from sharing a name. If you try to create a duplicate, the API returns a conflict response rather than silently making a second “Production Servers” group that someone could target by mistake. This matters precisely because groups are selected by people who read the name, and two groups with the same name are an accident waiting to happen.
Tenant scope on every path. Every list and export operation applies a scope filter so users only ever see groups belonging to companies they are authorised for. Direct lookups go further. When a user requests a group that belongs to another tenant, PMAP returns a not-found response rather than a forbidden one. The distinction is deliberate. A forbidden response confirms that the group exists, which leaks information. A not-found response reveals nothing about whether the ID is real, which prevents enumeration of other tenants’ groups.
Immutable type. A group’s type, static or dynamic, is fixed at creation and cannot be changed later. You cannot convert a static group into a dynamic one or back. If you need to switch models, you delete the group and create a new one of the desired type. This constraint keeps the semantics clean. A consumer that targets a group never has to wonder whether the group’s behaviour changed underneath it, because the type it was created with is the type it keeps.
Permission checks on mutation. Creating, updating, and deleting a group all check whether the acting user is permitted to mutate asset groups for that group’s company. Member additions and removals reuse the update permission. The reusable scope layer is therefore governed by the same role-based access control as the rest of the platform, so the people who can change a scope are the people who are supposed to.
Together these guardrails mean that a group you find in PMAP is one you can rely on. Its name is unique, it belongs to your tenant, its type is stable, and only authorised users could have changed it. That reliability is what makes it safe to wire groups into scans and reports that run unattended.
How PMAP Keeps Scoping Reusable
Step back from the individual features and the through-line is simple. Scoping should be a definition you maintain in one place, not a selection you rebuild every time. PMAP delivers that through two complementary group models and a preview that lets you trust a rule before you depend on it.
Static groups give you deliberate, frozen control for scopes that must not change, like a contracted pentest target or a regulated system set. You curate them by hand, add members in bulk up to 5,000 at a time, pull in whole subnets through CIDR selection, and the membership stays exactly as you left it. Dynamic groups give you self-healing scopes for the parts of your estate that change constantly, expressing membership as a rule that re-evaluates against live inventory on every read. The live preview connects the two, letting you see a real match set before you commit, whether you are authoring a dynamic rule or adding a subnet to a static group.
Around all of it, PMAP enforces the guardrails that make a reusable scope safe to depend on. Names stay unique within a tenant, types stay immutable, tenant boundaries are never crossed, and access control governs who can change a scope. The payoff is that everything downstream, every scan, every report, every dashboard, can point at a group by ID and trust that the scope is current, correct, and exactly what someone intended.
If you want the procedural walkthrough, our companion guide on creating static and dynamic asset groups covers the step-by-step of building a group and defining a rule. This article focused on the why and the when. The decision between static and dynamic is the one that determines whether your scope drifts or self-heals, so make it deliberately. To go deeper on the inventory those groups are built from, see how PMAP merges every source into one trustworthy asset inventory.
For broader context on why an organised, grouped inventory underpins effective vulnerability management, the CIS Controls v8 Control 1 on enterprise asset inventory and NIST SP 800-53 control CM-8 on system component inventory both treat a current, well-segmented inventory as foundational. The OWASP Attack Surface Analysis Cheat Sheet makes the same case from the offensive-testing angle, where defining and segmenting scope is the first step before any assessment.
Frequently Asked Questions
What is the difference between a static and a dynamic asset group?
A static group is a hand-curated list of assets that you maintain through explicit add and remove operations. Its membership stays exactly as you set it until you change it. A dynamic group is a rule rather than a list. It stores criteria as a JSONB rule, and that rule is evaluated against your live inventory every time the group is opened, so its membership reflects whatever currently matches. Use static groups for fixed scopes like a pentest target and dynamic groups for scopes defined by a property like “all critical web assets.”
How do dynamic groups stay current when assets change?
Dynamic groups resolve membership at query time. There is no stored member list and no cached snapshot. When you open a dynamic group, PMAP evaluates the stored rule against the asset table at that moment and returns whatever matches. A newly provisioned asset that fits the rule appears immediately, and a decommissioned asset drops out on the next read. Nobody has to update anything, which is why dynamic group membership never goes stale.
Can I target a scan or report at an asset group instead of individual assets?
Yes. Scans and reports both accept a group ID as their scope selector. Instead of rebuilding an asset selection each time, you point the scan or report at the group, and it runs against the group’s membership. For a dynamic group, that membership is the current rule evaluation, so a recurring scan always covers the present set. Dashboards and analytics also consume groups as aggregation units, so the same definition that targets a scan can drive the numbers a dashboard reports.
How many assets can I bulk-add to a static group at once?
You can attach up to 5,000 assets to a static group in a single operation. If a request exceeds that limit, the API rejects it rather than applying it partially. Assets that are already members are skipped silently rather than causing an error, and the response reports how many were actually added. Assets belonging to a different company are excluded automatically, because membership is enforced within a single tenant.
What does the dynamic rule preview do, and does it create anything?
The preview evaluates a rule against your live inventory and shows you the matching assets without creating or saving a group. In the create and edit modal, a two-panel layout puts the rule inputs on the left and the live match results on the right. You press preview, see exactly which assets the rule would capture, and refine the criteria until the result is right. Nothing is persisted during preview, so you can tune a rule freely with no side effects and no half-built groups left over.
How does CIDR matching work in an asset group?
CIDR matching checks whether an asset’s IP address falls within a supplied range. In a dynamic group, the IP-in-CIDR criterion includes any asset that has at least one IP inside the range, and because dynamic membership re-evaluates on every read, the group keeps tracking that subnet as assets come and go. On a static group’s detail page, you can also enter a CIDR in the member picker to preview the assets in that range and add the whole set at once, which freezes those assets into the static list rather than tracking the range over time.
Can I change a group from static to dynamic later?
No. A group’s type is fixed at creation and cannot be changed afterward. This keeps the behaviour predictable for everything that targets the group, since a consumer never has to account for a group’s type changing underneath it. If you need the other model, you delete the group and create a new one of the desired type. Decide between static and dynamic before you create the group, because that choice determines whether the scope stays frozen or self-heals.
