Reviewing multi-repository and polyglot architectures for cross-service vulnerabilities

Key takeaways

• Modern applications frequently split authentication, API gateways, domain services and worker queues across multiple repositories and programming languages.
• Reviewing each repository in complete isolation misses trust-boundary mismatches, where Service A assumes Service B validated a tenant ID or webhook signature, and Service B assumes Service A already did.
• Rule-based SAST tools are typically bound to a single language parser and a single repository tree at a time.
• Dokima discovers and tracks multiple Git repositories inside a unified workspace, mapping component boundaries across Go, TypeScript, Python, Rust, Java and C# codebases together.

Why do the hardest vulnerabilities hide between repositories?

Even small and mid-sized engineering teams rarely keep their entire product in a single monolith. A typical B2B platform might have a TypeScript web frontend, a Go or Rust API gateway, a Python worker service handling background jobs or data processing, and shared infrastructure or authentication libraries in separate Git repositories.

Within any single repository, engineers usually understand the local conventions. The most dangerous vulnerabilities happen at the seam between repositories, where two services make opposite assumptions about who is responsible for a security check:

• The API gateway forwards an internal header (X-Org-ID or X-User-Role) assuming the downstream service only accepts requests from verified routes, while a second ingress route forwards client-supplied headers untouched.
• The billing or licensing service issues a signed payload assuming the account service verified the user’s email address first, while a retry endpoint in the account service triggers the call before verification completes.
• A frontend or CLI client enforces role restrictions in the UI, while the backend service exposes the underlying mutation endpoint to any authenticated session.

When every security tool in your pipeline only ever sees one Git repository (or one language) at a time, these seam vulnerabilities remain invisible until an external penetration test or a production incident.

Four vulnerability classes that span multiple repositories and languages

1. Confused deputy and header-trust mismatches

One service acts as a proxy or orchestrator for another. If the upstream proxy fails to strip user-supplied identity headers, or if the downstream service trusts internal RPC calls without binding the caller’s session authority to the target tenant, an attacker can pivot across tenant boundaries.

2. Asymmetric validation across polyglot services

A frontend written in TypeScript, an API written in Go and a worker written in Python may parse URLs, JSON keys, path segments or archive filenames slightly differently. Path normalisation or character encoding that looks harmless in the validator service can resolve to a traversal or injection payload in the downstream consumer.

3. Webhook, queue and asynchronous state replay

When Service A enqueues a background job or emits a webhook to Service B, time passes between the initial request and execution. If Service B executes the job without re-checking whether the user’s session, membership or licence was revoked in the meantime, revoked actors can retain access.

4. Shared secret and token contract drift

When token formats, HMAC signatures or encryption envelopes are produced in one repository and verified in another, subtle drift (such as accepting an empty key ID, skipping audience validation or ignoring expiry timestamps during clock-skew handling) creates exploitable authentication gaps.

Why traditional scanners struggle with polyglot architectures

Rule-based static analysis engines compile or parse an abstract syntax tree for one language at a time. A Go analyser understands Go packages; a Python analyser understands Python modules. Neither understands that a specific fetch("/api/internal/export") call in a TypeScript repository maps to a route in a Go service that enqueues a task for a Python worker.

Even when a vendor offers scanners for multiple languages, each scanner runs inside its own repository’s CI job. When the scanner inspects the downstream Python worker, it cannot see how the upstream Go gateway authenticated the request. It either floods the team with false positives on every internal endpoint or ignores internal endpoints altogether.

How Dokima reviews multi-repository workspaces

Dokima is designed around a workspace directory rather than a single-language compiler plugin:

1. Automatic Git discovery: When you point dokima at a workspace directory containing multiple related repositories (for example, frontend/, api-service/, billing-worker/), Dokima discovers each Git repository, tracks its branch and commit state, and keeps them coordinated.
2. Cross-component decomposition: The Repository Attack-Surface Mapper and Component Decomposer map external entrypoints alongside internal service-to-service boundaries.
3. Cross-service assumption verification: When the Security Assumption Author records that an internal worker relies on the gateway to verify organisation ownership, the Assumption Verifier and Information Gatherer can inspect the gateway repository in the same workspace to verify whether that check actually happens on every route.
4. Incremental workspace sweeps: When commits land in one repository, Dokima syncs the workspace and evaluates how those changes affect both the modified component and its adjacent trust boundaries.

How to set up a multi-repo security review workspace

Setting up a unified review takes only a few minutes:

mkdir -p ~/security-workspace && cd ~/security-workspace
git clone git@example.com:org/web-app.git
git clone git@example.com:org/core-api.git
git clone git@example.com:org/worker-service.git

dokima

If you prefer not to grant the AI runner user account direct Git credentials, you can have a cron job pull the latest commits from your repositories and sync a clean copy into a restricted Unix user directory where Dokima runs. (See our guide on runner permissions and isolation.)

Read the Getting started guide to configure your first workspace, inspect our sample report, or start a 21-day free trial on Linux or macOS.