Vulnerabilities & Risk Troubleshooting & FAQ

Triage and findings

The Triage queue is empty (or every count is zero) even though scans found things. Triage reads the unified findings lake, which is filled by the vulnerability sync (every 2 hours) and scored by the Triage Engine (daily). Right after onboarding, or after a burst of scans, click Sync All Sources on the Raw findings tab, then Score on the Triage tab (or POST /api/vulnerabilities/sync followed by POST /api/triage/score). The summary should show scored counts within a minute.

A finding I resolved came back as open. Only findings the platform closed automatically — because a scan stopped reporting them — reopen when a later scan reports them again. Your own decisions (false positive, accepted risk, a manual resolved) are preserved across syncs, including a forced resync. If an accepted risk reopened on its own, check its review date: acceptances and suppressions expire on the date you set (checked daily at 01:15 UTC) so that an acceptance is a decision with an end. Re-accept with a new date if the reasoning still holds.

The Action queue shows P1 for something that is clearly not urgent. Open the finding and read the score breakdown: P1 is usually forced by an override — internet-exposed and exploitable (KEV / high EPSS) on a production asset, or an active detection. If the exposure or environment is wrong, fix the asset's business context (see below) and the next re-score will move it. If the finding is genuinely not a risk, Accept Risk or Mark FP with a reason; the decision applies to the whole work item across resources.

Raw findings shows the same CVE many times. That is by design: the grouped view is one row per vulnerability with an affected-asset count; the occurrence list is one row per vulnerability per asset, because that is the unit SLAs, assignments and tickets attach to. Work from the grouped view or the Triage work item to act on all of them at once.

A container / cloud finding disappeared from Vulnerability Management but the module still shows it. The lake is 2 hours behind the module at most. Sync All Sources catches it up immediately. If it is still missing after a sync, the module finding is no longer in a failing / open state, or its asset was removed — resolved and deleted-asset occurrences are closed by the sync's reconciler; check the finding's status in its module and the asset in Asset Inventory.

SLA

Occurrences show no SLA due date. No policy matched. The default policies only match production environment, and an asset with no business context is treated as development / medium criticality — so a fresh installation matches nothing until you either add a policy without an environment condition (leave environments empty to match all) or set business context on your assets. Business context is set over the API today: PUT /api/assets/{asset_id}/business-context with environment (production · staging · development · qa · dr), criticality (critical · high · medium · low), data_classification and owner, or POST /api/assets/business-context/bulk for many at once. SLAs are attached when the occurrence is next synced.

Two policies match; which one applies? The one with the highest priority. Give your narrow policies (critical assets, PCI scope) a higher number than the broad defaults.

Nothing breaches / nobody is notified. Breach checks run every 15 minutes; Check Breaches on the SLA page runs one now. A breach notifies once (it is marked as notified) and escalation rules fire at their own offsets, so a policy with no escalation rules produces exactly one notification. Make sure the notification channel it targets is configured and its minimum severity is not filtering the alert out — see Alerts and notifications.

Changing a policy did not change existing due dates. Policies are applied when an occurrence is created or re-synced. Run Sync All Sources with force resync (POST /api/vulnerabilities/sync?force_resync=true) to re-evaluate existing occurrences; triage decisions survive the resync.

Alerts

An alert I resolved reappeared as new. Its condition happened again. Alerts are deduplicated on a key, so a recurrence of a resolved or closed alert reactivates the same record — with the count incremented and the history intact — rather than creating a duplicate. A recurrence is only counted when it is genuinely newer than the last one, so an old failure being re-read by a sync will not reopen it. Fix the cause (the failing scan, the expired credential) and resolve it again.

Too many alerts. Filter by category and severity and use Acknowledge All on the filtered set; bulk action resolves or closes what you have chosen. Then raise the channel's minimum severity (default high) so the bell and Slack / email only carry what needs a human. Scan and credential failures are best fixed at the source — a paused cloud account or an expired token produces an alert on every attempt.

The bell shows a count but no channel message arrived. The in-app bell and external channels are separate: a channel receives the alert only if it is enabled, its minimum severity is met, and the integration's test succeeds. Check Integrations → Notifications and send a test.

Risk register

The register filled with dozens of Security Vulnerability risks I did not create. That is the automatic import: after each sync, open high and critical findings that are not yet linked to a risk are minted as risks (one per vulnerability, deduplicated) and linked back. Use the by category view to work with them as a group; POST /api/risk-management/risks/merge-duplicates folds an earlier manual risk that covers the same vulnerability into one record. Re-running Import from Findings is safe — already-linked findings are skipped.

Residual risk equals inherent risk although controls are linked. The controls have not been tested. An untested (or ineffective) control contributes zero reduction; partially effective counts half, effective counts fully. Record Test on each control, then look at Inherent vs Residual on the Dashboard.

A treatment plan cannot be submitted for approval. Only draft and rejected plans can be submitted. If it is already pending, an approver has it under Pending Approvals on the Dashboard; if it is approved or completed, there is nothing to submit.

The heat map does not show a risk. The heat map plots business risks (likelihood × impact). System risks (magnitude 0–100) appear in the register and the dashboard trend, not on the 5 × 5 grid.

Bulk import mapped the columns wrongly. Download the template and match its headers, or correct the mapping in the review step before Import — the suggested mapping is a header match, not a commitment. Import creates new risks; it does not update existing ones by ID.

Frequently asked questions

How is the risk score in Triage different from the risk register's score? The Triage score (0–100, P1–P4) is computed per finding from severity, exploitability, exposure, environment and detections — it decides what to fix first. A register risk's score (likelihood × impact or magnitude) is a business assessment, owned by a person — it decides what to tell the board. Importing a finding as a risk links the two; it does not copy the number.

Do triage decisions affect compliance? A finding marked false positive or accepted risk stops counting against SLAs and the Triage queue; it still exists, with its reason and expiry, for auditors. Compliance controls read the underlying scan results and are not changed by a triage decision.

Can I export everything? Occurrences and findings over the API (GET /api/vulnerabilities/occurrences, GET /api/vulnerabilities/findings); the register via Export or GET /api/risk-management/reports/export; the SLA breach list via GET /api/sla/breaches. Scheduled and executive reports live under Reports & AI.

Where do findings come from in the first place? Every scanner in the platform — cloud posture, Kubernetes, container images, SBOM/SCA, SAST, secrets, IaC, DAST, host — plus imported third-party results. See Vulnerability Management for the source table.

Still stuck?

The platform-wide Troubleshooting page covers login, workers and deployment. When contacting support include the finding fingerprint or occurrence ID, the sync status (GET /api/vulnerabilities/sync/status) and, for SLA questions, the policy name and the asset's business context.