Glossary¶

Definitions of terms used throughout the Mayo ASPM documentation, listed alphabetically.

A¶

API Key: A long-lived credential (prefixed mayo_ak_) used to authenticate with the Mayo ASPM REST API. See API Keys.
Asset: A scannable unit in Mayo ASPM — typically a GitHub repository, container image, or uploaded artifact. Assets belong to projects.
Auto-project: A project created automatically when a new asset is discovered that doesn't match any existing project or project policy. See Auto-projects.

Base branch: The target branch of a pull request (e.g., main). PR scans compare the head branch against the base branch to find new findings.
Bi-directional sync: The mechanism by which status changes in Jira are reflected in Mayo ASPM and vice versa. When a Jira ticket is closed, the linked finding is resolved.

Check run: A GitHub feature that reports the pass/fail status of a PR scan. Mayo ASPM creates check runs via the GitHub Checks API.
Confirmed: A finding status indicating the finding has been accepted as actionable through triage. See Statuses.
CVE: Common Vulnerabilities and Exposures. A standardized identifier for publicly known security vulnerabilities (e.g., CVE-2026-1234).
CWE: Common Weakness Enumeration. A categorization system for software weaknesses (e.g., CWE-89 for SQL Injection).

Deferred: A triage decision that means the finding needs human review. Deferred findings appear in the triage queue.
Default Project: A catch-all project where assets are placed when no project policy matches and auto-projects are disabled.

EPSS: Exploit Prediction Scoring System. A score from 0.0 to 1.0 indicating the probability that a vulnerability will be exploited in the wild within the next 30 days.
Effective Policies: The resolved set of policies that actually apply to a project or sub-project, after inheritance and overrides are calculated.

Finding: A single security issue detected by a scanner. Findings have a severity, status, and belong to an asset and project.
Finding status: The lifecycle state of a finding: Open, Triaged, Confirmed, Suppressed, In Progress, Resolved, or Reopened.

Gitleaks: A secret detection scanner that finds hardcoded passwords, API keys, and tokens in source code.
Grype: An SCA (Software Composition Analysis) scanner that detects known vulnerabilities in project dependencies by matching against CVE databases.

Head branch: The source branch of a pull request — the branch containing the new code being proposed for merge.

IaC: Infrastructure as Code. Configuration files (Terraform, CloudFormation, etc.) that define infrastructure. Trivy can scan IaC for misconfigurations.
Input: The JSON object provided to an OPA policy for evaluation. Each policy kind receives a different input structure.

JWT: JSON Web Token. A short-lived authentication token used for browser-based sessions in Mayo ASPM.

KEV: CISA Known Exploited Vulnerabilities catalog. A list maintained by CISA of vulnerabilities that are actively exploited in the wild.

OPA: Open Policy Agent. The policy engine used by Mayo ASPM to evaluate Rego policies for triage, priority, ownership, project mapping, and PR scan decisions.
Ownership policy: A policy that assigns findings to teams or individuals based on asset, file path, or other attributes.

Policy: A set of Rego rules that automate a security decision. Mayo ASPM supports five policy kinds: triage, priority, ownership, project, and PR scan.
Policy kind: The type of decision a policy makes. Each kind has its own package name, input schema, and output variables.
Priority policy: A policy that assigns a numeric priority score (0-100) to triaged findings.
PR Scan: A scan triggered by a pull request event. PR scans are differential — they only report findings introduced by the PR.
PR Scan policy: A policy that determines whether a PR passes or fails the security gate based on scan results.
Project: The primary organizational unit in Mayo ASPM. Projects group assets, findings, and policies.
Project policy: A policy that maps assets to projects based on attributes like repository name, language, or topics.

Rego: The query language used by OPA. Mayo ASPM uses Rego v1 syntax.
Resolved: A finding status indicating the issue has been fixed and verified.

SCA: Software Composition Analysis. Scanning technique that identifies known vulnerabilities in third-party dependencies.
SAST: Static Application Security Testing. Scanning technique that analyzes source code for vulnerability patterns.
Scanner: A tool that analyzes code or configurations to find security issues. Mayo ASPM supports Grype, Trivy, Semgrep, and Gitleaks.
Scope: The level at which a policy applies: organization, project, or sub-project.
Semgrep: A SAST scanner that uses pattern matching to find code-level vulnerabilities across 30+ languages.
Sub-project: A child project that inherits policies from its parent. Used for organizing within a project.
Suppressed: A finding status indicating the finding was rejected during triage as noise or a false positive.

Triage: The process of evaluating a finding and deciding whether it is actionable (accept), noise (reject), or needs review (defer).
Triage funnel: The pipeline that processes findings through triage policies, producing accept/reject/defer decisions at scale.
Triage policy: A policy that assigns a triage decision (accept, reject, defer) to incoming findings.
Trivy: A comprehensive scanner supporting SCA, container image scanning, and IaC scanning.

Version (policy): A snapshot of a policy at a point in time. Every save creates a new version. Versions can be compared and rolled back.

Webhook: An HTTP callback that delivers real-time event notifications. Mayo ASPM uses webhooks to receive GitHub events and Jira status changes.