Migratowl

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

A documented vulnerability response process is published at https://github.com/bitkaio/migratowl/blob/main/SECURITY.md including reporting channels (email security@bitkaio.com, GitHub Security Advisory), response SLAs by severity, coordinated disclosure policy, and scope.

The project uses ruff as its primary code style enforcer with PEP 8/pycodestyle (E), Pyflakes (F), isort (I), and pyupgrade (UP) rules. This is configured in pyproject.toml. CONTRIBUTING.md requires running the linter before submitting. See https://github.com/bitkaio/migratowl/blob/main/pyproject.toml

Coding standards are automatically enforced via ruff in the CI pipeline (ci.yml "Ruff lint" step) on every push and pull request to main. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

Migratowl is a Python project and does not compile native binaries. There are no C/C++ compiler or linker flags involved. The build system (uv/pip) does not apply.

This is a pure Python project. There are no compilation steps that would require preservation of debug information (CFLAGS/CXXFLAGS).

The project uses uv/pip for dependency management rather than a recursive build system like make. This criterion does not apply to Python packaging tools.

The project uses a uv.lock lockfile that pins all dependency versions, ensuring reproducible installs. The CI uses "uv sync --frozen" to enforce lockfile fidelity. See https://github.com/bitkaio/migratowl/blob/main/uv.lock

Installation is straightforward using uv: "uv sync" installs all dependencies. The Quick Start guide in README documents the full setup. See https://github.com/bitkaio/migratowl#quick-start

Migratowl is run as a server process, not installed as a system package with PREFIX/DESTDIR conventions. It uses uv for Python dependency management.

The README Quick Start section provides clear steps to get a development environment running: install uv, run "uv sync", configure .env, start minikube, and run uvicorn. See https://github.com/bitkaio/migratowl#quick-start

All external dependencies are listed in pyproject.toml in a machine-processable format, and pinned in uv.lock. See https://github.com/bitkaio/migratowl/blob/main/pyproject.toml

The project uses Renovate (renovate.json) for automated dependency updates, and runs pip-audit in CI (vulncheck job in ci.yml) to check for known vulnerabilities in dependencies on every push to main. See https://github.com/bitkaio/migratowl/blob/main/renovate.json

All reused components are managed via uv/pip using standard Python package management. Dependencies can be updated by modifying pyproject.toml and running "uv sync". Renovate automates dependency update PRs.

The project uses current, non-deprecated APIs. It requires Python >=3.13, uses Pydantic v2 (>=2.0), FastAPI >=0.115.0, and other modern dependencies. ruff's pyupgrade (UP) rules enforce migration away from deprecated Python patterns.

The CI pipeline (ci.yml) runs "uv run pytest tests/ -v --cov=migratowl" on every push and pull request to main via GitHub Actions. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/ci.yml

The README states "TDD is mandatory for all production code in migratowl/. The Red-Green-Refactor cycle is enforced: write a failing test first... No production code without a corresponding test in tests/." This policy ensures regression tests are added for all bugs fixed.

The README has a formal written 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 https://github.com/bitkaio/migratowl#development

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 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 implements secure design principles: fail-safe defaults (deny-all NetworkPolicy on sandbox pods), least privilege (runAsNonRoot, capabilities.drop: ALL, automountServiceAccountToken: false), input validation via Pydantic, and separation of untrusted code execution in Kubernetes sandboxes. See SECURITY.md and README architecture section.

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.

The project does not implement its own cryptographic algorithms. It uses HTTPX for HTTP communication which delegates to Python's ssl module. The project does not expose cryptographic algorithm configuration to users.

Authentication credentials (ANTHROPIC_API_KEY, GITHUB_TOKEN, GITLAB_TOKEN, etc.) are stored as environment variables and can be updated without modifying the application code. The .env.example documents all required credentials.

All network communications use HTTPS: the API server is exposed via HTTP but intended to be run behind a reverse proxy with TLS. Registry queries (PyPI, npm, crates.io, Maven, Go proxy) and Git provider APIs all use HTTPS. The httpx client is used for all outbound requests.

The project uses HTTPX for all outbound HTTP communication, which uses Python's ssl module and supports TLS 1.2 and TLS 1.3 by default. Older TLS versions are not supported by modern Python/OpenSSL.

HTTPX verifies TLS certificates by default (verify=True). The project does not disable certificate verification anywhere in the codebase.

HTTPX performs full TLS certificate verification before transmitting any data, which is the default behavior. The project does not override this setting.

Container image releases are cryptographically signed using cosign with keyless OIDC signing in the release.yml workflow. SLSA provenance is also generated for each release. See https://github.com/bitkaio/migratowl/blob/main/.github/workflows/release.yml

All API inputs are validated via Pydantic models (ScanWebhookPayload, etc.). FastAPI automatically rejects requests that fail Pydantic validation. The git_provider field uses Literal types to restrict to valid values. See https://github.com/bitkaio/migratowl/blob/main/migratowl/models/schemas.py

Security hardening is applied to sandbox pods: runAsNonRoot=true, allowPrivilegeEscalation=false, capabilities.drop=[ALL], automountServiceAccountToken=false, deny-all NetworkPolicy. The FastAPI API uses defusedxml for safe XML parsing. See README security defaults section.

SECURITY.md serves as the security assurance documentation, identifying key security requirements (sandbox escape prevention, API key protection, prompt injection defense, network policy enforcement) and the mechanisms in place to meet them. See https://github.com/bitkaio/migratowl/blob/main/SECURITY.md

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

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.