Skip to content

Security Scanning

Security scanning is the core capability of Mayo ASPM. Scans analyze your source code and dependencies to identify vulnerabilities, secrets, and code quality issues — then normalize the results into a unified findings model for triage and remediation.

What Scanning Does

When a scan runs against one of your assets, Mayo ASPM:

  1. Clones the repository at the specified branch
  2. Executes the selected scanner with the configured rule set
  3. Parses the scanner output into Mayo ASPM's normalized finding format
  4. Deduplicates findings against existing results using fingerprint matching
  5. Stores the findings linked to the asset, project, and scan record
  6. Evaluates OPA policies (if configured) to auto-triage, assign priority, or route findings

The entire process is automated — you configure and trigger, Mayo ASPM handles the rest.

Supported Scanners

Mayo ASPM ships with five built-in scanners spanning three categories:

Scanner Category What It Detects
OpenGrep SAST (Static Analysis) Code-level vulnerabilities, injection flaws, insecure patterns
Semgrep SAST (Static Analysis) Code-level vulnerabilities, custom rules, security anti-patterns
Trivy SCA (Software Composition Analysis) Vulnerable dependencies, outdated packages, license issues
Grype SCA (Software Composition Analysis) Vulnerable dependencies, CVE matching against SBOM
Gitleaks Secrets Detection Hardcoded API keys, tokens, passwords, certificates in source code

Scanner Updates

Scanner rule databases and vulnerability feeds are updated automatically. You always scan against the latest known vulnerabilities without manual intervention.

SAST Scanners (OpenGrep & Semgrep)

Static Application Security Testing scanners analyze your source code without executing it. They look for patterns that indicate security vulnerabilities:

  • SQL injection, XSS, command injection
  • Insecure cryptographic usage
  • Authentication and authorization flaws
  • Hardcoded credentials in application code
  • Framework-specific security misconfigurations

SCA Scanners (Trivy & Grype)

Software Composition Analysis scanners examine your dependency manifests (package.json, requirements.txt, go.mod, etc.) and match them against vulnerability databases:

  • Known CVEs in third-party libraries
  • Outdated packages with available security patches
  • Transitive dependency vulnerabilities
  • License compliance issues (Trivy)

Secrets Scanner (Gitleaks)

Gitleaks scans your repository's full file tree for secrets that should not be committed to version control:

  • API keys (AWS, GCP, Azure, Stripe, etc.)
  • OAuth tokens and refresh tokens
  • Database connection strings with credentials
  • Private keys and certificates
  • Generic high-entropy strings matching secret patterns

Three Scan Modes

Mayo ASPM supports three distinct ways to trigger scans:

1. Ad-Hoc Scans

On-demand scans triggered manually from the Assets page. You select the scanner, rule set, and branch — then Mayo ASPM executes the scan immediately (or queues it if capacity is full).

Best for: One-off assessments, scanning a specific branch, testing a new rule set, or investigating a suspected vulnerability.

See Ad-Hoc Scans for details.

2. Scheduled Scans

Automated nightly scans that run across all active assets in your organization. Scheduled via an Airflow DAG, these scans ensure your security posture is continuously evaluated without manual intervention.

Best for: Continuous monitoring, compliance requirements, catching newly disclosed CVEs in existing code.

See Scheduled Scans for details.

3. PR Scans

Scans triggered automatically when a pull request is opened or updated on a repository with PR scanning enabled. Results are posted as GitHub comments and check runs directly on the PR.

Best for: Shift-left security, blocking vulnerabilities before they reach the default branch, developer feedback loops.

See PR Scanning for details.

Scan Lifecycle

Every scan follows a predictable lifecycle through these states:

┌──────────┐     ┌──────────┐     ┌─────────────┐
│  Queued  │────▶│ Running  │────▶│  Completed  │
└──────────┘     └──────────┘     └─────────────┘
                      │
                      │           ┌─────────────┐
                      └──────────▶│   Failed    │
                                  └─────────────┘

┌──────────┐
│ Cancelled│  (user-initiated from queue)
└──────────┘
State Description
Queued The scan has been submitted and is waiting for scanner capacity. Scans are processed first-in-first-out within their priority tier.
Running The scanner is actively executing. A progress indicator shows elapsed time.
Completed The scan finished successfully. Findings have been parsed, deduplicated, and stored.
Failed The scan encountered an error (e.g., repository clone failure, scanner crash, timeout). Error details are available in the scan record.
Cancelled The user cancelled the scan from the Scan Queue page before it started running.

Scan Duration

Scan duration depends on repository size, scanner type, and rule set complexity. Typical scans complete in 30 seconds to 5 minutes. Large monorepos with comprehensive rule sets may take longer. See Scanner Reference for typical timing by scanner.

Findings from Scans

Each completed scan produces zero or more findings. Findings are deduplicated using a fingerprint that combines:

  • Scanner type
  • Rule ID
  • File path
  • Code snippet hash

If a scan detects the same issue that was found in a previous scan, the existing finding is updated rather than duplicated. This means your findings count reflects unique issues, not cumulative scan noise.

See Findings Overview for the complete findings model.

Scan Capacity and Quotas

The number of concurrent scans you can run depends on your plan tier:

Plan Max Concurrent Scans Max Queue Depth Max Scan Duration
Free 1 5 10 minutes
Pro 3 20 30 minutes
Enterprise 10 100 60 minutes

See Scan Queue for monitoring your current capacity usage.

Next Steps