Selecting repositories
The dropdown is populated from the repositories you connected in Step 1: Connect GitHub. Select every repository that is directly involved in the scope of this test. Maximum: 4 repositories per run.All selected repositories should tie directly to the target URLs you defined in Step 2: Scope & Connectivity. If a repo isn’t involved in serving or supporting those URLs, leave it out.
How many repos to include
| Situation | What to select |
|---|---|
| Single full-stack repo | Just that one repo (ideal) |
| Separate frontend + backend | Both repos |
| Frontend + backend + infrastructure (IaC) | All three |
| Monorepo with multiple services | The monorepo. Mjolnir navigates it. |
Why the 4-repo limit?
Mjolnir performs deep analysis of every file in every selected repository. Beyond 4 repos, the analysis time increases significantly without proportional benefit. If your application spans more than 4 repos, prioritise the ones closest to your attack surface (backend API, auth service, core frontend).Branches and monorepo subdirectories
For each selected repository, you can choose a specific branch (defaults to your repo’s default branch) and, for monorepos, a subdirectory to scope Mjolnir to a single service.File uploads
In addition to your source code, you can upload supplementary files that help Mjolnir understand your application’s architecture, data model, and intended behaviour. The more context Mjolnir has, the more targeted and accurate the assessment. This step is optional — Mjolnir works from source code alone, but supporting docs almost always improve coverage.OpenAPI / Swagger specification (recommended)
OpenAPI / Swagger specification (recommended)
Accepted formats:
.json, .yaml, .ymlAn OpenAPI spec is the most valuable thing you can provide beyond source code. It gives Mjolnir a structured map of your API endpoints, request/response schemas, authentication requirements, and parameter types, without inferring all of this from crawling.If you have one, upload it. If you have several (e.g. v2 and v3), upload all of them.Common locations in a project:openapi.json/openapi.yamlin the rootdocs/api.yaml- Auto-generated at
/api-docsor/swagger.jsonat runtime (export it and upload the file)
Architecture documentation
Architecture documentation
Accepted formats:
.pdf, .md, .txt, .docxAny documentation that describes your application’s architecture, data flows, or infrastructure topology. This helps Mjolnir understand the relationship between components, which is especially useful for microservice architectures where the attack surface spans multiple services.User role definitions / permission matrix
User role definitions / permission matrix
Accepted formats:
.json, .yaml, .pdf, .mdA description of your application’s roles and what each one can and cannot do. This directly improves the quality of privilege escalation tests — Mjolnir can check whether every boundary in your permission model is actually enforced.Examples:- A table showing which roles can access which endpoints
- A RBAC/ABAC configuration file
- A narrative description of your permission model
User journeys / workflows
User journeys / workflows
Accepted formats:
.pdf, .png, .mdDescriptions or diagrams of the key user flows in your application: signup, checkout, approval workflows, data export, and so on. This helps Mjolnir prioritise which flows carry the most business risk.Other
Other
Anything else you think would help. When in doubt, include it. Mjolnir will use what’s relevant and ignore what isn’t.
How to upload
Drag and drop files onto the upload area, or click to open a file picker. Each uploaded file shows its name, detected type, and size. Mjolnir auto-detects the document type but you can override the classification before launch. Remove any file with the trash icon before proceeding.Next: Pricing
Choose your Mjolnir tier and confirm payment