--- title: Security findings (Issue Compass) description: How Issue Compass lists the security findings of a group audit, what each severity and review state means, which findings count as open, and how the API, advisor and MCP serve them category: Portfolio Analytics order: 10 --- # Security findings (Issue Compass) Issue Compass is the security findings explorer of a group audit (**Portfolio → Issue Compass**). It lists the security findings across every repository of one audit round of a company, most severe first, with where each one is, how severe it is, whether it was validated and what to do about it. The same findings, with the same severity, review state and counts, are served by the [Enterprise Data API](/documentation/enterprise-data-api) (`GET /group-audits/{id}/security-findings/` and the finding detail route), by the in-app AI advisor (`get_security_findings_summary`, `get_security_finding_detail`) and by the [MCP server](/documentation/mcp-server) (`list_security_findings`, `get_security_finding`). The web app is the reference. Words such as open and review state are also defined in the [Glossary](/documentation/glossary). ## Where findings come from Each finding has a `source`: - **`llm`: CodeDD AI analysis.** Flags the audit raised while reading the code, each checked by the AI validator when it is Red or Orange. These carry an OWASP category (A01-A10 or `OTHER`, from the validator's category), a CWE where known, the AI validation (verdict, confidence, conclusion, impact, recommended action), exploitability and reachability. - **`sonar`: SonarQube.** Security issues from the static analysis run during the audit, with SonarQube's own severity. A finding belongs to one repository audit of the group audit. Its `file` is the path inside that repository (`src/app/main.py`): CodeDD's checkout folders are never shown. `line_range` is the finding's lines, or null when the audit did not record them. ## Severity Issue Compass names each finding's severity by the same colours as the repository flags: | Severity | Colour | In the critical/high KPI | |----------|--------|--------------------------| | `critical` | Red | Yes | | `high` | Orange | Yes | | `medium` | Yellow | No | **Medium** findings are the Yellow ones from both sources, CodeDD AI analysis and SonarQube. They are listed and priced by [Financials](/documentation/glossary#fix-days-and-effort) (the Issue Compass scope includes Yellow), but they stay outside the critical/high KPI and the Critical/High validation breakdown. AI Yellow findings are not validated, so they read Medium / Not validated. Issue Compass never produces a `low` severity. ## Review states Every finding has one review state: | Review state | Shown as | Counts as open | |--------------|----------|----------------| | `confirmed` | Confirmed: the AI validator, a rule or a reviewer confirmed it | Yes | | `inconclusive` | Inconclusive: the validator could not decide | Yes | | `not_validated` | Not validated: never checked by the validator | Yes | | `refuted_by_ai` | Refuted by AI: the validator refuted it | No | | `dismissed` | Dismissed by user: a reviewer dismissed it | No | | `resolved` | Resolved: fixed in the code | No | `counts_as_open` is true for the first three. `confirmed_by` says who confirmed a finding: `reviewer`, `ai` or `rule` (null for any other state). When a reviewer decided, `user_marked_valid` (true confirmed, false dismissed) and `user_marked_timestamp` (UTC) say so. Who decided is never served. `ai_verdict` on the detail is the validator's own answer: `confirmed`, `refuted`, `inconclusive` or `not_validated`. ## What counts as open Open findings are the ones still to fix: confirmed, inconclusive and not validated. They are the default everywhere: - **Web**: the explorer lists open findings by default; its status chips add the others (resolved and dismissed rows are loaded only when a chip asks for them). - **MCP** `list_security_findings`: `status` is `open` (default), `refuted_by_ai`, `resolved`, `dismissed` or `all` (every state). `get_security_finding` opens resolved and dismissed findings too. - **AI advisor**: open by default; `validation_status` takes `refuted_by_ai`, `resolved`, `dismissed` or `all`. - **Enterprise API**: every open and AI-refuted row, each with `review_state` and `counts_as_open`, plus `open_count`; `?include_closed=1` adds the resolved and dismissed rows. Two counts are served: `totals.open` (MCP) or `open_count` counts every open finding, medium included; `open_critical_high` (MCP `totals.open_critical_high`, API `open_critical_high_count`) counts the open critical and high findings, the figure the KPIs use. Resolved and dismissed rows are read only when a status asks for them, and the rollups describe open rows only. ## Saved selections A saved Issue Compass selection stores your filters (severity, source, OWASP category, status, text, domains). Over MCP, `saved_selection` applies one of your own selections for that group audit, and `include_saved_selections` lists them. Without an explicit status, the selection's own status filter applies, or open findings when it has none. An explicit `severity`, `source`, `owasp` or `status` replaces what the selection stores for that filter. Saved selections are personal: they are never listed to anyone else and are not served to an organization API key. ## While a group audit runs The findings of a group audit that is still running are served as they are found, marked `partial: true` (and `meta.partial` on the Enterprise API), with a note. They are not final until the group audit completes. KPIs are not shown for a running group audit. ## The CSV export The Issue Compass CSV export lists the same rows as the explorer. Its `file` column is the repository-relative path (the repository folder is not repeated), and the last two columns are `user_marked_valid` and `user_marked_timestamp` (ISO 8601). ## Recent changes - AI (CodeDD analysis) Yellow findings now appear in Issue Compass as Medium / Not validated, next to SonarQube Yellow. They count in the list total and the effort figures, not in the critical/high KPI. - Resolved and dismissed findings, and a reviewer's decision (`user_marked_valid`, `user_marked_timestamp`), are served on MCP, the advisor and the Enterprise API. - File paths are repository-relative on every surface, and the CSV export drops the repository folder from `file`. - Severities are labels (`critical`, `high`, `medium`) on every surface, list and detail alike; earlier descriptions that called Orange "medium" were wrong. ## Next steps - [Glossary](/documentation/glossary): review states, severity and data states - [Enterprise Data API](/documentation/enterprise-data-api): the security-findings routes - [MCP Server](/documentation/mcp-server): `list_security_findings` and `get_security_finding`