Skip to content

Sub-Projects

Sub-projects let you organize assets within a project into smaller groups. They inherit policies from their parent project while allowing overrides where needed.


When to use sub-projects

Sub-projects are useful when a single project contains assets that need different treatment:

Scenario Parent project Sub-projects
Monorepo with multiple services platform platform/auth, platform/billing, platform/gateway
Multi-environment payments-api payments-api/production, payments-api/staging
Team ownership mobile-app mobile-app/ios-team, mobile-app/android-team

Info

Sub-projects are optional. Many organizations work perfectly well with a flat project list. Add sub-projects only when you need finer-grained policy scoping or ownership.


Creating a sub-project

  1. Open the parent project.
  2. Click the Sub-projects tab.
  3. Click New Sub-project.
  4. Enter a name — this is appended to the parent name (e.g., parent platform + name auth = platform/auth).
  5. Optionally set an owner different from the parent.
  6. Click Create.

Via the API

curl -X POST https://mayoaspm.com/api/projects/{project_id}/sub-projects \
  -H "Authorization: Bearer mayo_ak_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "auth",
    "description": "Authentication service",
    "owner_id": "user_xyz"
  }'

Policy inheritance

Sub-projects inherit all policies from their parent by default. You can then:

  • Add policies that apply only to the sub-project
  • Override inherited policies with sub-project-specific versions
  • Exclude inherited policies so they don't apply to the sub-project
Parent: platform
├── Policy: triage-critical (inherited by all sub-projects)
├── Policy: priority-scoring (inherited by all sub-projects)
├── Sub: platform/auth
│   └── Policy: auth-specific-triage (additional)
├── Sub: platform/billing
│   └── Policy: pci-compliance (additional)
│   └── Policy: triage-critical (overridden with stricter rules)
└── Sub: platform/gateway
    └── (inherits parent policies only)

Tip

Use the Effective Policies view on any sub-project to see exactly which policies apply after inheritance and overrides are resolved.


Moving assets to sub-projects

Assets can be moved from the parent project into a sub-project:

  1. Open the parent project.
  2. Select the assets to move.
  3. Click Move to sub-project and choose the destination.

Assets in a sub-project still appear in the parent project's aggregate dashboards and finding counts.


Sub-project dashboards

Each sub-project has its own dashboard with:

  • Finding breakdown by severity
  • Policy compliance specific to that sub-project
  • Recent scan activity for assets in the sub-project
  • Owner and team information

The parent project dashboard shows aggregate numbers that include all sub-projects.


Limitations

Limitation Detail
Nesting depth Sub-projects cannot contain further sub-projects (max 2 levels)
Maximum count Up to 50 sub-projects per parent project
Naming Sub-project names must be unique within their parent
Deletion Deleting a sub-project moves its assets back to the parent

Filtering and searching

You can filter the global findings view by sub-project:

  1. Open Findings from the left sidebar.
  2. Click the Project filter.
  3. Expand a parent project to see its sub-projects.
  4. Select one or more sub-projects.

The API supports sub-project filtering as well:

curl "https://mayoaspm.com/api/findings?sub_project_id=sproj_abc123" \
  -H "Authorization: Bearer mayo_ak_..."

Best practices

  1. Don't over-subdivide — if you have fewer than 5 assets in a project, sub-projects add overhead without benefit.
  2. Use sub-projects for ownership — assign different teams as owners of different sub-projects within a shared domain.
  3. Leverage inheritance — define common policies at the parent level and only add overrides at the sub-project level.
  4. Name consistently — use a pattern like <parent>/<component> or <parent>/<environment>.

Next steps