CVERiskPilot feature reference

The dashboard adapts to your role, with views for analysts, GRC leads, owners and auditors. They show queue health, critical and high exposure, per-framework compliance posture, recent activity and KPIs. Posture-trend charts fill in once posture history is recorded, which is planned.

A chronological feed of the latest actions across your organization: scan uploads, triage decisions, case status changes, report generation, and integration events. Each entry links directly to the relevant resource.

Shortcut buttons for the most common workflows: upload a new scan, view untriaged findings, generate an executive report, and open the compliance posture view. These adapt based on your RBAC role — Viewers see report and dashboard links only.

The findings table supports filtering by severity (Critical, High, Medium, Low, Info), case status, scanner, KEV listing and EPSS threshold, plus text search. Filters compose — applying multiple narrows the result set with AND logic. Sort by discovery date or scanner. Pagination handles large result sets without performance degradation.

Selecting a finding opens the detail panel with full context:

Select multiple findings using checkboxes to perform batch operations: assign to a team member, change status, or export the selection as CSV. Bulk actions respect RBAC — Viewer and Auditor roles cannot modify finding state.

After findings are parsed and enriched, users can invoke AI-assisted triage and remediation paths. The triage context considers CVSS base and temporal scores, EPSS exploitation probability, KEV catalog status, asset criticality and environment (production vs. staging), network reachability, and the compliance frameworks active for your organization. External AI calls run behind redaction, and Claude and NIM calls also pass a daily spend cap. The output is a priority level, a recommended action, and a confidence score.

Every triage decision includes a confidence score between 0 and 1. Your organization can configure an auto-approve threshold in Settings (default: 0.90), but automatic approval remains release-gated. It only applies after the gate is enabled and only for explicitly allowed low-risk actions. All other decisions are flagged for manual review.

Any Analyst, Admin, or Owner can override an AI triage decision from the finding detail view. Select a new priority level and action, then provide a justification. Overrides are recorded in the audit log with the original AI recommendation preserved for compliance evidence.

Configure triage behavior under Settings:

Cases move from New and Triage through In Remediation and Fix Pending (fix applied, awaiting verification) to Closed, or are set aside as Accepted Risk, Deferred, False Positive, N/A or Duplicate; a closed case can be Reopened. Status changes made on a case's page are logged in the audit trail.

Cases can be assigned to any team member with Analyst, Admin, or Owner role. The assignee receives email and in-app notifications. Unassigned cases appear in the team queue. Ownership can be transferred at any stage.

AI triage records a recommendation on the case; it never changes a case's status or closes it on its own. To record a risk acceptance, false-positive or not-applicable decision with its justification, file a risk exception; when an Owner or Admin approves it, the case moves to that status. No AI confidence score can approve an exception.

Each case has a threaded comment stream for team discussion. Comments support plain text and are timestamped with the author. Use comments to document investigation findings, remediation steps, and approval rationale.

Direct file attachments on cases are not available yet. Compliance evidence records can reference a file you store elsewhere (a screenshot, configuration export or scan diff) by URL, name, size and SHA-256 hash.

Each finding is mapped to compliance controls through a CWE-based bridge. When a finding carries a CWE (from the scanner, or written as CWE-NNN in its title or description), the platform maps it to NIST 800-53 and from there to the other frameworks; a finding without a CWE maps to no control yet. For example, a SQL injection finding (CWE-89) maps to NIST 800-53 SI-10 (Information Input Validation) and SA-11, and through SI-10 to SOC 2 CC6.8, PCI DSS Req-6.2, and OWASP ASVS V5.1. The compliance detail view shows exactly which controls are threatened by open findings.

The compliance posture score is a weighted percentage reflecting how well your organization's current vulnerability state aligns with each framework's control requirements. The score reflects open and closed cases, open critical, high and KEV-listed cases, SLA compliance, average remediation time and scan frequency, plus whether SLA policies, risk exceptions, audit logging and integrations are in use. Scores are computed per framework and rolled up into an aggregate posture score displayed on the dashboard.

Generate a Plan of Action and Milestones (POAM) document directly from open findings. The POAM includes finding description, affected controls, planned remediation date, responsible party, and estimated completion timeline. POAMs can be exported as CSV, JSON or XLSX for submission to auditors or authorizing officials.

For audit engagements, the platform keeps status changes made on a case, risk-exception approvals and scan uploads in the hash-chained audit log, and stores each AI triage decision on its case with the model that produced it. Signed evidence export (Vault Protocol) is in progress, and posture-score history is planned.

The executive summary downloads as PDF. Scan comparisons, scheduled report runs and bulk exports download as CSV (raw data for spreadsheet analysis and further processing); scheduled runs and bulk exports can also produce JSON.

Every upload passes through a four-stage pipeline:

Adapters for Tenable, Qualys, CrowdStrike, Rapid7 and Snyk are built, but the sync jobs that pull findings from them are not running yet. Today, export results from your scanner and upload the file.

The crp-scan CLI runs dependency, secrets, and IaC scans directly in your CI/CD pipeline. With an API key, results appear on the Pipelines page in your workspace; they are not added to findings or cases. See the pipeline docs and GitHub Action for integration guides.

Set your organization name and primary contact email. During the alpha, findings map across all 13 frameworks on every plan; industry-specific triage is planned.

Invite team members by email. Each member is assigned one of five roles:

View your current plan, usage metrics (assets, AI calls, team seats), and billing history. Upgrade or downgrade between Free, Pro, and Enterprise tiers. Manage payment methods and download invoices. The billing page connects directly to the Stripe customer portal.

Generate and manage API keys for CLI uploads, scanner connectors, and programmatic access. Keys are scoped to your organization and can be rotated or revoked at any time. Use the API key console for detailed key management.

Create Jira tickets directly from findings or cases. Configure the target project, issue type, priority mapping, and custom fields. Ticket status syncs bidirectionally — resolving a ticket in Jira updates the case status in CVERiskPilot.

Create ServiceNow incidents from cases, with an optional default assignment group. Available on every plan.

Register webhook endpoints and send HMAC-SHA256-signed test deliveries from Settings; live event delivery is planned. See the webhook docs for the signature format and verification examples.

API keys work with the triage, usage and key endpoints under /api/v1, CI pipeline upload, and the MCP server, which reads findings and records dispositions. Other product routes need a signed-in session; a public API reference is planned. See Developers.

The audit log captures all significant platform actions: login attempts, scan uploads, triage decisions (including AI and human), case status changes, role assignments, settings modifications, API key operations, and data exports. Each entry records the actor, timestamp, action type, affected resource, and metadata.

Each audit entry carries the hash of the one before it, so editing or removing an entry breaks the chain and is detectable during verification. Ed25519 signatures and Merkle tree inclusion proofs (Vault Protocol) are in progress; production signing keys are still being set up.

Filter audit log entries by action type, user, date range, and affected resource. The Auditor role has full read access to the audit log without the ability to modify any platform data — designed for external auditors performing evidence review.