Migratowl

The source code is publicly hosted on GitHub at https://github.com/bitkaio/migratowl with full history accessible to everyone.

The project uses Git (hosted on GitHub) which tracks all changes, authors, and timestamps. Every commit records who made the change and when. See https://github.com/bitkaio/migratowl/commits/main

The main branch receives frequent interim commits between releases. All development work is committed to the repository before release, as evidenced by the detailed commit history on GitHub.

The project uses Git, a distributed version control system. The repository is publicly accessible and can be cloned by anyone, enabling distributed development.

Each release has a unique version identifier following Semantic Versioning (v0.1.0, v0.2.0, v0.3.0). Versions are set in pyproject.toml and tagged in the git repository. See https://github.com/bitkaio/migratowl/blob/main/pyproject.toml

The project follows Semantic Versioning (semver.org) as stated in CHANGELOG.md: "this project adheres to Semantic Versioning". Current version is 0.3.0, with the format MAJOR.MINOR.PATCH. See https://github.com/bitkaio/migratowl/blob/main/CHANGELOG.md

Every release is tagged in Git with the "v" prefix (v0.1.0, v0.2.0, v0.3.0). The release.yml workflow triggers on "v*" tag pushes, building and signing the Docker image. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/release.yml

A CHANGELOG.md following the "Keep a Changelog" format documents all notable changes for each release. Each version entry lists Added, Changed, and Fixed items with detailed descriptions. See https://github.com/bitkaio/migratowl/blob/main/CHANGELOG.md

The CHANGELOG.md documents all notable changes per release including security-relevant fixes. The SECURITY.md coordinated disclosure policy ensures vulnerabilities are documented when resolved. See https://github.com/bitkaio/migratowl/blob/main/CHANGELOG.md

CONTRIBUTING.md documents the bug reporting process: "Use GitHub Issues for bug reports and feature requests. For bugs, include: steps to reproduce, expected behavior, actual behavior, and environment details. Check existing issues before opening a new one." See https://github.com/bitkaio/migratowl/blob/main/CONTRIBUTING.md

The project uses GitHub Issues as its issue tracker for all individual bug reports and feature requests. Issues are publicly visible and include labels, milestones, and assignment. See https://github.com/bitkaio/migratowl/issues

The project maintainers respond to bug reports via GitHub Issues. CONTRIBUTING.md acknowledges the process and encourages opening issues for questions and problems.

Enhancement requests are tracked via GitHub Issues. CONTRIBUTING.md directs contributors to "Open an issue first" before submitting a PR for new features. See https://github.com/bitkaio/migratowl/blob/main/CONTRIBUTING.md

All bug reports and enhancements are permanently archived in the public GitHub Issues tracker at https://github.com/bitkaio/migratowl/issues. GitHub retains issue history indefinitely.

A dedicated SECURITY.md documents the full vulnerability reporting process: private reporting channels (security@bitkaio.com and GitHub Security Advisory), required information to include, severity-based response SLAs (e.g., Critical: 48h acknowledgement, 5 business days resolution), coordinated disclosure policy, and scope. See https://github.com/bitkaio/migratowl/blob/main/SECURITY.md

N/A — the project has not had any publicly known vulnerabilities since its initial release in April 2026. The SECURITY.md specifies private reporting channels (email and GitHub Security Advisory) for responsible disclosure.

SECURITY.md defines response SLAs: Critical vulnerabilities receive acknowledgement within 48 hours and resolution within 5 business days. High within 48h / 7 days, Medium 5 business days / 30 days. See https://github.com/bitkaio/migratowl/blob/main/SECURITY.md

The project uses uv as its build and dependency management tool. Running "uv sync" installs all dependencies from the lockfile. The server is started with "uv run uvicorn migratowl.api.main:app --reload". See https://github.com/bitkaio/migratowl#quick-start

The project uses standard, widely-available Python tooling: uv (package manager), uvicorn (ASGI server), and Docker/kubectl for Kubernetes. All are FLOSS tools with broad platform support.

N/A — Migratowl is a Python application. It does not produce compiled native binaries and does not require proprietary build tools. All tooling (uv, ruff, pytest, mypy) is open source.

The project has an automated test suite using pytest located in the tests/ directory, which mirrors the migratowl/ package structure. Tests are run with "uv run pytest tests/ -v". See https://github.com/bitkaio/migratowl/tree/main/tests

Tests can be invoked with a single command: "uv run pytest tests/ -v". This is documented in the Development table in the README. See https://github.com/bitkaio/migratowl#development

The README mandates TDD for all production code: "TDD is mandatory for all production code in migratowl/. No production code without a corresponding test in tests/." The test suite covers the core functionality of the migratowl package.

GitHub Actions CI runs the full test suite (pytest) on every push and pull request to the main branch, via the lint-and-test job in ci.yml. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

The README states an explicit TDD policy: "TDD is mandatory for all production code in migratowl/. The Red-Green-Refactor cycle is enforced: write a failing test first, confirm RED, write minimal code to pass, confirm GREEN, then refactor. No production code without a corresponding test in tests/. See CLAUDE.md for details." See https://github.com/bitkaio/migratowl#development

The TDD policy in the README requires tests to be written before production code. The CI enforces this by running the full test suite on every PR; PRs that break tests cannot be merged.

The PR template (.github/PULL_REQUEST_TEMPLATE.md) includes a mandatory checklist item "New/updated tests added". CONTRIBUTING.md states "Include tests for new functionality and bug fixes". Both together ensure tests are required for contributions. See https://github.com/bitkaio/migratowl/blob/main/.github/PULL_REQUEST_TEMPLATE.md

The project uses ruff with rules E (pycodestyle), F (Pyflakes), I (isort), and UP (pyupgrade) — all configured in pyproject.toml. Mypy is used for static type checking. Both tools are run in CI on every push and PR. See https://github.com/bitkaio/migratowl/blob/main/pyproject.toml

Ruff is configured with --error mode in CI (ci.yml "Ruff lint" step), which causes the build to fail if any lint warnings are present. All warnings must be resolved before code can be merged. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

The project enables strict linting with ruff (E, F, I, UP rule sets) and requires type annotations on all new function signatures (per PR template checklist). Mypy enforces type safety with --ignore-missing-imports. Both are blocking in CI.

The project README and SECURITY.md document secure design principles applied throughout: deny-all NetworkPolicy on sandbox pods, non-root container execution (runAsNonRoot=true), dropped Linux capabilities, no service account token auto-mounting, defusedxml for safe XML parsing, and Pydantic input validation.

The CI pipeline runs Semgrep with the p/owasp-top-ten and p/security-audit rule sets to detect OWASP Top 10 vulnerabilities. Bandit performs Python-specific security checks. Developers are thus informed about common security errors before code is merged.

N/A — Migratowl does not implement any cryptographic algorithms. It relies entirely on standard library TLS via HTTPX/Python ssl module for transport security.

N/A — The project does not implement cryptographic primitives. All cryptographic operations are handled by the underlying httpx/OpenSSL stack.

N/A — Migratowl does not bundle or implement its own cryptographic routines.

N/A — The project does not configure cryptographic key lengths. TLS parameters are managed by the system OpenSSL/Python ssl module defaults.

N/A — The project does not implement cryptographic hash functions or encryption directly.

N/A — Migratowl is a backend orchestration service that does not implement its own cryptographic mechanisms. TLS is handled entirely by the httpx library using Python's ssl module (OpenSSL), which uses modern cipher suites and does not support deprecated algorithms like MD4, RC4, or DES by default.

N/A — Perfect forward secrecy is handled at the TLS layer by the httpx/OpenSSL stack, not implemented by the project itself.

N/A — Migratowl does not store user passwords. Authentication credentials (API keys, tokens) are read from environment variables at runtime.

N/A — The project does not generate cryptographic random numbers directly. Job IDs use Python's uuid.uuid4() which uses a cryptographically secure source.

All distribution channels use HTTPS: the GitHub repository (https://github.com/bitkaio/migratowl), container registry (ghcr.io), and documentation. Container images are additionally signed using cosign with keyless OIDC signing, providing cryptographic integrity verification. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/release.yml

Container image releases are signed using cosign with OIDC keyless signing in the release workflow. SLSA Level 3 provenance is generated for every release. Source code is distributed via GitHub over HTTPS with git integrity guarantees. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/release.yml

The project is new (first release April 2026) and has no known publicly disclosed vulnerabilities. The SECURITY.md defines response SLAs: Critical vulnerabilities are resolved within 5 business days, High within 7 days. See https://github.com/bitkaio/migratowl/blob/main/SECURITY.md

No critical vulnerabilities have been publicly disclosed against Migratowl. The CI pipeline runs pip-audit on every push to main to detect known CVEs in dependencies, and the SECURITY.md mandates a 5 business day resolution target for Critical severity issues.

The repository has no hardcoded credentials. All secrets (ANTHROPIC_API_KEY, GITHUB_TOKEN, GITLAB_TOKEN, etc.) are read from environment variables defined in .env (which is git-ignored). The .env.example file shows only placeholder values. The CI uses GitHub Actions secrets. See https://github.com/bitkaio/migratowl/blob/main/.env.example

The CI runs three complementary FLOSS static analysis tools on every push and PR: (1) Semgrep with p/python, p/security-audit, p/owasp-top-ten, and p/docker rule sets in --error mode; (2) Bandit for Python-specific security checks; (3) Mypy for static type analysis. zizmor analyzes GitHub Actions workflow files for security issues. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

Semgrep is configured with p/security-audit (general security issues) and p/owasp-top-ten (OWASP Top 10 vulnerabilities) rule sets, run in --error mode so any finding blocks the CI. Bandit provides additional Python-specific security checks (injection, subprocess usage, etc.). See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

Static analysis runs in CI with --error flags, meaning any finding blocks merging. Ruff, Semgrep, and Bandit results must all be clean before a PR can be merged into main.

Static analysis tools (ruff, mypy, Semgrep, Bandit, zizmor, Hadolint) all run automatically on every push and pull request to main via GitHub Actions CI. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

The project runs pytest with coverage on every CI run, which exercises code paths dynamically. The release workflow runs Trivy container image scanning to detect runtime vulnerabilities in the Docker image. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

Migratowl is written entirely in Python, which is a memory-safe language. There is no C, C++, or other memory-unsafe code in the project, so memory safety dynamic analysis tools (ASAN, valgrind, etc.) are not applicable.

Python assertions and Pydantic runtime validation are active in all test runs. Pytest is run without the -O flag, so Python assertions remain enabled during testing.

Any dynamic analysis findings (test failures, Trivy vulnerabilities, pip-audit CVEs) block the CI pipeline and must be resolved before merging. The scheduled.yml workflow re-runs checks periodically.