Risk register

A finding says what a scanner saw. A risk says what could go wrong for your business because of it, how likely and how bad that is, and what you are doing about it. The risk register keeps those risks for the whole workspace, links each one to the findings and assets that are its evidence, and records every assessment, decision and review along the way.

What it is for

• Keeping one list of the security risks your workspace carries, with an owner, a level and a next review date for each.
• Rating each risk on a 5x5 likelihood and impact matrix, before and after treatment, with a suggested rating worked out from the evidence.
• Accepting a risk formally, by the right person, for a limited time, instead of leaving a finding dismissed and forgotten.
• Seeing which of your vulnerable dependencies and web findings are being exploited in the wild right now.
• Handing an auditor a register in a standard layout.

How it works

Risks

Each risk gets a reference such as RISK-0001, numbered in the order risks are created in the workspace. It has a title, a scenario that describes what could happen, a category, an owner, a treatment, tags, and a status:

• Identified: raised, not yet assessed.
• Analysed: assessed at least once. A risk moves here on its first inherent assessment.
• Treatment planned and In treatment: work is planned or under way. Adding the first treatment action moves a new or analysed risk to Treatment planned.
• Accepted: formally accepted. A risk only reaches this status through acceptance.
• Monitored and Closed.

The categories are secret exposure, vulnerable dependency, code weakness, web application, exposed service, data protection, misconfiguration, access control, third party and other. The treatments are mitigate, accept, transfer and avoid.

Assessments and levels

An assessment rates likelihood and impact from 1 to 5. It is one of three kinds:

• Inherent: the risk as it stands with no treatment.
• Residual: what is left once the treatment is in place.
• Target: where you want it to be.

The score is likelihood times impact, and the level follows from the score: up to 3 is very low, up to 6 low, up to 12 moderate, up to 16 high, and anything above is very high. Assessments are never edited: a new one is added, and the latest of each kind is what the risk shows.

Suggested rating

When you assess a risk, Vulnara suggests a likelihood and an impact from its evidence, with the reasons, so you have somewhere to start. Using the suggestion only fills in the fields; nothing is saved until you save the assessment.

• Likelihood starts from the highest severity among the linked findings, and goes up when a linked finding is triaged as exploitable, when an asset is in production or is a web application or network, and when a linked CVE has an EPSS score of 0.1 or more. A CVE in the CISA Known Exploited Vulnerabilities catalogue sets it to 5.
• Impact starts from the highest business criticality of the linked assets, goes up for confidential or restricted data, and is at least 4 for secret exposure and data protection risks.

Evidence

Link findings to a risk from the finding drawer with Add to risk, for code, dependency and web application findings. A link uses the same match key as the finding's triage decision, so the risk shows that decision next to the finding, and it stays linked across rescans. You can also link a whole repository, git workspace, web application or network.

Business context of an asset

For each repository, git workspace, web application and network you can record its business criticality from 1 (negligible) to 5 (critical), its environment (production, staging, development or other), the classification of the data it handles (public, internal, confidential or restricted), and its owner. Open Business context from the asset's detail. A risk's detail lists the context of every asset its evidence links.

Business context feeds the suggested rating and weighs the security score: a finding on a critical asset costs more than the same finding on a negligible one. Saving it recalculates the asset's score straight away.

Treatment actions and reviews

A risk's treatment is tracked as actions, each with a description, an owner, a due date, a status and an optional link to an issue. Each level has a review interval. Recording a review sets the next review date from it.

Vulnara sends an event when a review falls due (risk.review_due), when a treatment action is overdue (risk.treatment_overdue), when an acceptance expires (risk.acceptance_expired), and when a triage decision lapses (triage.decision_expired). To receive them, add them to an alert rule through the API, by name or all at once with category:findings. The rule form in the web app does not list them yet.

Acceptance

A risk whose treatment is accept can be accepted, with an optional expiry and conditions. The level that counts is the residual level, or the inherent level when there is no residual assessment. Each level has its own criteria:

• Very low and low: an editor can accept, for up to 365 days.
• Moderate: an editor can accept, for up to 180 days.
• High: an admin must accept, for up to 90 days.
• Very high: an admin must accept, for up to 30 days.

These are the defaults. An admin can change them on the Acceptance criteria tab, and can also require that the person who accepts a risk is not the person who raised it. Without an expiry, an acceptance lasts for the level's review interval.

Acceptance is refused, with the reason, when the treatment is not accept, the risk has no owner, it has never been assessed, your role is below the level's, the expiry is later than the level allows or in the past, or you raised the risk and a different acceptor is required.

When an acceptance expires, the risk goes back to Analysed and a notification is sent. Revoking an acceptance does the same straight away.

Will not fix needs an accepted risk

An admin can turn on Require an accepted risk for will not fix on the Acceptance criteria tab. A Will not fix decision on a finding is then refused unless an accepted risk links that finding, and its review date cannot be later than the acceptance's expiry. The triage dialog says which of the two was the problem. See Triage findings.

Triage exceptions

The Exceptions tab lists every Will not fix and Defer decision in force across the workspace, with who made it, why and when it expires. Narrow it to the ones expiring within 30 days to see what is about to come back. A decision whose review date passes is removed, and the finding returns to the open list.

Actively exploited findings

Vulnara pulls the CISA Known Exploited Vulnerabilities catalogue (KEV) and the FIRST EPSS scores once a day. The Actively exploited tab lists the dependency findings of each repository's latest scan, and the web application findings of each web application's latest scan, whose CVE is in KEV or has an EPSS score at or above the threshold you pick. KEV findings come first, then the highest EPSS.

Each row shows the CVE, linked to its NVD page, whether it is in KEV with CISA's dates and ransomware marker, the EPSS probability and percentile, the package with its installed and fixed versions, the asset, the severity and the triage decision. Add to risk links the row to a risk. The tab also says when the feeds were last synced.

The register's summary shows how many findings are in KEV, and links to the tab.

Risks drafted for newly exploited findings

When a finding's CVE joins KEV, Vulnara drafts a risk for it, so it reaches the register without anyone having to notice. It checks after every successful scan and every feed update, and looks at the open findings of the latest scans that carry no triage decision.

• The draft is in status Identified, created by vulnara, tagged kev and auto-drafted, and marked Auto-drafted in the register.
• Its title names the CVE, the package and the asset. Its scenario says the CVE is in KEV, whether it is used in ransomware, the fixed version and CISA's due date.
• The finding is linked, and the asset's owner from its business context becomes the risk's owner.
• A person then assesses, treats and, if it comes to that, accepts it. Nothing is assessed or accepted automatically.

Each finding is handled once. A draft you delete is not drafted again, and a finding with a triage decision is left alone. Each run also sends one finding.exploited event with the number of findings, their CVEs and the references of the drafted risks; route it with an alert rule as above.

Drafting is on by default. An admin can turn off Draft a risk when a finding becomes actively exploited on the Acceptance criteria tab. With it off, the finding.exploited event is still sent.

What you can see on the register

• Summary: open risks, reviews overdue, acceptances expiring within 30 days, overdue treatment actions and actively exploited findings.
• Heat map: the number of risks in each likelihood and impact cell, residual or inherent.
• Register: the risks with their reference, title, category, owner, inherent and residual level, treatment, status, next review and number of links, filtered by status, level, treatment, category, text, and review overdue.
• Export: a CSV of the register in the layout of NIST IR 8286A, named risk-register-<date>.csv.

Do it

Raise a risk from a finding

1. Open the finding in Vulnerabilities and choose Add to risk.
2. Pick an existing risk, or create a new one. A new risk starts with a category that matches the finding.
3. Open the risk in Risk register, add an inherent assessment, starting from the suggestion if it fits, and set an owner and a treatment.

Accept a risk

1. Set the risk's treatment to accept and make sure it has an owner and an assessment.
2. Choose Accept, and optionally set an expiry and conditions.
3. If the acceptance is refused, the dialog says why.

Do the same through the API

• GraphQL: risks, risk, riskSummary, riskRegisterExport, triageExceptions, exploitedFindings, assetContext and riskSettings to read; createRisk, updateRisk, assessRisk, linkRisk, addRiskAction, reviewRisk, acceptRisk, revokeRiskAcceptance, saveAssetContext and saveRiskSettings to change.
• MCP: every read above, plus create_risk, update_risk, assess_risk, link_risk, add_risk_action, update_risk_action, review_risk and save_asset_context for members whose AI access is Write. An assistant cannot accept, revoke or delete a risk, or change the acceptance criteria.
• GitHub Action: fail a build on actively exploited findings with fail-on-exploited. See GitHub Action.

Good to know

• Reading the register needs only the viewer role. Raising, assessing, linking and treating risks, and recording business context, need the editor role. Deleting a risk and changing the acceptance criteria need the admin role. See Teams and roles.
• Setting a risk's status to Accepted directly is refused. Use Accept, so the criteria are checked and the approver is recorded.
• Every change to a risk is added to its history with who made it and when. Nothing in the history is edited or deleted.
• The same finding can be linked to a risk only once.
• When the threat feeds have never been synced, the Actively exploited tab says so instead of showing an empty list that looks clean.