Cartography: Mapping Cloud Infrastructure into a Queryable Neo4j Graph

What Cartography Solves and Who It Is For

Cartography addresses a specific pain: security and compliance teams that need to answer relationship-based questions across multiple cloud providers and SaaS platforms. Instead of logging into each console and manually correlating IAM policies, network configurations, and resource exposures, Cartography pulls all that data into a single Neo4j graph. The README lists questions it answers, such as which identities have access to which datastores across tenants or providers, whether you are affected by critical vulnerabilities, and what network paths exist in and out of your environment. This is aimed at security engineers, cloud architects, and incident responders who deal with multi-account, multi-provider environments and need a unified view. The tool is not for simple asset inventory; its power lies in traversing relationships, like finding an IAM role that can assume another role to reach an S3 bucket.

How the Graph Is Built: Sync Modules and Neo4j

Cartography works by running sync modules that fetch data from each supported platform and write it into a Neo4j graph database. The README shows that you select modules with the --selected-modules flag, for example 'aws'. Each module is responsible for a specific platform, and the data is modeled as nodes and relationships. For AWS, the module pulls resources like EC2, IAM, RDS, S3, and Lambda, and stores properties such as storage_encrypted on an RDS instance. The graph schema is designed to support traversal queries, so you can start from an AWSAccount node, follow a RESOURCE relationship to an RDS instance, and filter by attributes. The documentation mentions a data schema and a querying tutorial, which likely define the node labels and relationship types. The key mechanism is that Cartography does not just store flat inventory; it preserves the relationships between assets, which is what enables the security questions. The tool also includes a rules engine, accessible via cartography-rules, that can run predefined security checks against the graph, such as object_storage_public.

Getting Started: Commands and Configuration

The quick start is straightforward. Install with pip install cartography, or use cartography[neo4j-rust] to swap in Neo4j's Rust Bolt codec, which the README claims cuts sync time by roughly 20-30%. You need a Neo4j database; the README provides a Docker command to run Neo4j 5 community with no auth: docker run -d --publish=7474:7474 --publish=7687:7687 -v data:/data --env=NEO4J_AUTH=none neo4j:5-community. Then you run cartography --neo4j-uri bolt://localhost:7687 --selected-modules aws, assuming your AWS credentials are configured via environment variables or ~/.aws/config. After the sync, you query the graph using Cypher in the Neo4j browser at http://localhost:7474. For security rules, you run cartography-rules list, then cartography-rules run object_storage_public. For authenticated Neo4j, you set NEO4J_PASSWORD or use other secure options in the rules docs. This is a simple CLI workflow, but note that you need to manage the Neo4j instance yourself, which is a significant operational dependency.

Limitations and Failure Modes

The most obvious limitation is the reliance on Neo4j. You must run and maintain a separate database, which adds complexity and resource overhead. The README does not mention any built-in scheduling or incremental sync; you likely need to set up cron jobs or CI pipelines to run Cartography periodically, and the documentation probably covers that. Another limitation is that the tool is only as good as the credentials you provide. If your AWS profile has limited permissions, the sync will miss resources, leading to incomplete graphs and false negatives in security queries. The README does not specify credential requirements per module, so you must test each platform. Also, the graph can become stale quickly in dynamic environments; without frequent syncs, the data may not reflect current state. Finally, the rules engine is limited to the rules that ship with the tool; you can list and run them, but the README does not mention custom rule authoring, which may be a constraint for teams with specific compliance needs.

Alternatives: Steampipe and CloudSploit

A direct alternative is Steampipe, which also collects cloud infrastructure data, but instead of a graph database, it uses PostgreSQL and exposes each provider's API as SQL tables. The key difference is the query model: Steampipe uses SQL joins, while Cartography uses Cypher graph traversals. For relationship-heavy questions like 'which IAM role can access which S3 bucket', Cypher is often more natural, but for teams already familiar with SQL, Steampipe has a lower learning curve. Another alternative is CloudSploit, which focuses on security scanning and compliance, but it does not provide a graph model; it returns a list of findings rather than a queryable relationship graph. So the choice depends on whether you need to explore arbitrary relationships or just run predefined checks. Cartography's strength is the ability to write ad-hoc Cypher queries, which is more flexible than a fixed set of scans.

Maintenance and Upgrade Cost

Cartography is under active development, with recent releases including 0.140.0, 0.139.1, and 0.139.0, and the last push was August 2026. This means you should expect regular updates, which is good for bug fixes but requires a maintenance commitment. The README does not mention a migration path for the Neo4j schema between versions, so upgrading Cartography might require re-syncing or schema changes. The use of the Rust Bolt codec is an optional dependency, which adds a compilation step if you install from source, but pip should handle it. The license is Apache-2.0, which is permissive and allows commercial use, but you are responsible for any third-party dependencies. The project is part of the CNCF, which suggests governance and community support, but that does not guarantee stability. You should budget time for testing each new release against your environment, especially if you rely on custom Cypher queries that might break if node labels change.

Security Rules and Real-World Use

The rules engine is a practical feature. After a sync, you can run cartography-rules list to see available rules, then run a specific one like object_storage_public. This allows you to codify common security checks, such as finding publicly accessible S3 buckets or unencrypted RDS instances. The README gives an example query for unencrypted RDS instances, which is a typical compliance requirement. The rules likely execute Cypher queries against the graph and return findings. However, the README does not provide a list of all rules, so you need to explore the documentation. The value is that you can automate these checks and integrate them into your CI/CD pipeline. But the rules are only as current as the sync data, so you must run syncs before running rules. This is a reasonable workflow, but it adds complexity to your automation.

Editorial conclusion

Adopt Cartography if you need to answer cross-account or cross-provider security questions, such as 'which identities can access which datastores' or 'which EC2 instances are exposed to the internet', and you are comfortable running and maintaining a Neo4j instance. Avoid it if you want a lightweight, single-provider inventory tool or lack the operational capacity to manage a graph database. Before adopting, verify that your required platforms are in the supported list, confirm the sync time with the Rust Bolt codec is acceptable, and review the security rules for your environment. Cartography is a mature, actively maintained project, but its value depends on the quality of your credentials and the frequency of your syncs.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes