Key Concepts¶
Mayo ASPM is built around a small set of interconnected concepts. Understanding how they relate to each other makes the entire platform intuitive. This page is a reference you can return to any time.
The big picture¶
Organization
├── Members (users with roles)
├── Integrations
│ ├── GitHub App (connects to repositories)
│ ├── Jira (connects to issue tracker)
│ └── API Keys (connects to automation)
├── Assets (repositories)
│ ├── Scan Runs
│ │ └── Findings
│ └── Branches
├── Projects (groups of assets)
│ └── Findings (aggregated from assets in the project)
└── Policies (OPA/Rego rules)
├── Triage Policies
├── Priority Policies
├── Ownership Policies
├── Project Policies
└── PR Scan Policies
Organizations¶
An organization is the top-level container. Everything in Mayo ASPM belongs to an organization.
| Attribute | Description |
|---|---|
| Name | Human-readable identifier (e.g., "Acme Corp"). |
| Members | Users who belong to the org, each with a role (Owner, Admin, Member, Viewer). |
| Billing tier | Free, Pro, or Enterprise. Determines limits and available features. |
| Settings | Global preferences, integrations, default policies. |
Multi-org support
A single user account can belong to multiple organizations. This is common for consultants, contractors, or developers who work across several companies. Use the organization switcher in the top-left corner of the dashboard to move between orgs.
What lives inside an organization¶
Everything: assets, findings, projects, policies, integrations, team members, and billing. Deleting an organization removes all of this permanently.
Assets¶
An asset represents a single code repository. Assets are the primary unit of scanning — you scan an asset, and findings are attached to it.
| Attribute | Description |
|---|---|
| Name | The repository name (e.g., acme/backend-api). |
| Source | Where the code lives — typically a GitHub repository linked through the GitHub App. Can also be a manually-added public repository. |
| Branches | The branches available for scanning, synced from GitHub. |
| Default branch | The branch that is scanned by default (usually main or master). |
| Language breakdown | Detected programming languages and their proportions. |
| Findings count | Total number of open findings across all scans. |
How assets are created¶
Assets are created in two ways:
- Automatically — when you install the GitHub App and select repositories, each repository becomes an asset.
- Manually — you can add a public repository by URL from the Assets page. See Adding Public Repos.
Findings¶
A finding is a single vulnerability or security issue detected by a scanner. Findings are the core of Mayo ASPM — they represent the things you need to pay attention to.
| Attribute | Description |
|---|---|
| Title | Human-readable summary of the vulnerability. |
| Severity | Critical, High, Medium, Low, or Info. |
| Status | Triage state: Open, Confirmed, Accepted Risk, Resolved, False Positive. |
| Scanner | Which scanner produced this finding. |
| Rule | The specific rule that triggered. |
| CWE / CVE | Standardized vulnerability identifiers. |
| File path | Relative path to the affected file. |
| Line number | The specific line of code. |
| Code snippet | Surrounding code context. |
| First seen | The date this finding was first detected. |
| Last seen | The date of the most recent scan that confirmed this finding still exists. |
| Asset | The repository (asset) this finding belongs to. |
Finding deduplication¶
Mayo ASPM deduplicates findings across scans. If the same vulnerability (same rule, same file, same line range) appears in consecutive scans, it is treated as the same finding — not a new one. This prevents finding counts from inflating every time you scan.
Deduplication keys
Deduplication is based on: scanner + rule ID + file path + line range. If you rename a file or the vulnerability moves to a different line, Mayo ASPM creates a new finding and may auto-resolve the old one.
Scan Runs¶
A scan run (or simply "scan") is a single execution of a scanner against an asset's codebase. It produces findings.
| Attribute | Description |
|---|---|
| Scanner | Which scanner was used (Semgrep, Bandit, Trivy, etc.). |
| Branch | Which branch was scanned. |
| Status | Queued, Running, Completed, or Failed. |
| Duration | How long the scan took. |
| Finding counts | New, existing, fixed, and total findings from this scan. |
| Trigger | How the scan was initiated: manual (ad-hoc), scheduled, or PR event. |
Types of scan triggers¶
| Trigger | Description |
|---|---|
| Ad-hoc | Manually started by a user from the Assets page or API. |
| Scheduled | Automatically started on a cron schedule (e.g., nightly). |
| PR event | Automatically started when a pull request is opened or updated on GitHub. |
Projects¶
A project is an organizational group of one or more assets. Projects help you structure your security posture by team, application, business domain, or any other grouping that makes sense for your organization.
| Attribute | Description |
|---|---|
| Name | Human-readable name (e.g., "Payment Service" or "Frontend Team"). |
| Assets | The repositories belonging to this project. |
| Aggregated findings | The combined findings from all assets in the project. |
| Sub-projects | Projects can be nested for hierarchical organization. |
Auto-created projects¶
When a repository syncs from GitHub, Mayo ASPM automatically creates a project with the same name. You can:
- Rename the project to something more meaningful.
- Merge multiple auto-created projects into a single project (e.g., group all microservice repos under one "Backend" project).
- Add sub-projects for multi-level organization.
Use projects to map your architecture
Projects work best when they reflect how your team thinks about the codebase. If you have a "payments" domain with three microservices, create a "Payments" project and add all three repos as assets.
Policies¶
A policy is an OPA (Open Policy Agent) / Rego rule that automates decisions about findings, scans, and projects. Policies are what make Mayo ASPM scale — instead of manually triaging every finding, you write rules that do it for you.
| Policy kind | What it automates |
|---|---|
| Triage policy | Automatically sets the status of findings based on criteria (e.g., auto-close Low-severity info findings). |
| Priority policy | Assigns a priority score or label to findings beyond the scanner's severity. |
| Ownership policy | Assigns findings to teams or individuals based on file path, project, or other attributes. |
| Project policy | Automatically maps assets to projects based on naming patterns, topics, or other repo metadata. |
| PR scan policy | Decides whether a PR scan should block the merge, warn, or allow — based on finding severity, count, or other criteria. |
Policies are optional
You do not need to write any policies to use Mayo ASPM. They become valuable as your organization scales and manual triage becomes unsustainable. See OPA Policies for a full guide.
Integrations¶
Integrations connect Mayo ASPM to external systems.
| Integration | Purpose |
|---|---|
| GitHub App | Connect repositories, enable PR scanning, receive webhook events. |
| Jira | Generate and sync Jira tickets from findings. |
| API Keys | Authenticate REST API requests for custom automation. |
| Airflow | Trigger scans on a schedule using Apache Airflow DAGs. |
Integrations are configured per-organization from Settings > Integrations.
How everything connects¶
Here is the relationship diagram showing how concepts reference each other:
┌──────────────────────────────────────────────────────────────┐
│ ORGANIZATION │
│ │
│ ┌──────────┐ syncs from ┌────────────────────────┐ │
│ │ GitHub │ ───────────────> │ Assets (repositories) │ │
│ │ App │ webhooks │ │ │
│ └──────────┘ <──────────────── │ ┌──────────────────┐ │ │
│ │ │ Scan Runs │ │ │
│ ┌──────────┐ tickets from │ │ └─> Findings │ │ │
│ │ Jira │ <──────────────── │ └──────────────────┘ │ │
│ └──────────┘ └────────────┬───────────┘ │
│ │ │
│ ┌──────────────────┐ groups │ │
│ │ Projects │ <─────────────────────-┘ │
│ │ └─> Sub-projects│ │
│ └──────────────────┘ │
│ │
│ ┌──────────────────┐ acts on findings, assets, PRs │
│ │ Policies (OPA) │ ─────────────────────────────────────> │
│ └──────────────────┘ │
│ │
│ ┌──────────────────┐ │
│ │ Members │ (Owner, Admin, Member, Viewer) │
│ └──────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Key relationships¶
- An organization has many assets, projects, policies, integrations, and members.
- An asset belongs to one organization and can belong to one or more projects.
- A scan run belongs to one asset and produces zero or more findings.
- A finding belongs to one asset and one scan run (the scan that first detected it). It persists across scans.
- A project contains one or more assets and optionally contains sub-projects.
- A policy is scoped to the organization and can target specific assets, projects, or all resources.
Summary table¶
| Concept | One-line definition | Created by |
|---|---|---|
| Organization | Top-level container for all resources | User during sign-up |
| Asset | A code repository | GitHub App sync or manual addition |
| Finding | A single detected vulnerability | Scanner during a scan run |
| Scan Run | One execution of a scanner against an asset | User (ad-hoc), schedule, or PR event |
| Project | Organizational group of assets | Auto-created per repo, customizable |
| Policy | OPA/Rego rule that automates decisions | User in the Policies editor |
| Integration | Connection to an external system | User in Settings > Integrations |
You now have a solid understanding of how Mayo ASPM is structured. From here, explore the features in depth or jump to a specific area: