Skip to content

Findings

Findings are the core output of Mayo ASPM. Every security issue detected by any scanner — whether through ad-hoc scans, scheduled scans, or PR scans — is normalized into a unified finding record that you can filter, triage, and track to resolution.

What Is a Finding?

A finding represents a single security issue detected in your code or dependencies. Each finding captures:

Field Description
Title A human-readable summary of the issue (e.g., "SQL Injection in user query")
Severity Critical, High, Medium, or Low
Status The current triage state (Open, Confirmed, In Progress, Resolved, False Positive, Accepted Risk)
Scanner Type Which scanner detected the issue (OpenGrep, Semgrep, Trivy, Grype, Gitleaks)
Rule ID The specific scanner rule that triggered the finding
File Path The file where the issue was found
Line Numbers Start and end lines of the affected code
Code Snippet The relevant source code around the finding
Description A detailed explanation of the vulnerability and why it matters
CWE Common Weakness Enumeration identifier (if applicable)
CVE Common Vulnerabilities and Exposures identifier (for dependency findings)
Asset The repository where the finding was detected
First Detected When the finding was first seen
Last Seen The most recent scan that confirmed the finding still exists
Fingerprint A unique hash used for deduplication

The Unified Model

One of Mayo ASPM's key strengths is its unified findings model. Every scanner produces output in its own format — OpenGrep produces SARIF, Trivy produces JSON, Gitleaks produces its own schema. Mayo ASPM normalizes all of these into a single, consistent structure.

This means:

  • One place to see everything — All findings from all scanners appear in the same table with the same columns
  • Consistent severity — Severity levels are normalized across scanners so a "High" from OpenGrep means the same as a "High" from Trivy
  • Unified triage — The same triage workflow applies regardless of which scanner found the issue
  • Cross-scanner deduplication — If two scanners detect the same issue, Mayo ASPM can identify and link them

Normalization Examples

Scanner Output Normalized To
OpenGrep severity: ERROR Mayo ASPM severity: High
Semgrep severity: WARNING Mayo ASPM severity: Medium
Trivy CVSS score: 9.8 Mayo ASPM severity: Critical
Grype severity: Critical Mayo ASPM severity: Critical
Gitleaks finding (any) Mayo ASPM severity: High (secrets are always high by default)

Deduplication by Fingerprint

Every finding is assigned a fingerprint — a hash computed from:

  • Scanner type
  • Rule ID
  • File path
  • Code snippet (or dependency identifier for SCA findings)

When a new scan produces a result that matches an existing fingerprint:

  • No duplicate is created — the existing finding is updated
  • The Last Seen timestamp is refreshed
  • The scan count is incremented
  • Any status changes (from triage) are preserved

This prevents your findings list from growing unboundedly with each scan. If you scan a repository nightly and the same SQL injection exists in the same file, you see one finding — not 365 duplicates.

Fingerprint Stability

Fingerprints are designed to be stable across minor code changes. If a vulnerability moves up or down a few lines (due to nearby edits), the fingerprint uses code content rather than exact line numbers, so the finding remains deduplicated.

Finding Lifecycle

Findings move through a defined lifecycle as they are detected, triaged, and resolved:

                     ┌──────────────────┐
Scan detects ───────▶│      Open        │
                     └────────┬─────────┘
                              │
                    ┌─────────┴──────────┐
                    ▼                    ▼
           ┌──────────────┐    ┌─────────────────┐
           │  Confirmed   │    │ False Positive   │
           └──────┬───────┘    └─────────────────┘
                  │
                  ▼
           ┌──────────────┐    ┌─────────────────┐
           │ In Progress  │    │ Accepted Risk    │
           └──────┬───────┘    └─────────────────┘
                  │
                  ▼
           ┌──────────────┐
           │   Resolved   │
           └──────────────┘
Status Meaning
Open Newly detected, not yet reviewed
Confirmed Reviewed and confirmed as a real vulnerability
In Progress A fix is actively being worked on
Resolved The vulnerability has been fixed
False Positive The finding was reviewed and determined to not be a real issue
Accepted Risk The finding is real but the team has decided to accept the risk

See Triage Workflow for details on transitioning between statuses.

Finding Sources

Findings can be created by any scan mode:

Source When Findings Are Created
Ad-hoc scan When a user triggers a manual scan from the Assets page
Scheduled scan During the nightly automated scan pipeline
PR scan When a pull request is opened or updated on a PR-scanning-enabled repo

Regardless of source, all findings are stored in the same unified model and appear together on the Findings page.

Finding Counts and Metrics

The Mayo ASPM dashboard provides aggregate metrics on findings:

  • Total open findings — across all assets and severities
  • Findings by severity — breakdown of Critical, High, Medium, Low
  • Findings by status — how many are Open vs. Confirmed vs. In Progress, etc.
  • New findings this week — recently detected issues
  • Resolved this week — findings that were fixed
  • Mean time to resolve — average time from detection to resolution

These metrics help security teams track their posture over time and identify trends.

Next Steps