Skip to content

Systems & Groups

OpenSCM uses an automated discovery model paired with a manual approval gate — agents register themselves automatically, but a security administrator must explicitly approve each one before it can receive compliance tests.

Systems

A System represents any endpoint running the scmclient agent — servers, workstations, or any supported device.

Automatic Discovery

You do not need to manually create system entries in the dashboard.

  1. Install scmclient on the endpoint
  2. Configure the server URL in the config file:
    # /etc/openscm/scmclient.config
    [server]
    url = "https://your-openscm-server.com"
    tenant_id = "default"

    # /usr/local/etc/openscm/scmclient.config
    [server]
    url = "https://your-openscm-server.com"
    tenant_id = "default"

Set ServerURL in the registry at: HKEY_LOCAL_MACHINE\SOFTWARE\OpenSCM\Client

  1. Start the agent service — it will automatically register with the server
  2. The system appears in the dashboard under Systems highlighted as New

Adding a New System

Click the New System button at the top of the Systems page to open the agent download page, where you can download and install scmclient on a new endpoint.

Approving a System

New systems are Pending and cannot receive compliance tests until approved.

  1. Navigate to Systems
  2. Locate the system marked with a New badge
  3. Review the metadata — Hostname, IP, OS, Architecture — to verify it is a legitimate device
  4. Click Approve
  5. On the next heartbeat the cryptographic handshake completes and the system becomes Active

Security Notice

Never approve a system you do not recognize. The approval step exists specifically to prevent unauthorized agents from joining your compliance network.

Assigning a System to Groups

After approval, assign the system to one or more groups:

  1. Click the Edit (pencil) icon next to the system
  2. Select the desired groups from the dual list
  3. Click Save Changes

Group assignment determines which policies the system participates in.

Bulk Actions

Select multiple systems using the checkboxes on the left of each row, then use the bulk toolbar that appears at the top of the table:

Action Description
Approve Approve all selected pending systems in one click
Add to Group Assign all selected systems to a group
Delete Permanently remove all selected systems

The Select All checkbox in the header selects all rows matching the current search filter, not just the visible page.

Editor role required

Bulk actions require at least the Editor role.

Rejecting or Deleting a System

  • Reject (Pending) — click the Delete button on a pending system to reject the registration request
  • Delete (Active) — removes the system and all its compliance history from the database

Data Loss Warning

Deleting an active system permanently removes its historical compliance data. If the agent is still running on the endpoint it will attempt to re-register as a new pending system and require re-approval.

System Groups

Groups organize your infrastructure logically — by department, environment, OS type, or any other classification that makes sense for your organization.

Groups are the link between systems and policies. A policy is assigned to one or more groups — every system in those groups participates in that policy's compliance scans.

System Group "Production-Linux"
    ├── web-server-01
    ├── web-server-02
    └── db-server-01
            ↓
    Policy: "CIS Ubuntu 22.04"
            ↓
    All three systems are scanned against this policy

Creating a Group

  1. Navigate to System Groups
  2. Click New Group
  3. Enter a name and description
  4. Optionally assign systems immediately using the dual list
  5. Click Create Group

Editing a Group

Click the Edit icon to:

  • Rename the group or update its description
  • Add or remove systems using the dual list

Changes take effect immediately — systems added to a group will be included in the next policy scan.

Deleting a Group

Deleting a group removes the group definition and unlinks all systems from it. The systems themselves are not deleted — they remain in the inventory and can be assigned to other groups.

Best Practice

Structure your groups to mirror your infrastructure segments. For example:

  • Production-Linux — production Linux servers
  • Production-Windows — production Windows servers
  • Dev-Linux — development and staging Linux systems
  • Network-DMZ — DMZ-facing systems requiring stricter policies

This makes it easy to apply different policy strictness levels to different segments of your network.