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¶
- Open the parent project.
- Click the Sub-projects tab.
- Click New Sub-project.
- Enter a name — this is appended to the parent name (e.g., parent
platform+ nameauth=platform/auth). - Optionally set an owner different from the parent.
- 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:
- Open the parent project.
- Select the assets to move.
- 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:
- Open Findings from the left sidebar.
- Click the Project filter.
- Expand a parent project to see its sub-projects.
- 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¶
- Don't over-subdivide — if you have fewer than 5 assets in a project, sub-projects add overhead without benefit.
- Use sub-projects for ownership — assign different teams as owners of different sub-projects within a shared domain.
- Leverage inheritance — define common policies at the parent level and only add overrides at the sub-project level.
- Name consistently — use a pattern like
<parent>/<component>or<parent>/<environment>.
Next steps¶
- Policy scoping — assign policies at the project or sub-project level
- Projects overview — return to the projects overview