05.03 The Vulnerability Management Extra

Requires: Vulnerability Management Extra

Native scanner ingestion, the Triage Vulnerabilities queue, and the auto-conversion of scanner findings to SimpleRisk risks all live in the Vulnerability Management Extra. Core SimpleRisk has no native vulnerability tracking — see Recording a Vulnerability for the Core-only workarounds.

Why this matters

The Vulnerability Management Extra is the surface that turns SimpleRisk from "a risk register that can also hold vulnerability-shaped risks" into "a vulnerability management platform that produces risks as a byproduct." Once activated, the Extra ingests scanner data on a configurable cron schedule, presents the findings in a triage queue, and lets reviewers promote the findings worth promoting — with the promoted findings landing in the standard risk register automatically. The bookkeeping the Core path required (per-finding subject formatting, CVSS calculator entry, asset linkage, tagging) drops to two clicks per finding.

The Extra also exists to scale. A program with one scanner producing 50 findings per month can manage on the Core path; a program with three scanners producing thousands per month can't. The Extra's per-platform tables (vulnmgmt_ _vulnerabilities) hold the per-finding detail without polluting the risk register, and the triage step is what enforces the discipline of not promoting every finding to a risk. The volume problem is what the Extra solves.

The other reason this matters: the Extra is the integration point with the scanners customers already operate. SimpleRisk doesn't try to be a scanner; it integrates with the scanners that are scanners. If your environment already runs Qualys, Rapid7, or Tenable, the Extra meets your data where it already lives rather than asking the program to switch tools.

Before you start

Have these in hand before activating the Extra:

Admin access to your SimpleRisk installation, plus the relevant Vulnerability Management permissions for the actions you'll take: Allow Access to Vulnerability Management "Configure" Menu for setup, Allow Access to Vulnerability Management "Vulnerabilities" Menu for the triage queue, Able to Approve Vulnerability Triage to Risk to promote findings, Able to Reject Vulnerability Triage to Risk to dismiss findings. The four permissions are separate so that scanner configuration (sensitive: holds API credentials) is gated separately from triage work (operational: routine review). (See Permission Reference.)
An active subscription for the Extra and a registered SimpleRisk install. The Extra is a paid add-on; activation requires the installation to be registered and the Extra to be licensed.
Scanner platform credentials. The Extra supports five platforms: Qualys, Rapid7 InsightVM Cloud, Rapid7 InsightVM On-Premise, Rapid7 Nexpose, and Tenable.io. For each platform you'll integrate, gather the API URL and the API key (or username/password depending on the platform). The credentials are stored encrypted in the SimpleRisk database.
Network connectivity from the SimpleRisk server to the scanner's API endpoint. Cloud scanners (Qualys, Tenable.io, Rapid7 InsightVM Cloud) need outbound HTTPS to the vendor's cloud; on-premise scanners (Rapid7 InsightVM, Nexpose) need network reachability between the SimpleRisk server and the scanner appliance. Air-gapped or heavily-firewalled environments may need additional plumbing.
A read on your scanner site / scope structure. Most scanners organize work by "site" or "scope" — a named bundle of assets to scan. The Extra picks up data per-site; decide which sites you want SimpleRisk to consume before running the configuration.

Step-by-step

1. Activate the Extra

Sidebar: Configure → Extras opens the Extras administration page. Find Vulnerability Management Extra in the list and click Activate. The activation:

Sets the extra_vulnmgmt configuration setting to true.
Creates the platform-specific tables (vulnmgmt_ _vulnerabilities, vulnmgmt_ _vulnerabilities_to_assets, vulnmgmt_ _categories, vulnmgmt_ _vulnerabilities_to_categories) for each supported platform — the schema is created at activation, populated when you configure the platform.
Adds two sidebar entries: Vulnerabilities and Vulnerabilities → Configure.

2. Pick the scanner platform(s) to integrate

Sidebar: Vulnerabilities → Configure opens /vulnerabilities/configure.php. The first tab is the platform-selection step. The form shows a checkbox list of supported platforms:

Qualys
Rapid7 InsightVM Cloud
Rapid7 InsightVM On-Premise
Rapid7 Nexpose
Tenable.io

Check the platforms you'll integrate and save. Each enabled platform writes a extra_vulnmgmt_ configuration setting (e.g., extra_vulnmgmt_tenable) that gates the platform's UI and data flow.

You can enable multiple platforms simultaneously — programs running multiple scanners (e.g., Tenable for infrastructure scanning, Qualys for web-app scanning) integrate both, and the triage queue surfaces findings from all enabled platforms together with the source labeled.

3. Configure platform connectivity

For each enabled platform, open its connectivity tab and fill in:

API URL — the scanner's API endpoint. For cloud scanners, this is the vendor's published cloud URL (e.g., https://cloud.tenable.com for Tenable.io). For on-premise scanners, it's the URL of your scanner appliance.
API credentials — the username/password or API key combination the platform requires. The credentials are stored encrypted in the SimpleRisk database.
SSL Certificate Check (optional) — controlled by extra_vulnmgmt_ssl_certificate_check. When enabled, the Extra validates the scanner's TLS certificate; when disabled, it accepts self-signed or otherwise unverifiable certificates. Enable for cloud scanners and properly-certified internal scanners; disable only for development/testing environments where TLS isn't fully configured.

Click Test Connection to verify the credentials work; the Extra makes a probe API call and reports success or failure.

4. Pick the sites/scopes to import

Once the platform connection is verified, the next configuration tab lets you pick which sites or scopes SimpleRisk should consume. The Extra calls the scanner's API to enumerate available sites; pick the ones you want vulnerability data from.

For programs running many sites in their scanner, picking only the sites that matter to SimpleRisk's audience reduces noise and improves sync performance. Sites you don't pick stay in the scanner's own console; SimpleRisk just doesn't receive their data.

5. Set the import and triage thresholds

The Import/Triage Settings tab controls what the Extra ingests and what it auto-promotes. The relevant configuration settings:

extra_vulnmgmt_import_assets — when on, the Extra creates SimpleRisk asset records for the assets the scanner has discovered (so the asset linkage on imported vulnerabilities resolves to real asset rows). When off, scanner-discovered assets aren't created and the asset linkage is incomplete. Most programs leave this on.
extra_vulnmgmt_import_vulnerabilities_by_score + extra_vulnmgmt_import_vulnerabilities_by_score_value — the import-side filter. When the toggle is on, only vulnerabilities with CVSS scores at or above the configured threshold are ingested. Useful for high-volume scanners where you don't want every Low and Informational finding cluttering the database. The threshold is a CVSS score from 0.0 to 10.0; common values are 4.0 (Medium and above) or 7.0 (High and above).
extra_vulnmgmt_triage_vulnerabilities_by_score + extra_vulnmgmt_triage_vulnerabilities_by_score_value — the auto-triage-side filter. When the toggle is on, vulnerabilities at or above the configured threshold are automatically converted to risks during the import cycle, without human review. Common value: 9.0 (Critical only). Setting this lower than 9.0 is risky; the auto-promotion produces risks the team didn't review, and at low thresholds it can flood the risk register.

The two thresholds work together: import filters what enters SimpleRisk at all; auto-triage filters what gets immediately promoted. A typical setup is "import everything CVSS 4.0+, auto-triage CVSS 9.0+, manually triage everything in between."

6. Set up the cron schedule

The Extra runs scanner syncs on a cron schedule controlled by:

extra_vulnmgmt_cron_auto — when on, the Extra polls the scanner on the configured schedule. When off, syncs only happen when a user clicks the manual update trigger.
extra_vulnmgmt_cron_schedule — the cron expression for the auto-sync. Defaults vary by install; common cadences are hourly for large environments and daily for smaller ones.

The cron requires the SimpleRisk job runner to be running (see the Administrator Guide for cron setup). When the cron isn't running, automatic syncs don't happen; the symptom is "no new vulnerabilities are appearing" which can look benign but isn't.

For manual sync (useful for testing the connection or pulling data on demand) the Extra exposes GET /api/v2/vulnmgmt/update/all, which triggers a full sync across all enabled platforms.

7. Triage the queue

Sidebar: Vulnerabilities → Triage Vulnerabilities opens /vulnerabilities/index.php. The page shows a deduplicated list of pending vulnerabilities — same-title findings across multiple assets are grouped, with the highest CVSS score per group surfaced and the affected-asset count shown alongside. For each row:

Approve Selected Vulnerabilities promotes the finding to a SimpleRisk risk (full mechanics in From Vulnerability to Risk).
Reject Selected Vulnerabilities hides the finding from the queue without deleting it from the underlying vulnerability table. Hidden findings stay in the database for audit-trail purposes; rejecting doesn't delete the per-asset detail in case the finding becomes relevant later.

Bulk-select multiple findings via the row checkboxes and use the bulk approve/reject buttons; the actions are atomic per selection.

The triage queue is the operational workspace; reviewing it on a recurring cadence (weekly is typical for active programs) keeps the queue from accumulating into a backlog nobody reads.

8. Programmatic operation via the v2 API

The Extra exposes several v2 API endpoints for automation and integration:

GET /api/v2/vulnmgmt/version — fetch the Extra version.
GET /api/v2/vulnmgmt/activate — activate the Extra (admin only).
GET /api/v2/vulnmgmt/update/all — trigger a manual full sync across all enabled platforms.
POST /api/v2/vulnmgmt/vulnerability/triage/add — approve and convert vulnerabilities to risks. Body specifies the vulnerability IDs and the platform.
POST /api/v2/vulnmgmt/vulnerability/triage/remove — reject vulnerabilities (sets the hidden flag).
Per-platform variants such as POST /api/v2/vulnmgmt/vulnerability/triage/tenable/add for platform-scoped operations.

The most common automation pattern is a script that pulls the triage queue (via direct database query or a list endpoint), filters to the team's auto-triage rules (e.g., "auto-approve everything with kev:true from the CISA Known Exploited Vulnerabilities catalog"), and posts approvals via the API.

Common pitfalls

A handful of patterns recur with the Extra.

Auto-triage threshold too low. Setting extra_vulnmgmt_triage_vulnerabilities_by_score_value to 6.0 or 7.0 produces a risk register dominated by routine Medium- and High-severity findings the team would have rejected on manual review. Set the auto-triage high (9.0+) so the auto-promoted findings are unambiguously the worst-of-the-worst; leave the rest for human review.
Import threshold too low or off. Importing every CVSS 0.0+ Informational finding produces a vulnerability database with thousands of low-value rows that slow down the queue rendering and obscure the meaningful findings. For high-volume scanners, set the import threshold at CVSS 4.0+ (Medium and above) or higher; the suppressed findings stay in the scanner's own console where they belong.
Triage queue that never gets worked. A growing queue with no reviewers actively triaging produces a backlog where the operationally-significant findings get buried in routine ones. Schedule a recurring triage session (weekly is reasonable); the discipline of clearing the queue is what makes the Extra useful rather than just a data-collection layer.
Configured-and-forgotten scanner integrations. Scanner credentials expire. API endpoints change. Site definitions get reorganized. When a scanner sync starts failing, the symptom is silence (no new vulnerabilities appearing) which can look like good news. Watch the vulnmgmt_log for sync failures; failed syncs are an incident that hides itself if not surfaced.
Disabling SSL certificate check in production. Setting extra_vulnmgmt_ssl_certificate_check to off accepts whatever TLS certificate the scanner presents, including invalid or attacker-substituted ones. The setting exists for development and testing; turning it off in production is a security regression. If your scanner has a self-signed cert in production, fix the cert.
Treating reject as delete. Rejecting a vulnerability hides it from the triage queue; it doesn't delete the underlying record. The next sync from the scanner will not re-surface a hidden vulnerability (the hidden flag persists), but the vulnerability detail (the affected assets, the CVSS, the descriptions) stays in the database for audit-trail purposes. Reject confidently; the action is recoverable if you later realize the finding deserved attention.
Letting the auto-triage produce risks the team doesn't notice. Auto-promoted risks land in the risk register without a human-decision moment. A program with auto-triage on at 9.0+ will produce 9.0+ risks the team only notices when the next risk dashboard review happens. For programs that need a human-decision moment on every promotion, leave auto-triage off and rely on the manual triage queue.
Ignoring the deduplication. The triage queue groups same-title findings across assets to keep the queue readable. The single triage decision applies to all the underlying per-asset findings; approving the grouped row creates one risk that links to all the affected assets. Programs sometimes expect per-asset triage decisions; the Extra deliberately doesn't work that way (the deduplication is what keeps the queue navigable). If you genuinely need per-asset granularity, the promoted risk's asset linkage will carry it; the triage decision is at the title level.
Skipping the asset import. Turning extra_vulnmgmt_import_assets off leaves vulnerability records with asset references that don't resolve to SimpleRisk asset rows. The asset-linkage on the promoted risks is then incomplete, and asset-by-risk reporting won't surface vulnerability-derived risks against the correct assets. Most programs should leave this setting on.
Multiple scanners producing duplicate findings without coordination. Running Tenable and Qualys against the same environment will surface most of the same vulnerabilities through both pipelines, with slightly different CVSS scores and descriptions. The Extra doesn't cross-deduplicate across platforms; both findings will appear in the triage queue. The fix is operational: pick one scanner as the primary source for each population of assets and limit the other scanners to populations the primary doesn't cover.