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 (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 (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.

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:

Medium findings are the Yellow ones from both sources, CodeDD AI analysis and SonarQube. They are listed and priced by Financials (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:

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: review states, severity and data states
• Enterprise Data API: the security-findings routes
• MCP Server: list_security_findings and get_security_finding