> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Reports

> Generate and export security reports from your scan data

## Overview

ZeroPath generates exportable security reports for compliance reviews, stakeholder updates, and audit documentation. Reports are generated asynchronously and available for download from the dashboard.

The **Reports** section of the dashboard has two tabs:

* **Generate**: create downloadable Scan, Organization SBOM, Monthly Security, Organization Summary, SLA Compliance, or SOC 2 reports. Each report is a row in a group for its audience (leadership, auditors, engineering teams), showing its file format and when it was last generated, with a **Generate** button; the **Recent** panel lists your own latest files with a download button.
* **History**: search, filter, download, retry and delete generated reports. The tab label shows how many reports you can see.

Two further pages are not tabs and are opened from their URLs:

* **Views** (`/app/reports/views`): build custom report views from preset or saved filter configurations. Requires the **View Custom Reports** permission.
* **Assets** (`/app/reports/assets`): stat cards for **Repositories**, **Applications**, **Endpoints** and **Open Issues**, above a table of applications with **Application**, **Path**, **Repository**, **Tags**, **Open Issues** and **Endpoints** columns. The table footer shows your current position (e.g. "Showing 50 of 200 applications") and loads more results automatically as you scroll. Requires repository-level view access.

The **Generate** and **History** tabs require repository-level view access and are only shown to users who have it. When you open the Reports section (or its sidebar entry), you are directed to the first of **Generate**, **History**, **Views**, **Assets** that you can open. Users with repository view access land on **Generate**, and users with only the **View Custom Reports** permission land on **Views**.

Within the **Generate** tab, the **Scan report** row is available to anyone with repository-level view access. The **Organization SBOM** row has the same requirement: its file covers only the repositories you can view. The organization-level report rows (**Monthly security report**, **Organization summary**, **SLA compliance**, and **SOC 2**) are only shown to users who also have the **View Custom Reports** organization-level permission. If you do not see these rows, contact your organization administrator to request the required permission.

## Dashboard Overview Statistics

The dashboard displays four key security posture metrics at a glance:

| Metric | Description |
| - | - |
| **Total Open** | Total number of open issues across your organization. Click the number to jump directly to the Issues view pre-filtered to open statuses. |
| **Total Resolved** | Total number of issues resolved in the selected time range. Click the number to jump to the Issues view pre-filtered to resolved issues within that date window. |
| **Reachable & Exploitable** | Open SCA issues with reachable package paths and confirmed exploitability |
| **Mean Time To Resolve** | Average time from detection to resolution, for issues resolved in the selected range, with the number of resolved issues that average covers and a **Low sample** marker when it is fewer than ten. Click the number to jump to the Issues view showing those resolved issues. Displays "—" when no issues have been resolved in that range, rather than showing a misleading "0 days". |

The "Reachable & Exploitable" metric highlights the subset of dependency findings that have both a reachable code path and confirmed exploitability, helping you focus on the SCA issues that pose the most immediate risk.

### Dashboard Filters

You can filter all dashboard charts by **severity**, **vulnerability class**, and **application**. The application filter lets you scope every widget, including Open Issues By Severity, Open Issues By Vulnerability Type, Open Issues By Repository, Open Issues By PR Author, Most Critical Open Issues, and Most Critical Resolved Issues, to one or more specific applications. This is especially useful in organizations with monorepos containing multiple services, allowing you to focus on the security posture of a single application at a time.

When any filter is active — including workspace-level team or tag filters, severity, vulnerability class, application, or a time granularity override — a **scope strip** appears between the filter controls and the statistics cards. Each active dimension is shown as a chip; you can click the **x** on a chip to clear that single dimension, or click **Clear all** to reset the dashboard to the full workspace. Clickable statistics cards (Total Open, Total Resolved, Mean Time To Resolve) carry all active filters into the Issues view, so the list you land on always matches the numbers you clicked.

The **Most Critical Open Issues** widget ranks findings by score, highest first. Findings that have not yet received a score are placed at the bottom of the list so that scored, actionable findings are always surfaced first.

The date range picker offers preset windows including **Last 1 year**, in addition to the shorter presets. You can also choose a **Quarterly** time granularity from the period picker alongside the existing daily, weekly, and monthly options. Granularity options that would produce too few or too many chart points for the selected date range are automatically disabled. If you change the date range so that a previously selected granularity no longer fits, the picker resets to **Auto**.

### Open Issues By Vulnerability Type

The dashboard includes an **Open Issues By Vulnerability Type** chart that shows open issues broken down by vulnerability class. Long vulnerability class names, such as full CWE titles, are displayed in the chart legend as truncated labels cut on a word boundary (for example, "Improper Neutralization…"), so the legend remains readable even when multiple classes share a long common prefix. Hover over a segment to see the full vulnerability class name and issue count. You can click a legend entry to highlight that class across the chart.

### Issues By Application

The dashboard includes an **Issues By Application** chart that groups open and resolved issues by application. Each bar represents one application, split by open (red) and resolved (green) segments. You can hover over a segment to see the exact count. This chart respects the same severity, vulnerability class, and application filters as the other dashboard widgets.

### Open Issues By PR Author

The **Open Issues By PR Author** chart shows open issues from each repository's latest **merged** pull request scan, grouped by the PR author. Scans for pull requests that were never merged are excluded, so no author is attributed findings from work that did not ship. Full-scan-only findings are not included here.

### Mean Time To Resolve Chart

The **Mean Time To Resolve** trend chart plots the average remediation time — in days — for issues resolved within each individual period (day, week, month, or quarter). Each point reflects only the issues that were resolved during that period, so the value is self-contained and does not shift when you change the date range. Periods in which no issues were resolved show no data point rather than a misleading zero.

This is consistent with the **Mean Time To Resolve** summary card above the chart, which reports the straight average for issues resolved within the selected range only.

### Estimated Exposure Window

The **Estimated Exposure Window** chart shows, for each period, the average time (in days) that open issues of each severity had been exposed. It does not count issues. If no issues of a given severity are open during a period, that severity's line breaks rather than dropping to zero.

### Dashboard Profiles

A **dashboard profile** is a saved arrangement of the dashboard widgets on a 12-column grid, together with the filters (date range, period, severity, vulnerability class, application) that were active when it was saved. Selecting a profile restores both the layout and the filters.

* The **profile switcher** beside the page title lists your **personal** profiles and the **org templates** shared with everyone in the organization. The dashboard opens with the profile you last opened (marked with a star), on every device. While the layout or filters on the page differ from the saved profile, the switcher shows **· edited** and a notice under the filters offers **Save to profile** or **Reset**.
* **Edit Layout** opens the layout editor, which shows the 12-column grid with empty-cell guides and an **Add widgets** side panel. To add a widget, drag its card from the panel onto the grid. Each card shows the widget's name and exact cell footprint (for example, 4 × 2). To move a placed widget, drag it by its header; a ghost outline follows the pointer and turns white at valid positions or red where it would overlap another widget. Remove any widget with the **×** in its drag handle. Pressing **Escape** during a drag cancels the move and snaps the widget back. **Save profile** writes the new layout and the current filters to the profile; **Save as new** saves them under a new name instead.
* **Manage profiles** lets you open, star (set as the default profile the dashboard opens with), duplicate, or delete any profile. The **Default** badge marks the profile the dashboard opens with; the **Viewing** badge marks the one currently on screen. Deleting the starred profile makes the dashboard open with the next available profile. Duplicating an org template gives you a personal copy you can edit freely.
* When saving a new profile, you choose its name and whether it is **Personal** (only you see it) or **Org template** (everyone in the organization can use it). The save dialog shows which widgets and filters will be included so you can confirm before saving.
* A member who has not saved a profile yet sees the **default layout** with a strip offering to keep it as a profile, start blank, or browse the org templates. **Edit Layout** on it starts a new profile from that layout.

Personal profiles need no special permission. Creating, editing, or deleting an **org template** requires the **Manage Dashboard Templates** organization permission, which stays with organization admins unless it is delegated to a team under **Settings → Teams**. Editing an org template without that permission always saves as a new personal profile.

## Report Types

| Type | Description |
| - | - |
| **Scan Report** | Detailed findings from a specific scan — includes all vulnerabilities, severity breakdown, affected files, and remediation status |
| **Organization SBOM** | ZIP of CycloneDX 1.6 or SPDX 2.3 JSON, one per repository you can view, with manifest.json |
| **Monthly Security Report** | Month-over-month security posture with per-repository stats; scope can be narrowed to specific tags or repositories |
| **Organization Summary** | High-level security posture across repositories in scope, with mean time to remediate and exposure metrics |
| **SLA Compliance Report** | Policy-based SLA tracking showing which findings are within or outside your configured remediation windows; scope can be narrowed to specific tags or repositories |
| **SOC 2 Report** | Compliance-focused report structured for SOC 2 audit evidence; scope can be narrowed to specific tags or repositories |

## Export Formats

Scan reports support multiple output formats:

| Format | Best For |
| - | - |
| **DOCX** | Stakeholder presentations, compliance documentation |
| **CSV** | Data analysis, custom dashboards, spreadsheet workflows |
| **SARIF** | Tool integration, CI/CD pipelines, SARIF viewers |
| **SBOM** | Supply chain compliance (CycloneDX JSON format) |

The Monthly Security Report is generated as a **DOCX** document. Organization Summary and SOC 2 reports are generated as **PDF** documents. The SLA Compliance Report is generated as a **ZIP** archive holding the report as `sla-compliance-report.pdf` and its findings as `findings.csv` and `findings.json`. Custom reports can be exported as **CSV**, **CASA CSV**, **SARIF**, or **PDF** (see [Exporting Custom Reports](#exporting-custom-reports)).

## Generating Reports

While one of your organization-level reports — **Monthly security report**, **Organization summary**, **SOC 2**, or **SLA compliance** — or your own **Organization SBOM** export is queued or generating, the **Generate** button on its row is disabled, so the same report is not started twice. It reads **Queued** while the report waits for a worker and **Generating…** while a worker runs it. The button is available again once the report is ready or has failed, or, for every row but **Organization SBOM**, once the report has been queued or generating for more than 30 minutes: an organization SBOM export never stalls, and you can have one in progress at a time. The **Scan report** button always stays available, so you can start reports for several scans one after another.

### Scan Report

1. Navigate to **Reports → Generate** in the dashboard.
2. Click **Generate** on the **Scan report** row (under **For engineering teams**).
3. Select a **repository** using the searchable picker. You can type to filter by name — the picker searches across all repositories in your organization, not just those on the first page of results. All repositories are listed regardless of whether the latest scan found issues, since reports can be generated for any completed scan.
4. Select a **scan** from the dropdown (populated after choosing a repo — shows full and PR scans with issue counts).
5. Select the **format** (DOCX, CSV, SARIF, or SBOM).
6. Set a **score threshold** — only findings above this score are included.
7. Choose which **issue types** to include (Exclude False Positives or All Issues).
8. Click **Generate**. The dialog closes and the report appears under **Recent** on the Generate tab (and in **History**); download it from either once it is ready. The **Scan report** row's **Generate** button stays available while it generates, so you can start a report for another scan right away.

### Organization SBOM

1. Navigate to **Reports → Generate** in the dashboard.
2. Click **Generate** on the **Organization SBOM** row (under **For engineering teams**).
3. Choose the **format**: **CycloneDX 1.6 (JSON)** or **SPDX 2.3 (JSON)**.
4. Read the preview: how many repositories you can view, how many will be exported, and how many will be listed as skipped. **Generate** stays disabled while nothing can be exported.
5. Click **Generate**. The dialog closes, the row reads **Queued** while the export waits for a worker, which takes longer when other exports are ahead of it, and **Generating…** while a worker builds it; the export appears under **Recent** and in **History**. Download the ZIP from either once it is ready.

The ZIP holds one SBOM per repository you can view, built from the latest dependency inventory on each repository's default branch, and a `manifest.json` listing what was included and what was skipped and why. See [Organization SBOM export](/docs/sca/sbom-exports#organization-sbom-export) for the manifest and the skip reasons.

### Monthly Security Report

1. Navigate to **Reports → Generate** in the dashboard.
2. Click **Generate** on the **Monthly security report** row (under **For leadership**).
3. Optionally enter a **title** for the report; without one, a report for September 2026 is titled "Monthly Security Report - 9/2026". Choose the **month** and **year** to report on and the **severity levels** to include.
4. Optionally narrow the report scope by selecting specific **tags** or **repositories**. By default the report covers your entire organization.
5. Click **Generate**. The dialog closes and the row's **Generate** button reads **Queued** while the report waits for a worker and **Generating…** while it generates; download the DOCX from **Recent** or **History** once it is ready.

### SLA Compliance Report

1. Navigate to **Reports → Generate** in the dashboard.
2. Click **Generate** on the **SLA compliance** row (under **For auditors**).
3. Choose the **SLA policy** to report on.
4. Optionally narrow the report scope by selecting specific **tags** or **repositories**. By default the report covers your entire organization.
5. Click **Generate**. The dialog closes and the row's **Generate** button reads **Queued** while the report waits for a worker and **Generating…** while it generates; download the ZIP from **Recent** or **History** once it is ready.

### Organization Summary

1. Navigate to **Reports → Generate** in the dashboard.
2. Click **Generate** on the **Organization summary** row (under **For leadership**).
3. Optionally provide a custom company name.
4. Optionally narrow the report scope by selecting specific **tags** or **repositories**. By default the report covers your entire organization.
5. Click **Generate**. The dialog closes and the row's **Generate** button reads **Queued** while the report waits for a worker and **Generating…** while it generates; download the PDF from **Recent** or the **History** tab when ready.

The generated document includes a **Scope** field on the cover page that describes exactly which repositories were included — for example, "All repositories (12)" or the specific tags and repository names you selected.

### SOC 2 Report

1. Navigate to **Reports → Generate** in the dashboard.
2. Click **Generate** on the **SOC 2** row (under **For auditors**).
3. Optionally provide a company name.
4. Optionally narrow the report scope by selecting specific **tags** or **repositories**. By default the report covers your entire organization.
5. Click **Generate**. The dialog closes and the row's **Generate** button reads **Queued** while the report waits for a worker and **Generating…** while it generates; download it from **Recent** or the **History** tab when ready.

The generated document includes a **Scope** field on the cover page that describes which repositories were included in the report.

<Note>
  All organization-level reports — Monthly Security Report, Organization Summary, SLA Compliance, and SOC 2 — display a **Scope** field on their cover page or header. When you generate a report without selecting any specific tags or repositories, the scope reads "All repositories" with the total count. When you narrow the scope, it lists the specific tags and repository names you chose. This makes the report self-describing for audit purposes, so a reader can tell exactly what was in scope without referring back to the generation settings.
</Note>

## Per-issue vulnerability report

You can export a single finding as a Word document. Open the issue, either its full page or the issue panel, click **More actions** (the **⋯** button), and choose **Export report (.docx)**. The file downloads in your browser right away. It is not generated on the **Generate** tab and does not appear on the **History** tab.

The report has these sections:

* The finding's title and severity
* **Status**
* **Description**
* **Severity**, with an **Impact** and a **Likelihood** rating, each with an explanation. Both ratings are derived from the finding's CVSS vector.
* **Exploitation**, the exploitation scenarios with their preconditions
* **Proposed fix**, the patch for each affected file

A section with no data says so in the document. For a detected secret, the model-written text and the patch are withheld from the file, because they can quote the secret.

The same report is available as Markdown through the `issues.vulnerabilityReport` [MCP tool](/docs/mcp/tools).

## Report History

All generated reports are listed in the **History** tab of the **Reports** section, newest first, 20 per page, with:

* Report title and file name
* Report type
* Who requested it
* When it was created
* Status (**Ready**, **Generating**, **Queued**, or **Failed** with the failure reason underneath)
* File size
* A **Download** button on ready reports, a **Retry** button on failed reports, and a **Delete** button on completed, failed, and stalled reports

An **Organization SBOM** row shows "N repositories · K skipped" under **Ready** once it finishes. It never shows as stalled: once its export starts, it keeps running until it finishes or fails. **Delete** is offered while it is still queued (deleting it cancels the export) and once it has finished or failed. Other members of the organization cannot see it, admins included; an organization admin's personal API token can, as it reads every report. Service tokens cannot read generated reports.

The toolbar narrows the list by a **search** across titles and file names, a **Type** menu, the **All / Ready / In progress / Failed** status segments, and a **Requested by** menu. Each option shows how many reports choosing it would list. The filters and the page are kept in the page URL (`q`, `type`, `status`, `requestedBy`, `page`), so a filtered view can be bookmarked or shared; **Clear filters** resets them when nothing matches. The pager below the table reads, for example, "Page 1 of 3 · 48 reports, newest first".

**Retry** re-submits a failed report with the parameters it was originally generated from (the scan, the month, the severity levels, the tag and repository scope, the SLA policy, and so on) through the same request its generate dialog makes, so the same permission and scope checks apply. The retried report appears as a new row; the failed row stays until you delete it. Retry is offered only when the stored parameters are complete: reports generated before scope selection existed and per-repository SBOM exports cannot be retried. An **Organization SBOM** can: **Retry** starts a new export in the same format, for the repositories you can view now. If the retry is refused (for example because a selected tag or repository has since been deleted, or the SLA policy was disabled), the reason is shown and nothing is queued.

Deleting a report asks for confirmation first — the dialog names the report and warns that it will be removed permanently, with its file when deleting removes one (a failed or stalled report usually has no file, and a per-repository SBOM's file is left to expire on its own, after 24 hours by default). Reports that are still queued or generating cannot be deleted; a report that has been queued or generating for more than 30 minutes is treated as stalled and can be. An **Organization SBOM** is never treated as stalled; it can be deleted while it is queued, and the dialog then says the export will be cancelled and deleted.

The report history respects per-report-type visibility. Organization-scoped reports (Monthly Security, Organization Summary, SLA Compliance, and SOC 2) are visible only to users who hold the **View Custom Reports** permission. Repository-scoped reports (Scan Report and SBOM) are visible to users who have view access to the report's repository. You can always see reports you created yourself, regardless of these permission checks. A personal API token sees the reports its owner sees, except that an organization admin's personal token sees every report, other people's Organization SBOMs included. Service tokens, which belong to no one, cannot read generated reports.

While a report is being generated, the history view **automatically refreshes** so you can see status updates in real time without reloading the page. When checking report status via the API, the response includes the report's `fileName` alongside the status, so you can identify the generated file before downloading it.

Reports can be downloaded or deleted from the history view. The same per-report-type visibility applies to downloads and deletions — you cannot download or delete a report you cannot see in the history list.

## Custom Report Statistics

Custom reports let you apply the full set of issue filters and retrieve aggregated statistics for the matching findings. This is useful for building executive dashboards, tracking remediation progress over time, or generating focused views of your security posture.

### Interactive Dashboard

When you open a custom report on the **Views** page (`/app/reports/views`), the platform displays an interactive dashboard with visual charts that update automatically as you change filters:

| Chart | Description |
| - | - |
| **Total Issues** | A prominent count of all issues matching your current filters |
| **Severity Distribution** | A color-coded stacked bar showing the breakdown by severity level (Critical, High, Medium, Low, Info), with per-level counts |
| **MTTR** | Mean time to remediation in days, calculated across resolved issues in the result set |
| **Top Vulnerability Classes** | A horizontal bar chart ranking the most common vulnerability categories among matching issues |
| **Issue Trend** | A line chart comparing new vs. resolved issues over time |

Below the charts, a paginated **issue table** lists all matching findings with columns for severity, score, title, repository, vulnerability class, status, and detection date. You can click any row to open a side pane with full issue details — your filters, scroll position, and selected report remain intact. Actions taken in the side pane (such as marking an issue as false positive or changing its status) refresh the report in the background without losing your place.

### Filter Bar

The filter bar uses a chip-based interface for building queries. Each filter appears as a compact chip showing the field name, operator, and selected value. You can:

* Click **"Add filter"** to choose from available filter fields, organized by category (Issue, Repository, Scan).
* Click an existing filter chip to edit its field, operator, or value inline via a popover.
* Remove individual filters by clicking the **x** button on a chip, or click **Clear** to reset all filters.
* Click **Save** to store the current filter configuration as a named report (see [Saved Custom Reports](#saved-custom-reports) below).
* Click **Export** to download the matching issues in your preferred format (see [Exporting Custom Reports](#exporting-custom-reports) below).

Available filter fields include:

| Field | Type | Example Operators |
| - | - | - |
| **Severity** | Enum | is, is not, is any of |
| **Score** | Number | =, !=, >=, \<, between |
| **Status** | Enum (Needs Review, Reviewing, Patching, …) | is, is not, is any of |
| **Type** | Enum (SAST, Logic, Policies, Secrets, IaC, CI/CD, EoL, SCA, Container, Uncategorized) | is, is not, is any of |
| **Vulnerability Class** | Text | contains, equals, starts with, is unknown |
| **Validation State** | Enum (Confirmed, Disconfirmed, Unknown) | is, is not, is any of |
| **Reachability** | Enum (Likely Exploitable, Needs Review, Likely Non-Exploitable) | is, is not, is any of |
| **Runtime Validation** | Enum (Confirmed, Disconfirmed, Untestable, Agent Error) | is, is not, is any of |
| **CVSS 4.0 Attack Vector** | Enum (Network, Adjacent, Local, Physical) | is, is not, is any of |
| **CVSS 4.0 Attack Complexity** | Enum (Low, High) | is, is not, is any of |
| **CVSS 4.0 Privileges Required** | Enum (None, Low, High) | is, is not, is any of |
| **CVSS 4.0 User Interaction** | Enum (None, Passive, Active) | is, is not, is any of |
| **Runtime Setup** | Enum (Unknown, Default setup, Requires modification) | is, is not, is any of |
| **Is New Issue** | Boolean | is true |
| **Wiz Exposure** | Boolean | is true |
| **Search** | Text | contains |
| **Language** | Enum | is, is not, is any of |
| **Repository Name** | Text | contains, equals, starts with |
| **Branch** | Text | equals, contains |
| **Tag** | Text | equals |
| **Application** | Enum (detected applications per repository) | is, is any of |
| **Detected At** | Date | is, before, after, between, in last N days, at or after, at or before |
| **Resolved At** | Date | is, before, after, between, in last N days, at or after, at or before |
| **Scan Type** | Enum (Full Scan, PR Scan) | is, is not, is any of |

Custom report statistics include:

| Metric | Description |
| - | - |
| **Total Count** | Number of issues matching your filters |
| **Severity Distribution** | Breakdown of matching issues by severity level (Critical, High, Medium, Low, Info) |
| **Top Vulnerability Classes** | The most common vulnerability categories among matching issues, ranked by count |
| **Mean Time to Remediation** | Average number of days from issue creation to resolution for resolved issues in the result set |
| **Trend** | A time-series view of new and resolved issues over the filtered period |

You can narrow results using any combination of the standard issue filters, including:

* **Date ranges** — filter by issue creation or resolution date using exact bounds ("at or after" / "at or before" with a datetime picker), calendar-day ranges ("between"), or a relative window ("in last N days", up to 36,500 days)
* **Validation state** — include only confirmed, disconfirmed, or unknown findings
* **Reachability** — filter by whether the vulnerable code path is reachable in your application
* **Runtime Validation** — filter by the dynamic testing verdict (Confirmed, Disconfirmed, Untestable, or Agent Error)
* **Runtime Setup** — filter by the setup complexity required to dynamically test a finding (Default setup or Requires modification)
* **CVSS 4.0 metrics** — filter by Attack Vector, Attack Complexity, Privileges Required, or User Interaction to zero in on specific threat profiles
* **Vulnerability class operators** — match vulnerability classes using exact match, prefix, substring, or "is unknown" (findings with no assigned vulnerability class)
* **Application filters** — narrow results to specific applications detected within your repositories (useful for monorepos with multiple services)
* **Repository branches** — scope the custom report to specific branches per repository, rather than using only the default branch
* **Score exclusion** — exclude issues at a specific score value (one exclusion per report)
* **Presence filters** — "Is New Issue" and "Wiz Exposure" can be set to "is true" to include only findings that match; omitting the filter returns all findings regardless of that attribute

Custom report statistics are available through the API and the dashboard, and require the **View Custom Reports** permission.

### Preset Reports

The **Views** page includes several built-in preset reports so you can start analyzing common issue categories immediately without configuring filters manually:

| Preset | Description |
| - | - |
| **SCA Vulnerabilities** | All dependency / software composition analysis findings |
| **PR Scan Issues** | Issues detected during pull request scans |
| **Secrets Exposure** | Exposed secrets and credentials |
| **Critical & High Severity** | All critical and high severity findings |
| **SAST Findings** | Static analysis findings (traditional and business logic) |
| **New Issues (Last 30 Days)** | Newly detected issues from the past 30 days |

Preset reports cannot be edited or deleted. To customize a preset, select it and modify the filters, then save it as a new custom report.

### Saved Custom Reports

You can save frequently used filter configurations as named custom reports for quick access. Saved reports are available both from the **Views** page in the dashboard and through the API.

From the **Views** page, you can:

* Select **New Custom Report** to build a report from scratch, or choose a **preset report** to start from a predefined filter configuration.
* **Save** a custom report with a name so you can return to it later. Saved reports appear in the report selector dropdown under **Saved Reports**.
* **Delete** a saved report by selecting it and clicking the delete button.

Creating and viewing saved reports requires the **Create Custom Reports** and **View Custom Reports** permissions. Deleting saved reports requires the **Delete Custom Reports** permission.

The API also provides endpoints to list, create, and delete saved custom reports programmatically.

### Saved Issue Rules

Saved filter configurations are also available for the **Issues** view, independently of the Reports **Views** page. Issue rules use the same filter schema as custom reports but are scoped to the Issues page. You can list, create, and delete them via:

* `GET /api/v1/reports/issue-rules/list` — list saved issue rules for the organization.
* `POST /api/v1/reports/issue-rules/create` — create a new saved issue rule with a name and filter array.
* `DELETE /api/v1/reports/issue-rules/delete` — delete a saved issue rule by ID.

Creating and viewing saved issue rules requires the **Create Custom Reports** and **View Custom Reports** permissions. Deleting them requires **Delete Custom Reports**.

### Exporting Custom Reports

You can export any custom report view by clicking the **Export** button in the filter bar. This opens an export dialog where you choose a format and download the matching issues.

#### Export Formats

| Format | Description |
| - | - |
| **Regular CSV** | All issues matching the current filters, exported as a CSV file |
| **CASA Relevant CSV** | Only CASA-relevant issues matching the current filters |
| **SARIF** | Issues with code locations, for SARIF-compatible tools. You can optionally include **preconditions** and **exploit walkthrough** context in the SARIF output. Issues without code location data are omitted, and you are notified of the count. |
| **PDF** | A shareable PDF that mirrors the on-screen dashboard (see below) |

#### Export Completeness

Exports include all matching findings regardless of whether they have a confidence or priority score. Findings that have not been assessed by a validation agent report null values for confidence and score rather than being omitted from the export. This ensures that security exports are always complete and no findings are silently dropped.

#### Ticket Links in Exports

CSV exports include a **Tickets** column and a **Ticket URLs** column carrying the Jira and Linear tickets each finding was filed as, so an export can be reconciled against your tracker — for example, pulling the keys out of an export to ask which of those tickets are still open. Multiple tickets on one finding are separated by `; `, and the two columns stay position-aligned: the Nth key always describes the same ticket as the Nth URL, so a ticket whose browse URL could not be derived holds an empty slot rather than shifting the later URLs. A finding that was never filed leaves both cells empty. The same links are available programmatically as the `tickets` array on each item returned by `/api/v2/issues/export`. Scan report CSVs carry the same two columns.

Linear tickets are keyed by their human identifier (`ENG-7`), the same value Linear's UI searches on, and their URL is exported in canonical form (`https://linear.app/<workspace>/issue/<ID>`) rather than the longer form Linear shows in the browser. The trailing segment of a Linear URL is a slug of the ticket title, and exports withhold AI-generated titles for secret findings; dropping the slug keeps that guarantee. The shortened URL opens the same ticket.

#### PDF Export Details

The generated PDF includes:

* A **cover page** with the report name, generation date, total issue count, and mean time to remediation
* **Charts** matching the interactive dashboard: total issues, severity distribution, MTTR, top vulnerability classes, and issue trend over time
* A **top issues table** listing the highest-scoring findings (up to 500) with severity, score, title, repository, vulnerability class, status, and detection date. Findings without a score are sorted to the bottom of the table so that scored findings are always surfaced first.

You can optionally set a custom report name and choose how many top issues to include in the table (default: 100, maximum: 500). If the total number of issues exceeds the table limit, the PDF includes a note indicating how many issues were omitted.

All exports respect your active filters, so the downloaded file reflects exactly what you see on screen. This is useful for sharing security posture snapshots with stakeholders who do not have dashboard access.

For secret findings, exported CSV and SARIF files automatically mask the secret value (showing only the last four characters, or for RSA/SSH key material, the algorithm label with a short head and tail). The AI-generated description, attack steps, and preconditions for secret findings are also withheld from exports, since those narratives are generated from the source line and can quote the secret in prose. This ensures that no export artifact reproduces a detected credential. Finding titles for secret findings are also redacted throughout the dashboard, including the Most Critical Open Issues widget, so that AI-generated titles that may reference the secret value are never displayed.

<Note>
  Exporting custom reports requires the **View Custom Reports** permission.
</Note>

### Filter Schema Discovery

You can retrieve the full list of available filter fields and their valid values programmatically via the filter schema endpoint. This is useful when building integrations or custom dashboards, as it lets you discover which filters are supported and what operators each filter accepts without hardcoding filter definitions.

## Report Contents

### Scan Report (DOCX)

* Executive summary with finding counts by severity
* Repository and scan metadata (branch, commit, date)
* Detailed finding list with:
  * Title, severity, confidence score
  * Affected file and line range
  * Vulnerability description and remediation guidance
  * CWE classifications

For secret findings, scan reports apply the same redaction as custom report exports: finding titles and descriptions are masked so that no exported artifact reproduces a detected credential. This applies to all scan report formats (DOCX, CSV, and SARIF).

### Monthly Security Report (DOCX)

* Month-over-month security posture for the repositories in scope
* Per-repository scan activity and finding counts
* Severity breakdown and top vulnerability families
* AI-generated executive summary for stakeholder communication
* **Mean Time to Remediate** is formatted with appropriate precision and includes the number of resolved issues and the date window the average covers — for example, "43 days (941 issues resolved Jul 1 – Jul 31, 2026)" — so readers can judge the weight of the metric at a glance. When no issues were resolved during the month, the metric is omitted from the summary rather than shown as zero (which would imply instant remediation).
* Cover page includes a **Scope** field describing the repositories included

### Organization Summary (PDF)

* Aggregate statistics across the repositories in scope
* Finding trends and severity distribution
* Repository-level breakdown
* Top vulnerabilities by impact
* **Mean Time to Remediate** and per-severity **exposure days** are formatted with appropriate precision rather than always rounding to whole days. The mean remediation time includes the number of resolved issues and the date window the average covers, so readers can assess the sample size alongside the metric. When no issues were resolved in the report window, the mean remediation time is omitted rather than shown as zero.
* Cover page includes a **Scope** field describing the repositories included

### SLA Compliance Report (ZIP: PDF + CSV)

* `sla-compliance-report.pdf`, with `findings.csv` and `findings.json` holding every finding the report counts
* Policy-based SLA compliance tracking: which findings are within or past your configured remediation windows
* Filtered to the repositories in scope, with a **Scope** field on the report header

### SOC 2 Report (PDF)

* Compliance-focused metrics structured for SOC 2 audit evidence
* Repository coverage and scan activity for the period
* Cover page includes a **Scope** field describing the repositories included

### SBOM Export

* Full dependency inventory from the selected scan
* Package metadata, licenses, and dependency relationships
* You can generate an SBOM from any completed scan — an SCA scan is included automatically if available, but is not required
* Active table filters do not limit the exported inventory — the export always covers the full scan
* SBOM generation usually takes less than a minute. Keep the dialog open while it completes.
* See [SCA SBOM Exports](/docs/sca/sbom-exports) for details

#### ML-BOM Export (AI Inventory)

When exporting from an AI inventory view, the dialog title changes to **Export ML-BOM** and only the **CycloneDX ML-BOM** format is available. This produces a CycloneDX ML-BOM document inventorying the AI/ML models and datasets detected in the selected scan. Active table filters do not limit the exported inventory.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.