05.02 Recording a Vulnerability

Why this matters

The honest answer to "how do I record a vulnerability in Core SimpleRisk?" is: through the standard risk register, with conventions. Core SimpleRisk doesn't have a native vulnerability-tracking surface — no Vulnerabilities page, no scanner integrations, no CVE field, no automatic CVSS calculator on a vulnerability record. The vulnerability-management workflow is gated to the Vulnerability Management Extra, and the Extra is the right answer for any program with meaningful scanner volume.

That said, plenty of small Core installations do track a small number of vulnerabilities directly in the risk register. The pattern works for low-volume vulnerability programs (dozens of findings, not thousands) where the per-finding overhead of risk-register submission is acceptable. This article walks the conventions that make the pattern usable, and the signals that tell you it's time to install the Extra instead.

The other reason this article exists: the migration story matters. A program that starts on Core with vulnerabilities-as-risks may later install the Extra and want to know how the existing risks reconcile with the new triage queue. The short answer is they don't reconcile automatically — vulnerabilities created via the Extra after activation get auto-converted to new risks; pre-existing risks tracking vulnerabilities stay as they are. Plan the cutover deliberately rather than expecting a magical merge.

Before you start

Have these in hand before recording vulnerabilities in Core:

The Able to Submit New Risks permission on your account. The Core path uses the standard risk-submission form. (See Permission Reference.)
An honest read on your scanner output volume. If your scanner produces more than ~50 findings per month that need tracking, the per-finding overhead of the risk-register path will eat the team's time and produce a register too noisy to read. Install the Extra instead; this article's path is for genuinely low-volume programs.
The CVSS scoring methodology selected as the per-risk methodology for vulnerability submissions. CVSS is one of SimpleRisk's six built-in methodologies (see Risk Scoring Methodologies) and is the right fit for vulnerability scoring because the upstream CVSS scores published in the National Vulnerability Database are already defensible.
A documented internal convention for what to record. Recording every scanner finding in the risk register doesn't scale; the discipline is to record only the findings that genuinely need risk-register treatment (significant residual exposure, accepted-risk decisions, mitigation plans that need cross-team coordination).

Step-by-step

Path A: Record a vulnerability via the standard risk-submission form (Core)

This is the Core-only path. Each vulnerability becomes its own risk record.

Open the Submit Risk form. Sidebar: Risk Management → Submit Risk opens /management/index.php. The full walk-through of the form is in Submitting a Risk; the conventions below are the vulnerability-specific tweaks on top of that.
Set the Subject to the vulnerability identifier and a brief description. A useful pattern: CVE-2024-12345 — Apache HTTP Server SSRF — Production Web Tier. The CVE number anchors the vulnerability for cross-referencing; the brief description scans well on dashboards; the affected scope (Production Web Tier) tells the reader where the exposure lives.
Pick Vulnerability Scanner from the Risk Source dropdown (or whichever value your install uses for "this came from a scanner"). The Risk Source field doesn't affect downstream behavior, but it lets you filter risks by source later — useful for splitting "vulnerability-derived risks" from "audit-derived risks" or "incident-derived risks" in reporting.
Set the Risk Scoring Method to CVSS. The CVSS calculator opens with the Base Metrics, Temporal Metrics, and Environmental Metrics fields from the official CVSS standard. Either fill in the metrics from the scanner's published CVSS vector, or use the upstream NVD CVSS score as a starting point and adjust the Environmental Metrics for your context (see Risk Scoring Methodologies).
Link the affected assets. Use the Affected Assets widget to link the risk to the specific systems with the vulnerability (see Tying Risks to Assets). The asset linkage is what makes "show me everything affecting our PCI-scope systems" filterable later.
Tag the risk for filtering. Add a vulnerability tag (and optionally a per-scanner tag like qualys or tenable) so vulnerability-derived risks are filterable as a population. Tags are free text and can be created on the fly.
Set the Risk Assessment to a one-paragraph summary. What the vulnerability is, what an attacker could do with it, and why it matters in your environment. The Risk Assessment field is the abstract; the Subject is the headline.
Save. The risk lands in the standard register and flows through the standard review-and-mitigation workflow.

Path B: Use the Vulnerability Management Extra for scanner-driven workflows

If your scanner volume is meaningful, the Extra is the right answer rather than this article's manual path. Activating the Extra adds a /vulnerabilities/index.php page with a triage queue that ingests scanner data automatically; the per-finding overhead drops to "click Approve" or "click Reject."

The full walk-through is in The Vulnerability Management Extra. The signals that justify the switch:

Scanner output volume above ~50 findings per month.
More than one scanner in use (managing multiple scanners through the manual path becomes untenable fast).
A regulatory requirement that mandates scanner-derived vulnerability tracking with timestamps and remediation evidence.
An auditor asking for a vulnerability register that's distinct from the risk register.

Path C: Record a vulnerability you don't intend to promote

Not every vulnerability needs a risk-register entry. A scanner finding the team will patch in the next maintenance window, with no risk-acceptance decision and no mitigation plan beyond "patch it," doesn't add anything to the risk register that wouldn't be cleaner to track in the scanner's own console.

For this case, the right SimpleRisk action is no action — let the patch process handle it, and reserve the risk register for the findings that genuinely need risk-management treatment. The discipline of not recording every vulnerability as a risk is what keeps the risk register readable.

The exception: if the scanner doesn't have a remediation-tracking surface and you need something to track the patch through, the standard SimpleRisk pattern is to record a single risk per recurring batch ("Q3 2026 Patch Cycle") with a mitigation plan covering the batch as a whole, rather than per-finding.

Common pitfalls

A handful of patterns recur when teams use the Core path for vulnerabilities.

Recording every scanner finding as a risk. This is the most common Core-path failure. A program with 800 scanner findings per month and a policy of "every finding gets a risk-register entry" produces a register where 95% of the entries are routine vulnerabilities the patch process will close without any risk-management work. The register becomes unreadable and the auditor's "show us your top risks" question can't be answered. Restrict risk-register entries to vulnerabilities that genuinely need risk-management treatment.
Skipping the CVSS Environmental metrics. Using the upstream NVD CVSS Base Score as the risk's score, without adjusting for the Environmental metrics that represent your specific context, produces scores that are accurate in the abstract and wrong in your environment. A CVSS 9.8 on an internet-isolated system isn't operationally a 9.8 in your environment. The Environmental metric group exists for exactly this case; SimpleRisk's CVSS calculator exposes the fields.
No standard tagging convention. Recording a hundred vulnerability-derived risks without a vulnerability tag (or worse, with an inconsistent set of tags — vuln, vulnerability, cve, scan-finding) produces a register where the vulnerability subset isn't filterable. Pick a convention before you start; write it down so the second person doing this follows the same pattern as the first.
Treating the manual Core path as a permanent solution at scale. The manual path scales until it doesn't. A program that grows from 30 vulnerabilities per month to 300 per month under the same Core-only path will spend an increasing fraction of risk-management time on per-vulnerability submission overhead. Watch the volume; install the Extra when the per-finding overhead exceeds the per-finding value.
Trying to retrofit Core-recorded vulnerabilities into the Extra after activation. Activating the Extra doesn't touch existing risks; the new triage queue starts fresh from the next scanner sync. Pre-existing Core-recorded vulnerability risks stay in the risk register as they are. Plan the migration: either retire the Core-recorded entries (they're now duplicates of what the Extra will produce on the next sync), or accept them as a one-time legacy population that gets worked through normally while the Extra handles new findings.
Confusing the CVSS score with the residual risk score. A CVSS 9.8 vulnerability with a strong compensating control (the affected service is firewalled off from any attacker who can reach it) doesn't have a residual risk of 9.8. The CVSS score describes the vulnerability's severity in the abstract; the residual risk is what's left after your controls. Record the mitigation plan and the residual percent; let the residual-risk calculation reflect the actual exposure rather than the headline CVSS.
Not linking the affected assets. A vulnerability risk that doesn't link to the specific assets with the vulnerability is missing the most important context ("which systems does this affect?") and the asset-by-risk reporting won't surface it. Always link to the affected assets; if the asset isn't yet in the inventory, add it (see Managing Assets in SimpleRisk).
Treating "patched" as the close criterion without a rescan. Closing a vulnerability risk with a comment of "patch applied" but no rescan to confirm the finding is gone produces an evidence trail the auditor can't verify. Wait for the next scan; close the risk only when the scanner confirms the finding has dropped off.