# SBOM Continuous Monitoring

Vulnerability and policy violations for an SBOM remain static after the initial analysis performed when importing SBOMs. Continuous Monitoring automatically checks SBOM versions of an application for new violations on a nightly basis. Use this feature to alert you as to when your SBOMs have newly discovered vulnerabilities.

**Continuous Monitoring Behavior**

Continuous Monitoring for SBOM Manager uses the `Compliance` stage and functions independently from Lifecycle's monitoring configuration.

Administrators need to enable Continuous Monitoring before the SBOM Manager reports newly discovered violations.

**Operating Model:**

- Monitors SBOM versions (not limited to the latest version).
- Uses an evaluation queue to process SBOM evaluations asynchronously.
- Evaluations can be distributed across multiple instances.

## Monitoring Scope

By default, continuous monitoring evaluates all SBOM versions for an application.

You can restrict which versions are evaluated by configuring a version evaluation window.

## Evaluation Queue Configuration

Continuous monitoring uses an evaluation queue to process SBOM evaluations asynchronously.

### Configuration Properties

| Property | Description | Default Value |
| --- | --- | --- |
| `enabled` | Enables the evaluation queue producer and consumer | true |
| `producerPeriodInMilliseconds` | Interval at which the producer runs | 600000 (10 minutes) |
| `producerMaxQueuedRows` | Maximum number of evaluations queued by the producer | 1000 |
| `cyclePeriodInMilliseconds` | Expected duration of a monitoring cycle | 86400000 (24 hours) |
| `resetCycleTimeout` | Restarts the cycle if it exceeds the expected duration | false |
| `consumerThreadsPerTenant` | Number of threads used to process evaluations | 1 |
| `consumerPeriodInMilliseconds` | Interval at which the consumer runs | 300000 (5 minutes) |
| `consumerMaxQueuedRows` | Maximum number of evaluations processed per cycle | 30 |
| `consumerRowExpirationInMilliseconds` | Time before queued evaluations are released for reprocessing | 6000000 (100 minutes) |
| `startTimeDelayEnabled` | Starts the monitoring cycle at the configured policy monitoring hour instead of immediately | true |

**Note**

If a monitoring cycle does not complete within the expected duration, processing continues until all evaluations are completed unless `resetCycleTimeout` is enabled.

### cURL example

Use the Configuration REST API to update evaluation queue settings.

```
curl -u admin:admin123 \
  -X PUT "http://localhost:8070/api/v2/config" \
  -H "Content-Type: application/json" \
  -d '{\n    "evaluationQueueConfig": {\n      "enabled": true,\n      "producerPeriodInMilliseconds": 600000,\n      "producerMaxQueuedRows": 1000,\n      "cyclePeriodInMilliseconds": 86400000,\n      "resetCycleTimeout": false,\n      "consumerThreadsPerTenant": 1,\n      "consumerPeriodInMilliseconds": 300000,\n      "consumerMaxQueuedRows": 30,\n      "consumerRowExpirationInMilliseconds": 6000000,\n      "startTimeDelayEnabled": true\n    }\n  }'
```

## Version Evaluation Window

By default, continuous monitoring evaluates all SBOM versions.

You can restrict the evaluated versions by configuring a version evaluation window.

A version evaluation window allows you to limit evaluations by number of versions or by age.

### Configuration Properties

| Property | Description | Required |
| --- | --- | --- |
| `contextId` | Context where the window is applied | Yes |
| `maxVersions` | Maximum number of versions to evaluate starting from most recent | Optional* |
| `maxAgeInDays` | Maximum age of versions to evaluate | Optional* |

**Note**

Either `maxVersions` or `maxAgeInDays` must be set to define the evaluation window.

### cURL example

Use the API to configure a version evaluation window.

```
curl -u admin:admin123 \
  -X PUT "http://localhost:8070/api/v2/versionEvaluationWindow/organization/ROOT_ORGANIZATION_ID" \
  -H "Content-Type: application/json" \
  -d '{\n    "contextId": "compliance",\n    "maxVersions": 5,\n    "maxAgeInDays": 90\n  }'
```

## Tuning Recommendations

Continuous monitoring is configured with conservative defaults. If monitoring cycles do not complete within the expected duration, you can adjust configuration to improve throughput.

A monitoring cycle that does not complete within the configured `cyclePeriodInMilliseconds` may indicate that the current configuration or evaluation scope is too large.

To improve completion time, you can:

- Increase evaluation throughput by adjusting `consumerThreadsPerTenant` or `consumerMaxQueuedRows`
- Reduce evaluation scope by limiting the number of versions evaluated using a version evaluation window

### Key Parameters

The following parameters have the most impact on evaluation throughput:

- `consumerThreadsPerTenant`: Controls the number of parallel evaluation threads
- `consumerMaxQueuedRows`: Controls how many evaluations are processed per cycle

## Resource Impact per Consumer Thread

| Resource | Approximate Impact |
| --- | --- |
| CPU | <1% per core during evaluations |
| Memory | ~0.5 to 1 GB additional heap |

**Note**

Each instance runs its own consumer threads. Increasing thread count increases overall resource usage.

## Enabling Continuous Monitoring

Administrators may enable Continuous Monitoring from the Organizations view. We recommend setting the configuration at the Root Organization; however, this setting may be enabled at any level of the organization hierarchy.

1. Navigate to the **Organizations** view
2. From the center view, select the **Continuous monitoring** configuration
3. Toggle the button from Disabled to Enabled
4. Select **Update**

## Scheduling Continuous Monitoring

Continuous Monitoring starts at midnight for the hosting system. You can change the start time through the [Configuration REST API](https://help.sonatype.com/en/configuration-rest-api.html "Configuration REST API").