Skip to content

Organizing Your Security Program

This guide helps you structure your Mayo ASPM deployment to support an effective application security program — from project layout to team workflows.

Project structure

By service / application

The most common approach. Each microservice, application, or library gets its own project:

payments-api
auth-service
mobile-app
shared-libraries
infrastructure

Best for: Microservices architectures, teams with clear ownership boundaries.

By business domain

Group related repositories into domain projects:

payments (payments-api, payments-web, payments-worker)
identity (auth-service, sso-proxy, user-management)
mobile   (mobile-ios, mobile-android, mobile-bff)

Best for: Organizations with cross-functional domain teams.

By team

Map projects to organizational teams:

team-alpha   (service-a, service-b)
team-beta    (service-c, service-d)
platform     (infrastructure, ci-cd, monitoring)

Best for: Small organizations where team and service boundaries overlap.

Use project policies to automate

Write a project policy that maps repositories to projects based on GitHub topics, naming conventions, or org structure. This eliminates manual project assignment.

Team setup

Roles in Mayo ASPM

Role Responsibility Mayo ASPM permissions
Security lead Configure policies, review triage decisions, monitor program metrics Admin
Security engineer Write and maintain policies, investigate complex findings Policy Editor
Engineering lead Review team findings, manage ticket flow, adjust priority Project Admin
Developer Remediate findings, resolve tickets Viewer + findings:write

Team-based ownership

Set up teams in Mayo ASPM that match your organizational structure:

  1. Go to Settings > Teams.
  2. Create teams that mirror your engineering org.
  3. Add members to each team.
  4. Write ownership policies to route findings to the right team.

Week 1 — Connect and scan

  1. Install the GitHub App on your organization.
  2. Select your most critical repositories (5-10).
  3. Run an initial scan with SCA (Grype) and secrets detection (Gitleaks).
  4. Review findings to understand the baseline.

Week 2 — Organize and triage

  1. Organize assets into projects (manually or via project policy).
  2. Write basic triage policies:
    • Auto-accept critical and high severity findings
    • Auto-reject informational findings
    • Suppress findings in test directories
  3. Activate policies and monitor the triage queue.

Week 3 — Prioritize and ticket

  1. Write a priority scoring policy.
  2. Connect Jira.
  3. Generate tickets for the top 10 critical/high findings.
  4. Work with developers to close the first batch.

Week 4 — Expand

  1. Add SAST scanning (Semgrep).
  2. Enable PR scanning for the most active repositories.
  3. Write scanner-specific triage rules based on Week 2-3 noise patterns.
  4. Expand to all repositories.

Month 2+ — Mature

  1. Write ownership policies.
  2. Set up nightly scans via Airflow.
  3. Target 80%+ triage automation rate.
  4. Add container scanning if applicable.

Workflow patterns

Finding lifecycle

New finding → Triage (policy) → Prioritize (policy) → Assign (policy)
     → Generate ticket → Developer remediates → Verify in next scan → Close

Weekly security review

  1. Open the Triage Queue — review deferred findings.
  2. Check the Findings Dashboard — monitor trends by severity and project.
  3. Review Policy Effectiveness — check automation rate and false positive reports.
  4. Update policies based on patterns from manual triage.

Incident response integration

When a zero-day is announced:

  1. Search findings by CVE ID.
  2. Use the API to query across all projects.
  3. Generate tickets for affected assets.
  4. Track remediation progress on the findings dashboard.

Metrics to track

Metric Description Goal
Coverage % of repositories scanned 100%
Automation rate % of findings auto-triaged > 80%
MTTT Mean time to triage < 24 hours
MTTR (critical) Mean time to remediate critical findings < 7 days
MTTR (high) Mean time to remediate high findings < 30 days
Open critical count Number of open critical findings 0

Next steps