Understanding Scan Results¶
Your first scan is complete and findings have appeared. This page explains what you are looking at and how to act on it.
Anatomy of a finding¶
Every finding in Mayo ASPM contains a consistent set of fields, regardless of which scanner produced it. Here is what a typical finding looks like:
┌─────────────────────────────────────────────────────────────────┐
│ FINDING: SQL Injection via string concatenation │
│ │
│ Severity: HIGH Status: Open │
│ Scanner: Semgrep Rule: python.sqlalchemy.injection │
│ CWE: CWE-89 CVE: — │
│ │
│ File: src/api/users.py │
│ Line: 47 │
│ │
│ Code snippet: │
│ 45 │ def get_user(user_id): │
│ 46 │ query = "SELECT * FROM users WHERE id = " │
│ 47 │ query += user_id # <-- vulnerability │
│ 48 │ return db.execute(query) │
│ │
│ Message: │
│ User-controlled input is concatenated into a SQL query │
│ without sanitization. Use parameterized queries instead. │
└─────────────────────────────────────────────────────────────────┘
Field-by-field breakdown¶
| Field | Description |
|---|---|
| Title | A human-readable summary of the vulnerability. |
| Severity | The risk level: Critical, High, Medium, Low, or Info. See severity table below. |
| Status | The current triage state: Open, Confirmed, Accepted Risk, Resolved, or False Positive. |
| Scanner | Which scanner detected this finding. |
| Rule | The specific scanner rule that triggered (e.g., python.sqlalchemy.injection). |
| CWE | The Common Weakness Enumeration identifier, linking to a standardized vulnerability category. |
| CVE | The Common Vulnerabilities and Exposures identifier, if the finding maps to a known published vulnerability (common for dependency findings). |
| File | The source file where the vulnerability was found, as a relative path from the repository root. |
| Line | The line number within the file. |
| Code snippet | A few lines of code surrounding the vulnerability, with the affected line highlighted. |
| Message | A detailed explanation of what the vulnerability is and how to fix it. |
Severity levels explained¶
Mayo ASPM normalizes severity from all scanners into five levels:
| Severity | Meaning | Examples | Action urgency |
|---|---|---|---|
| Critical | Actively exploitable, high impact. Could lead to full system compromise, data breach, or remote code execution. | Remote code execution, exposed secrets in production, SQL injection on auth endpoints | Fix immediately. |
| High | Exploitable with moderate effort. Significant impact if exploited. | SQL injection, XSS on sensitive forms, hardcoded credentials, path traversal | Fix within days. |
| Medium | Exploitable under certain conditions. Impact is limited or requires chaining with another vulnerability. | CSRF, information disclosure in error pages, missing security headers, weak crypto | Fix within your normal sprint cycle. |
| Low | Minor security concern. Low likelihood of exploitation or minimal impact. | Verbose logging, outdated but non-vulnerable dependencies, permissive CORS on non-sensitive endpoints | Address when convenient. |
| Info | Informational. Not a vulnerability, but something to be aware of. | Use of deprecated APIs, code quality suggestions, best-practice recommendations | Review and decide. |
Severity is a starting point, not the final word
Scanner-assigned severity does not account for your specific environment. A "Medium" SQL injection on an internal admin tool might be lower risk than a "Medium" XSS on your public-facing login page. Use triage to adjust priority based on your context.
The findings list¶
When you navigate to an asset's Findings tab (or the global Findings page), you see a table with all findings. Key features of this view:
Filtering¶
Use the filter bar at the top to narrow results:
| Filter | Options |
|---|---|
| Severity | Critical, High, Medium, Low, Info |
| Status | Open, Confirmed, Accepted Risk, Resolved, False Positive |
| Scanner | Semgrep, Bandit, Trivy, Gitleaks, Checkov |
| File path | Free-text search within file paths |
| Rule | Filter by specific scanner rule ID |
| CWE | Filter by CWE identifier |
| Date range | First seen / last seen date |
Sorting¶
Click any column header to sort. Common sorts:
- Severity (descending) — Critical first. The default and most common view.
- First seen (newest) — recently introduced findings first.
- File path — group findings by location in the codebase.
Bulk actions¶
Select multiple findings using the checkboxes and apply bulk actions:
- Change status — move multiple findings to Confirmed, Accepted Risk, Resolved, or False Positive.
- Generate Jira tickets — create tickets for selected findings (requires Jira integration).
What each status means¶
Findings move through a triage workflow:
┌──────────┐
│ Open │ (default for new findings)
└────┬─────┘
│
┌────────┼────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────────┐ ┌────────────────┐
│Confirmed│ │Accepted Risk │ │ False Positive │
└────┬────┘ └──────────────┘ └────────────────┘
│
▼
┌──────────┐
│ Resolved │
└──────────┘
| Status | Meaning | When to use |
|---|---|---|
| Open | New, untriaged finding. | Automatically assigned to all new findings. |
| Confirmed | Verified as a real issue that needs fixing. | After you have reviewed the code and confirmed the vulnerability is genuine. |
| Accepted Risk | Real issue, but you have decided not to fix it. | When the risk is low enough given your context, or a fix is not feasible. Document your reasoning. |
| Resolved | The vulnerability has been fixed. | After you deploy the fix. Mayo ASPM can also auto-resolve findings that disappear in subsequent scans. |
| False Positive | The scanner reported an issue that is not actually a vulnerability. | When the code is safe but the scanner's pattern matching flagged it incorrectly. |
Auto-resolution
When you re-scan a repository and a previously-found vulnerability no longer appears in the results, Mayo ASPM can automatically move it to Resolved. This keeps your findings list current without manual cleanup.
Understanding CWE and CVE identifiers¶
CWE (Common Weakness Enumeration)¶
CWEs categorize types of vulnerability. They answer the question: "What kind of bug is this?"
Examples:
- CWE-89 — SQL Injection
- CWE-79 — Cross-site Scripting (XSS)
- CWE-798 — Use of Hardcoded Credentials
- CWE-22 — Path Traversal
Click any CWE link in a finding to open the MITRE CWE database page with detailed descriptions, examples, and remediation guidance.
CVE (Common Vulnerabilities and Exposures)¶
CVEs identify specific known vulnerabilities in published software. They answer the question: "Is this a known, catalogued vulnerability?"
Examples:
- CVE-2024-1234 — Buffer overflow in libfoo 2.3.1
- CVE-2023-5678 — Authentication bypass in example-auth 1.0.0
CVEs are most common in dependency findings (from scanners like Trivy). Source-code findings typically have CWEs but not CVEs.
What to do next¶
After reviewing your findings, here are the recommended next actions:
1. Triage critical and high findings first¶
Filter for Critical and High severity. For each finding:
- Click through to the finding detail page.
- Read the code snippet and message.
- Determine if it is a genuine issue, a false positive, or an accepted risk.
- Update the status accordingly.
2. Focus on new findings¶
If this is not your first scan, filter for findings with a recent First seen date. These are newly introduced — they represent regression or new risk.
3. Generate tickets for confirmed findings¶
If you have Jira connected, select confirmed findings and click Create Jira Ticket. This pushes the finding into your team's existing workflow.
4. Enable PR scanning¶
To prevent new vulnerabilities from being introduced, enable PR scanning on your repository. This way, every pull request is scanned before it can merge.
Deep dive into findings management
For advanced workflows — filtering, triage, bulk operations, and more — see Findings.
Next steps¶
Now that you understand how to read findings, take a step back and learn the key concepts that underpin the entire platform.
:material-arrow-right: Next: Key Concepts