We have released the Risk Map feature

Enable tracking of hidden risks in one place

You can respond to incidents after they occur. However, “concerns that might eventually lead to an accident” tend to remain scattered across Slack threads, review comments, and the minds of the people involved—often left unaddressed because no one takes the time to take stock of them.

The Risk Map released in this update is a feature designed to centrally register and track these risks across various domains, including code, infrastructure, dependencies, business, and operations. You can access it from the "Risk Map" section in the sidebar.

Key Features

1. Risk Registration and Tracking

We structure and manage risks based on three criteria: “Category,” “Severity,” and “Status.”

- Categories (5 types) — Code / Infrastructure / Dependencies / Business / Operations

- Severity (5-level scale) — Critical / High / Medium / Low / Informational

- Status (6 types) — Open / Verified / In Progress / Resolved / Accepted / Duplicate

A key feature is the inclusion of an “Accepted” status . In risk management, it is important not to eliminate every risk , but rather to document that risks accepted as part of the decision-making process have been accepted.

The list view supports searching by title, location, and reporter, as well as filtering by status, severity, and category (multiple selections allowed), and sorting by each column.

2. Linking Incidents to CMDB Services

From the Risk Details screen, you can link existing incidents to services in the CMDB.

This allows users to trace back and forth between “What risks remain for this service?” and “Which past incidents form the basis for this risk?” From the linked incidents and services, users can navigate to their respective detail pages with a single click.

3. AI identifies potential risks based on past incidents

The biggest hurdle in risk management is “the process of identifying what constitutes a risk in the first place.”

The Risk Map now includes a feature that uses AI to analyze resolved incidents and suggest potential risks that have not yet been registered. When you select “Identify Potential Risks” from the list view, the system performs a cross-sectional analysis of the most recent resolved incidents (up to 100) and presents 3 to 10 potential risks.

In addition to the title, category, and severity level for each candidate, the system provides the rationale for why it was identified as a risk, along with the names of the actual incidents that served as the basis for that determination. You can review the details, select only the ones you need, and register them all at once. The output is available in both Japanese and English.

It is particularly effective at identifying patterns such as, “The same type of problem keeps recurring, but the root cause remains unaddressed.”

4. Automatic Risk Ticket Creation from CVE Scans

For CMDB services tech:<プロダクト名> If you configure the format tag, the scan results will be automatically cross-referenced with vulnerability information (CVE), and any matching vulnerabilities will beAutomatically registered as a risk in the "Dependencies" category...will be done.

- Severity is automatically determined based on the CVSS score (9.0 or higher is "Critical," 7.0 or higher is "High," 4.0 or higher is "Moderate," and 0.1 or higher is "Low").

- Risks related to the same product are consolidated into a single entry, and each time a new CVE is discovered, it is added to the list of related CVEs.

- The severity level will be raised only if a more serious CVE is detected later. Even if the team has rewritten the title or description, those changes will not be overwritten.

- Related CVEs are displayed with links to the NVD.

You can automatically add vulnerabilities in dependent packages to the risk register without manual intervention.

5. Recording the Change History

All changes to various items—including severity and status—as well as operations to link incidents to services are recorded in the audit log. On the "Change History" page of the risk details screen, you can view a timeline showing when, by whom, and what changes were made.

Since you can track “when the decision to accept this risk was made” retroactively, this information can also be used as documentation for audit purposes.

6. Operations via the Public API

The risk map also supports the Public API. This enables operations where risks can be automatically logged from external tools, such as CI/CD and security scanners.

| Operation | Endpoint |

| --- | --- |

| Get List | GET /v1/risks |

| Create | POST /v1/risks |

| Individual Acquisition | GET /v1/risks/{id} |

| Update | PATCH /v1/risks/{id} |

| Incident Linking | POST /v1/risks/{id}/link-incident |

About Permissions

Administrators and members can create, edit, delete, and link risks. Users with the "Viewer" role see a view-only screen; editing functions are not displayed.

Getting Started

1. Open "Risk Map" in the sidebar.

2. We recommend starting by performing the “Identify Potential Risks” step to identify potential risks based on past incidents.

3. Link the identified risks to the relevant CMDB services and incidents.

4. If you want to automatically detect vulnerabilities in dependencies, use the CMDB service to tech:<プロダクト名> Please set the tags