Corridor-id finds architectural choke points from graph position alone

A new open-source tool analyzes Docker Compose files to identify services that disproportionately expand attacker reach, using network topology instead of asset value labels to find security-critical nodes.

The Answer Up Front

For teams building with Docker Compose, corridor-id is a zero-configuration way to get an automated first pass on architectural security. It identifies services that act as critical bridges to deeper parts of your system. You should use it for a quick check before a manual security review. Skip it if your environment is not described by Docker Compose or if you already have extensive service mesh observability tools that provide similar reachability analysis. The bottom line: it's a clever, lightweight tool that uses graph theory to find choke points you might have missed.

Methodology

This v0 review covers corridor-id, a Python script for analyzing Docker Compose environments, as described by its author, Victor Areyzaga, in a technical blog post published on June 23, 2026. The analysis is based entirely on the author's published claims and the output provided for four distinct test cases: the author's own corridor-lab, a segmented version of Weaveworks' Sock Shop, OWASP crAPI, and the Docker Example Voting App. The source code and Docker environments are publicly available, making the results verifiable.

This review does not cover performance on extremely large or complex Docker Compose files, edge cases involving esoteric network configurations, or a direct comparison against commercial security scanners. Our assessment is based on the logic and results presented in the source article. Independent benchmarks are pending.

What it does

corridor-id is a command-line tool that analyzes a docker-compose.yml file to identify architectural weaknesses. It requires no configuration beyond the path to the file. The tool parses service definitions, network memberships, and port mappings to build a reachability graph of the environment. It then identifies "corridor nodes," which are services that provide access to deeper, otherwise unreachable parts of the system.

The analysis is based on two key metrics:

1. Exposure distance: How many hops a service is from a publicly exposed surface.
2. Forward reach gain: How many new, deeper nodes become accessible through a given service.

A service with a low exposure distance and high forward reach gain is a prime candidate for a corridor node. It represents a choke point where a single compromise can significantly expand an attacker's access.

The four test cases

The author ran the tool against four different environments to demonstrate its utility. In corridor-lab and a segmented version of Sock Shop, the tool correctly identified services like status-api and front-end as corridor nodes, matching the expected outcome of a manual analysis. These services acted as bridges between network segments.

When it finds nothing

More revealing were the tests where corridor-id found zero corridor nodes. On OWASP's crAPI, which uses a single default network, every service could reach every other service. There was no depth, so there could be no corridor nodes. Similarly, the Docker Voting App, despite having two networks, was functionally flat. The tool's empty output was not a failure but a correct diagnosis of a flat, unsegmented architecture where every node is equally exposed to every other node.

What's interesting / what's not

The most interesting aspect of corridor-id is its diagnostic power when it finds nothing. A "Corridor nodes found: 0" result on a system believed to be segmented is a direct, unambiguous signal of an architectural flaw. The tool's value isn't just in finding corridor nodes, but in confirming their absence in flat networks. It forces a conversation about network segmentation and least privilege by providing a concrete, machine-generated finding.

The methodology itself is the core innovation. It sidesteps the need for manually labeling assets as "sensitive" or "high-value." Traditional security tools often rely on these human inputs, which can be subjective and outdated. corridor-id operates purely on topology. A service is critical not because of what it contains, but because of where it is and what it connects to. This is a more robust and automatable approach to identifying systemic risk.

What's not interesting, or rather, what's a clear limitation, is its scope. The tool is explicitly for Docker Compose. It does not analyze Kubernetes manifests, Terraform configurations, or cloud provider network rules. It is a sharp, specific tool for one part of the development lifecycle, not a comprehensive cloud security posture management (CSPM) solution.

Pricing

Free (as of June 2026). The tool is presented as a standalone Python script in a technical blog post, implying an open-source or source-available model.

Verdict

corridor-id is a valuable diagnostic tool for any team using Docker Compose to define their local or testing environments. Its strength is its simplicity. By focusing only on graph position, it provides an objective, automated analysis of architectural choke points without requiring any manual configuration or asset labeling. For founders and engineering leads, running this tool can provide a quick, cheap, and surprisingly insightful check on whether their intended network segmentation is actually being realized. It's less a daily-use scanner and more of a periodic architectural health check.

What we'd test next

A v2 review would need to move beyond the author's curated examples. First, we would run corridor-id against a large, private, and complex production-like Docker Compose file with dozens of services and intricate networking. Second, we would test its sensitivity to various Compose features, like depends_on, links, and different network driver configurations, to identify potential blind spots. Finally, we would present its findings to a seasoned security architect alongside a manual review of the same environment to gauge the signal-to-noise ratio and determine what categories of risk this graph-based approach might miss.

The investor read

This tool is a feature, not a company. It signals a trend towards automated, zero-config, architecture-aware security analysis that can be embedded early in the dev lifecycle ('shift left'). The core insight, using graph topology over manual asset-value labels, is potent. An investable company would need to generalize this concept beyond Docker Compose to Kubernetes, Terraform, and cloud provider APIs, integrating it into CI/CD pipelines and providing actionable remediation advice. As a standalone open-source project, it's a strong lead magnet or a potential acquisition target for a larger DevSecOps platform looking to add topology-aware analysis to its feature set. The market wants security tools that reduce, not increase, developer friction.

Pull quote: “The tool's value isn't just in finding corridor nodes, but in confirming their absence in flat networks.”