Attack Paths Queries

This guide explains how to write and maintain Prowler Attack Paths queries: the read-only openCypher queries that traverse the Cartography-ingested cloud graph to detect privilege escalation chains, network exposure, and other graph-shaped security risks.

New to Attack Paths? Start with the user documentation:

Attack Paths - What Attack Paths detects, how to run built-in queries, and how to explore the resulting graph.
Writing Custom openCypher Queries - Run ad-hoc read-only queries from the Prowler App.

Introduction

Attack Paths queries run against a property graph populated by Cartography, an open-source graph ingestion framework, and enriched with Prowler findings. Every query is read-only openCypher (Version 9) so it runs on both the Neo4j and Amazon Neptune sinks. Two categories of query exist, each with a different isolation model:

	Predefined queries	Custom queries
Where they live	`api/src/backend/api/attack_paths/queries/{provider}.py`	User-supplied through the custom query API endpoint
Provider isolation	`AWSAccount {id: $provider_uid}` anchor plus path connectivity	Automatic `_Provider_{uuid}` label injection by `cypher_sanitizer.py`
What to write	Chain every `MATCH` from the `aws` variable	Plain Cypher, no isolation boilerplate
Internal labels	Never use	Never use (system-injected)

For predefined queries, every node must be reachable from the AWSAccount root through graph traversal. That reachability is the isolation boundary. For custom queries, the runner injects a _Provider_{uuid} label into every node pattern, and a post-query filter handles edge cases, so query authors write natural Cypher without isolation boilerplate. The rest of this guide focuses on predefined queries, though the graph model, list-property handling, and compatibility rules apply to both.

The Graph Model

Cartography Schema

Node labels, relationship types, and properties follow the upstream Cartography schema for each provider. Do not guess them, fetch the schema for the pinned Cartography version:

grep cartography api/pyproject.toml

Then read the schema for that exact tag:

# Git pin (prowler-cloud/cartography@<TAG>):
https://raw.githubusercontent.com/prowler-cloud/cartography/refs/tags/<TAG>/docs/root/modules/{provider}/schema.md

# PyPI pin (cartography==<TAG>):
https://raw.githubusercontent.com/cartography-cncf/cartography/refs/tags/<TAG>/docs/root/modules/{provider}/schema.md

The public schema reference for AWS is available at Cartography AWS Schema.

Prowler-Specific Additions

The Prowler sync task enriches the Cartography graph with the following labels and relationships. These are not part of the upstream schema:

Label / Relationship	Description
`ProwlerFinding`	Finding node (`status`, `severity`, `check_id`)
`Internet`	Internet sentinel node used to model public exposure
`CAN_ACCESS`	`(Internet)-[:CAN_ACCESS]->(resource)` exposure edge
`HAS_FINDING`	`(resource)-[:HAS_FINDING]->(:ProwlerFinding)` finding link
`TRUSTS_AWS_PRINCIPAL`	Role trust relationship
`STS_ASSUMEROLE_ALLOW`	Principal can assume a role

Internal Isolation Labels

The sync layer also adds internal labels used only for tenant and provider isolation: _ProviderResource, _AWSResource, _Tenant_*, and _Provider_*. These must never appear in query text, predefined or custom. The runner applies isolation automatically.

Query Structure

Provider Scoping Parameter

Parameter	Property	Used on	Purpose
`$provider_uid`	`id`	`AWSAccount`	Scopes the query to a specific account

The runner binds $provider_uid automatically. Every other node is isolated by path connectivity from the AWSAccount anchor.

Imports

from api.attack_paths.queries.types import (
    AttackPathsQueryAttribution,
    AttackPathsQueryDefinition,
    AttackPathsQueryParameterDefinition,
)
from tasks.jobs.attack_paths.config import PROWLER_FINDING_LABEL

Always reference PROWLER_FINDING_LABEL through f-string interpolation, never hardcode "ProwlerFinding".

Definition Fields

id: kebab-case {provider}-{category}-{description}, e.g. aws-ec2-privesc-passrole-iam.
name: short, human-friendly label. Sourced queries append the reference ID: "EC2 Instance Launch with Privileged Role (EC2-001)".
short_description: one sentence, no technical permissions.
description: full technical explanation, plain text.
provider: aws, azure, gcp, kubernetes, or github.
cypher: f-string Cypher body. Literal { and } are escaped as {{ and }}.
parameters: parameters=[] when the query takes no input.
attribution: optional AttackPathsQueryAttribution(text, link) for sourced queries. The link uses the lowercase ID.

Append the constant to the {PROVIDER}_QUERIES list at the bottom of the provider file.

The Predefined Query Template

The canonical shape combines a principal walk, an optional target walk, deduplicated nodes, and a typed finding overlay:

AWS_QUERY_NAME = AttackPathsQueryDefinition(
    id="aws-kebab-case-name",
    name="Label (REFERENCE_ID)",
    short_description="One sentence.",
    description="Full technical explanation.",
    attribution=AttackPathsQueryAttribution(
        text="pathfinding.cloud - REFERENCE_ID - permission",
        link="https://pathfinding.cloud/paths/reference_id_lowercase",
    ),
    provider="aws",
    cypher=f"""
        // Find principals with the source permission
        MATCH path_principal = (aws:AWSAccount {{id: $provider_uid}})--(principal:AWSPrincipal)-[:POLICY]->(policy:AWSPolicy)-[:STATEMENT]->(stmt:AWSPolicyStatement {{effect: 'Allow'}})
        MATCH (stmt)-[:HAS_ACTION]->(act:AWSPolicyStatementActionItem)
        WHERE toLower(act.value) IN ['permission_lowercase', 'service:*']
           OR act.value = '*'
        WITH DISTINCT aws, principal, stmt, path_principal

        // Pre-aggregate the statement's resource values (see "Avoiding Cartesian Products")
        MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
        WITH aws, path_principal, collect(DISTINCT res.value) AS res_values
        WITH aws, path_principal, res_values, ('*' IN res_values) AS res_wildcard

        // Match each target once against the in-memory resource list
        MATCH path_target = (aws)--(target_role:AWSRole)
        WITH path_principal, path_target, res_values, res_wildcard,
             target_role.name AS rname, target_role.arn AS rarn
        WHERE res_wildcard
           OR size([rv IN res_values WHERE rv CONTAINS rname OR rarn CONTAINS rv]) > 0

        WITH DISTINCT path_principal, path_target
        WITH collect(path_principal) + collect(path_target) AS paths
        UNWIND paths AS p
        UNWIND nodes(p) AS n

        WITH paths, collect(DISTINCT n) AS unique_nodes
        UNWIND unique_nodes AS n
        OPTIONAL MATCH (n)-[pfr:HAS_FINDING]-(pf:{PROWLER_FINDING_LABEL} {{status: 'FAIL'}})

        RETURN paths, collect(DISTINCT pf) as dpf, collect(DISTINCT pfr) as dpfr
    """,
    parameters=[],
)

Key points:

The principal walk types the POLICY and STATEMENT hops. Both are low-fan-out (each principal has a handful of policies; each policy a handful of statements), so the typed edge lets the planner cost a cheap inline filter.
The (aws)-- hub hops stay anonymous. AWSAccount is a high-degree node that fans out to every principal, role, policy, and resource in the account; typing those edges forces the planner to enumerate from the hub and collapses performance on multi-tenant Neptune.
Other relationship types appear only where the file’s existing queries already use one (TRUSTS_AWS_PRINCIPAL, STS_ASSUMEROLE_ALLOW, MEMBER_AWS_GROUP, HAS_EXECUTION_ROLE).
The finding probe is typed :HAS_FINDING and left undirected. The type lets Neptune apply an inline edge filter; the missing direction matches the convention of the rest of the file.
Collapse duplicate rows after each permission gate with WITH DISTINCT, carrying only the variables needed by later clauses.
The RETURN shape paths, dpf, dpfr is the contract the serializer and visualizer depend on. Do not change it.

Avoiding Cartesian Products

The most common performance defect in Attack Paths queries is a Cartesian product between a target set and a policy statement’s resource items. When the two are written as independent MATCH clauses, the planner pairs every target with every resource item before any filter runs. On accounts with many IAM principals, that multiplies into hundreds of thousands of rows and the query errors or times out.

The Pattern That Causes It

// One row per (target_role x resource_item): a Cartesian product
MATCH path_target = (aws)--(target_role:AWSRole)
MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
WHERE res.value = '*'
   OR res.value CONTAINS target_role.name
   OR target_role.arn CONTAINS res.value

The two MATCH clauses share no relationship, so the engine enumerates all targets multiplied by all resource items, applies a non-indexable CONTAINS to each pair, then expands the finding overlay for every surviving row. Cost grows with targets × resources, and a second constrained statement (stmt2) multiplies it again.

The Pattern That Avoids It

Collect the statement’s resource values into a list once, then match each target a single time against that in-memory list:

// Pre-aggregate the statement's resource values into a list
MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
WITH aws, path_principal, collect(DISTINCT res.value) AS res_values
WITH aws, path_principal, res_values, ('*' IN res_values) AS res_wildcard

// Match each target once; bind name/arn to locals so the predicate reads them once
MATCH path_target = (aws)--(target_role:AWSRole)
WITH path_principal, path_target, res_values, res_wildcard,
     target_role.name AS rname, target_role.arn AS rarn
WHERE res_wildcard
   OR size([rv IN res_values WHERE rv CONTAINS rname OR rarn CONTAINS rv]) > 0

Cost now grows with targets + resources (linear) rather than targets × resources. The rewrite is a pure algebraic identity: the result set is unchanged. Guidelines:

Aggregate resources before matching targets, not after. collect(DISTINCT res.value) reduces the resource items to a single list per statement.
Short-circuit the wildcard grant with ('*' IN res_values). When a statement grants *, every target matches, so the list scan is skipped entirely.
Bind target.name and target.arn to local variables in a WITH before the predicate. The list comprehension then reads each once per target instead of re-reading the property store once per resource value.
Use size([... ]) > 0, not any(...). The any(), all(), and none() predicate functions are not part of the openCypher specification and fail on Amazon Neptune. See openCypher Compatibility.
For two-statement queries, aggregate each statement’s resources into its own list (res_values, res2_values) and combine the two size([... ]) > 0 checks with AND.

Every IAM privilege escalation query in aws.py uses this pattern. The lateral-movement variants that constrain the target with a relationship (STS_ASSUMEROLE_ALLOW, TRUSTS_AWS_PRINCIPAL) already limit the target set before the resource filter, which keeps them efficient without further aggregation.

Privilege Escalation Sub-Patterns

Four path_target shapes cover the common escalation types. Each shares the canonical template’s path_principal, the resource pre-aggregation, the deduplication tail, and the RETURN; only the path_target MATCH and its resource predicate differ.

Sub-pattern	Target	`path_target` shape	Example
Self-escalation	Principal’s own policies	`(aws)--(target_policy:AWSPolicy)--(principal)`	IAM-001
Lateral to user	Other IAM users	`(aws)--(target_user:AWSUser)`	IAM-002
Assume-role lateral	Assumable roles	`(aws)--(target_role:AWSRole)-[:STS_ASSUMEROLE_ALLOW]-(principal)`	IAM-014
PassRole plus service	Service-trusting roles	`(aws)--(target_role:AWSRole)-[:TRUSTS_AWS_PRINCIPAL]-(:AWSPrincipal {arn: '{service}.amazonaws.com'})`	EC2-001

Multi-permission queries (for example PassRole plus a service-create action) add permission gates before path_target. Reuse the per-query counter for new variables (act2, policy2, stmt2) and collapse rows after each gate:

MATCH (principal)-[:POLICY]->(policy2:AWSPolicy)-[:STATEMENT]->(stmt2:AWSPolicyStatement {effect: 'Allow'})
MATCH (stmt2)-[:HAS_ACTION]->(act2:AWSPolicyStatementActionItem)
WHERE toLower(act2.value) IN ['service:*', 'service:createsomething']
   OR act2.value = '*'
WITH DISTINCT aws, principal, stmt, stmt2, path_principal

When a permission is an existence-only gate whose statement resource is not checked later, keep the policy and statement anonymous and carry only the variables still needed:

MATCH (principal)-[:POLICY]->(:AWSPolicy)-[:STATEMENT]->(:AWSPolicyStatement {effect: 'Allow'})-[:HAS_ACTION]->(act3:AWSPolicyStatementActionItem)
WHERE toLower(act3.value) IN ['service:*', 'service:othersomething']
   OR act3.value = '*'
WITH DISTINCT aws, principal, stmt, path_principal

Network Exposure Pattern

The Internet node is reached through CAN_ACCESS from an already-scoped resource, never as a standalone lookup:

cypher=f"""
    // Resource scoped through the account anchor
    MATCH path = (aws:AWSAccount {{id: $provider_uid}})--(resource:EC2Instance)
    WHERE resource.exposed_internet = true

    // Internet node reached through path connectivity from the resource
    OPTIONAL MATCH (internet:Internet)-[can_access:CAN_ACCESS]->(resource)

    WITH collect(path) AS paths, head(collect(internet)) AS internet, collect(can_access) AS can_access
    UNWIND paths AS p
    UNWIND nodes(p) AS n

    WITH paths, internet, can_access, collect(DISTINCT n) AS unique_nodes
    UNWIND unique_nodes AS n
    OPTIONAL MATCH (n)-[pfr:HAS_FINDING]-(pf:{PROWLER_FINDING_LABEL} {{status: 'FAIL'}})

    RETURN paths, collect(DISTINCT pf) as dpf, collect(DISTINCT pfr) as dpfr,
        internet, can_access
"""

The CAN_ACCESS edge stays typed and directed (-[:CAN_ACCESS]->); that is its canonical sync-time orientation. Network-exposure queries extend the RETURN contract with internet, can_access.

Working with List-Typed Properties

Some Cartography node properties carry a list of values: AWSPolicyStatement.action, AWSPolicyStatement.resource, AWSPolicyStatement.notaction, AWSPolicyStatement.notresource, KMSKey.encryption_algorithms, CloudFrontDistribution.aliases, the container-definition lists on ECSContainerDefinition, and many others. The graph models each such property as a set of child item nodes connected to the parent by a typed edge. Queries reach the values by traversing the edge; the parent does not carry the list as a single field.

Naming Convention

For a list-typed parent property the sink stores:

Child label: <ParentLabel><PropertyPascal>Item. Example: AWSPolicyStatement.resource becomes AWSPolicyStatementResourceItem.
Edge type: HAS_<PROPERTY_UPPER>. Example: resource becomes HAS_RESOURCE.
Child property: value, a single scalar string per list element. For list-of-dict properties (rare; for example SecretsManagerSecretVersion.tags) the child carries the original dict keys as named fields per the catalog’s field_map.

Variable Naming for Child-Item Matches

aws.py uses a per-query counter for each HAS_* traversal so chained matches stay unambiguous. The counter resets at the top of every query.

Edge	First	Second	Third
`HAS_ACTION`	`act`	`act2`	`act3`
`HAS_RESOURCE`	`res`	`res2`	`res3`
`HAS_NOTACTION`	`nact`	`nact2`	`nact3`
`HAS_NOTRESOURCE`	`nres`	`nres2`	`nres3`

Matching an Action

To find statements that grant iam:PassRole, iam:*, or *, traverse the HAS_ACTION edge in its own MATCH clause and apply the predicate in the attached WHERE:

MATCH (stmt:AWSPolicyStatement {effect: 'Allow'})
MATCH (stmt)-[:HAS_ACTION]->(act:AWSPolicyStatementActionItem)
WHERE toLower(act.value) IN ['iam:passrole', 'iam:*']
   OR act.value = '*'

The literal-action list is case-folded with toLower(act.value) because IAM authors mix case (iam:PassRole, iam:passrole); the * wildcard never lower-cases.

Matching a Resource Against a Target

To find statements whose resource can target a specific node, pre-aggregate the resource values and test the target against the list once (see Avoiding Cartesian Products):

MATCH (stmt)-[:HAS_RESOURCE]->(res:AWSPolicyStatementResourceItem)
WITH aws, path_principal, collect(DISTINCT res.value) AS res_values
WITH aws, path_principal, res_values, ('*' IN res_values) AS res_wildcard

MATCH path_target = (aws)--(target_role:AWSRole)
WITH path_principal, path_target, res_values, res_wildcard,
     target_role.name AS rname, target_role.arn AS rarn
WHERE res_wildcard
   OR size([rv IN res_values WHERE rv CONTAINS rname OR rarn CONTAINS rv]) > 0

Three predicates cover the resource cases: full wildcard (*), a pattern containing the target name (arn:aws:iam::*:role/admin*), and a pattern that is a prefix or component of the actual ARN.

Every-Item and Any-Item Predicates on a Custom Query

Custom queries can express list predicates directly with pattern comprehensions. To check whether every item satisfies a predicate, count the counter-examples and require zero, together with a guard that ensures at least one item is attached:

MATCH (stmt:AWSPolicyStatement)
WHERE size([
    (stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
    WHERE NOT toLower(a.value) STARTS WITH 's3:'
    | a
  ]) = 0
  AND size([(stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem) | a]) > 0
RETURN stmt
LIMIT 25

To return the list of values directly, collect them from the child items:

MATCH (stmt:AWSPolicyStatement {effect: 'Allow'})
OPTIONAL MATCH (stmt)-[:HAS_ACTION]->(a:AWSPolicyStatementActionItem)
RETURN stmt, collect(a.value) AS actions
LIMIT 25

Catalog of List Properties

The provider catalog lives in api/src/backend/tasks/jobs/attack_paths/provider_config.py (AWS_NORMALIZED_LISTS). Beyond policy statements it includes KMS algorithms, ECS container-definition lists (entry_point, command, links, dns_servers, and others), CloudFront aliases, Inspector finding URL and vulnerability lists, and RDS event-subscription categories. To query a list property that is not in the catalog, add an entry there first so the sync layer materializes it. Properties absent from the catalog are serialized to a comma-delimited string and emit a one-time warning during sync.

Working with JSON-Encoded Properties

Some Cartography properties represent nested objects, most notably condition on AWSPolicyStatement and S3PolicyStatement nodes. To keep the schema portable across graph backends, object-typed properties are stored as JSON-encoded strings:

'{"StringEquals":{"aws:SourceAccount":"123456789012"}}'

No JSON parser is available at query time, so use CONTAINS for substring checks against keys or known values:

MATCH (stmt:AWSPolicyStatement)
WHERE stmt.effect = 'Allow'
  AND stmt.condition CONTAINS '"aws:SourceAccount"'
RETURN stmt
LIMIT 25

When a query needs to inspect the structured members of a condition (for example, to evaluate every operator and key), fetch the rows first and parse the JSON in application code. Cypher cannot navigate JSON object keys or values.

openCypher Compatibility

Queries must run on both Neo4j and Amazon Neptune. Neptune implements a subset of Cypher, so several convenient constructs are unavailable. Avoid the following:

Feature	Use instead
APOC procedures (`apoc.*`)	Real nodes and relationships in the graph
Neptune extensions	Standard openCypher
`any(x IN list ...)`	`size([x IN list WHERE pred]) > 0`
`all(x IN list ...)`	`size([x IN list WHERE pred]) = size(list)`
`none(x IN list ...)`	`size([x IN list WHERE pred]) = 0`
`reduce()`	`UNWIND` plus `collect()`
`FOREACH`	`WITH` plus `UNWIND` plus `SET`
Regex `=~`	`toLower()` plus exact match, or `STARTS WITH` / `CONTAINS`
`CALL () { UNION }`	Multi-label `OR` in `WHERE`
Carried value plus aggregate expression	Project the aggregate first (`WITH principal_paths, collect(...) AS target_paths`), then combine lists in the next `WITH`
`EXISTS { MATCH (pattern) WHERE pred }`	Standalone `MATCH (pattern)` plus `WHERE pred`; precede the downstream `collect(path...)` with `WITH DISTINCT <path-vars>` to dedupe the joins

The carried-value-plus-aggregate rule is worth calling out because it is easy to hit. Neo4j 5.x rejects an expression that concatenates a carried list variable with an aggregate in the same projection:

// Rejected: "Aggregation column contains implicit grouping expressions"
WITH principal_paths + collect(DISTINCT path_target) AS paths

Split it into two WITH clauses so the aggregation resolves before the concatenation:

WITH principal_paths, collect(DISTINCT path_target) AS target_paths
WITH principal_paths + target_paths AS paths

For list-typed properties in the catalog (action, resource, and so on), traverse the HAS_* edges to the child item nodes rather than reading a single field; split(...) and comma-string predicates do not apply.

Best Practices

Chain every MATCH from the account anchor. An unanchored MATCH (role:AWSRole) returns roles from every provider in the graph; MATCH (aws)--(role:AWSRole) is scoped. A second-permission MATCH such as MATCH (principal)--(policy2:AWSPolicy)--(stmt2:AWSPolicyStatement) is safe because principal is already bound to the account subgraph.
Pre-aggregate resource lists before matching targets to avoid Cartesian products (see Avoiding Cartesian Products).
Type the finding probe. Always OPTIONAL MATCH (n)-[pfr:HAS_FINDING]-(pf:{PROWLER_FINDING_LABEL} {{status: 'FAIL'}}). The type lets Neptune apply an inline edge filter; an untyped probe scans every incident edge of high-degree nodes.
Comment each MATCH. One inline // ... line per clause explaining its role.
Never use internal labels. _ProviderResource, _AWSResource, _Tenant_*, and _Provider_* are system isolation labels and must not appear in query text.
Reach the Internet node through path connectivity with (internet:Internet)-[:CAN_ACCESS]->(resource), never as a standalone match.
Preserve the RETURN contract. paths, dpf, dpfr for the standard shape; add internet, can_access for network-exposure queries. The serializer and visualizer depend on these names.

Naming Conventions

ID: kebab-case {provider}-{category}-{description}, e.g. aws-ec2-privesc-passrole-iam.
Constant: UPPER_SNAKE_CASE {PROVIDER}_{CATEGORY}_{DESCRIPTION}, e.g. AWS_EC2_PRIVESC_PASSROLE_IAM.

Creating a New Query

New queries come from one of two input sources: a pathfinding.cloud research ID (for example ECS-001, GLUE-001) or a natural-language description from the requester. The aggregated paths.json is too large to fetch whole; query a single path by ID:

# Fetch a single path by ID
curl -s https://raw.githubusercontent.com/DataDog/pathfinding.cloud/main/docs/paths.json \
  | jq '.[] | select(.id == "ecs-002")'

# List all path IDs and names
curl -s https://raw.githubusercontent.com/DataDog/pathfinding.cloud/main/docs/paths.json \
  | jq -r '.[] | "\(.id): \(.name)"'

Then follow these steps:

Read the queries module first to match the existing style:

api/src/backend/api/attack_paths/queries/
├── __init__.py
├── types.py         # dataclass definitions
├── registry.py
└── {provider}.py

Fetch the Cartography schema for the pinned version. Do not guess labels, properties, or relationships. See The Graph Model.
Build the query from the canonical template plus the appropriate sub-pattern (privilege escalation or network exposure). Pre-aggregate resource lists, traverse HAS_* edges for list-typed properties, and keep the RETURN contract.
Register the constant in the {PROVIDER}_QUERIES list at the bottom of the provider file.
Verify compatibility against the openCypher Compatibility rules, and confirm the query parses and runs on Neo4j before it reaches Neptune.

AI assistants connected through Prowler MCP Server can fetch the exact Cartography schema for the active scan with the prowler_get_attack_paths_cartography_schema tool, which guarantees that generated queries match the schema version pinned by the running Prowler release.

Reference

pathfinding.cloud: github.com/DataDog/pathfinding.cloud (use curl | jq; the aggregated paths.json is too large for a single fetch).
Cartography AWS schema: cartography-cncf.github.io/cartography/modules/aws/schema.html.
Neptune openCypher compliance: docs.aws.amazon.com/neptune/latest/userguide/feature-opencypher-compliance.html.
Neptune openCypher rewrites: docs.aws.amazon.com/neptune/latest/userguide/migration-opencypher-rewrites.html.
openCypher specification: github.com/opencypher/openCypher.

Concepts

Providers

Miscellaneous

Introduction

The Graph Model

Cartography Schema

Prowler-Specific Additions

Internal Isolation Labels

Query Structure

Provider Scoping Parameter

Imports

Definition Fields

The Predefined Query Template

Avoiding Cartesian Products

The Pattern That Causes It

The Pattern That Avoids It

Privilege Escalation Sub-Patterns

Network Exposure Pattern

Working with List-Typed Properties

Naming Convention

Variable Naming for Child-Item Matches

Matching an Action

Matching a Resource Against a Target

Every-Item and Any-Item Predicates on a Custom Query

Catalog of List Properties

Working with JSON-Encoded Properties

openCypher Compatibility

Best Practices

Naming Conventions

Creating a New Query

Reference

​Introduction

​The Graph Model

​Cartography Schema

​Prowler-Specific Additions

​Internal Isolation Labels

​Query Structure

​Provider Scoping Parameter

​Imports

​Definition Fields

​The Predefined Query Template

​Avoiding Cartesian Products

​The Pattern That Causes It

​The Pattern That Avoids It

​Privilege Escalation Sub-Patterns

​Network Exposure Pattern

​Working with List-Typed Properties

​Naming Convention

​Variable Naming for Child-Item Matches

​Matching an Action

​Matching a Resource Against a Target

​Every-Item and Any-Item Predicates on a Custom Query

​Catalog of List Properties

​Working with JSON-Encoded Properties

​openCypher Compatibility

​Best Practices

​Naming Conventions

​Creating a New Query

​Reference

Introduction

The Graph Model

Cartography Schema

Prowler-Specific Additions

Internal Isolation Labels

Query Structure

Provider Scoping Parameter

Imports

Definition Fields

The Predefined Query Template

Avoiding Cartesian Products

The Pattern That Causes It

The Pattern That Avoids It

Privilege Escalation Sub-Patterns

Network Exposure Pattern

Working with List-Typed Properties

Naming Convention

Variable Naming for Child-Item Matches

Matching an Action

Matching a Resource Against a Target

Every-Item and Any-Item Predicates on a Custom Query

Catalog of List Properties

Working with JSON-Encoded Properties

openCypher Compatibility

Best Practices

Naming Conventions

Creating a New Query

Reference