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
Why the 4-repo limit?
Odin 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 the pentest to a single service.File uploads
In addition to your source code, you can upload supplementary files that help Odin understand your application’s architecture, data model, and intended behaviour. The more context Odin has, the more targeted and accurate the assessment. This step is optional — Odin 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 Odin 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 Odin 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 — Odin 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 Odin prioritise which flows carry the most business risk.Other
Other
Anything else you think would help. When in doubt, include it. Odin 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. Odin 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 plan tier. This step is skipped if your organisation already has an active plan.