Skip to content

fix(terraform): resolve module output edges by identity, not path alone#7471

Open
pszypowicz wants to merge 3 commits intobridgecrewio:mainfrom
pszypowicz:fix/module-output-edge-same-source-siblings
Open

fix(terraform): resolve module output edges by identity, not path alone#7471
pszypowicz wants to merge 3 commits intobridgecrewio:mainfrom
pszypowicz:fix/module-output-edge-same-source-siblings

Conversation

@pszypowicz
Copy link
Copy Markdown

Summary

  • Fix _should_add_edge() to match output vertices by full module identity (get_vertex_as_tf_module()) instead of path only, preventing wrong edge connections when two module calls share the same source
  • Add regression test that verifies variable resolution works correctly in this scenario

Details

When two module calls share the same source (e.g., modules "a" and "b" both using ./mod_a), and a third module "c" references one of their outputs, the old path-only check in _should_add_edge() could connect the edge to the wrong module instance. This corrupted variable resolution for module "c", leaving var.* references unresolved and causing false positives (e.g., CKV_AZURE_35).

The fix is a one-line change replacing the loose path comparison with get_vertex_as_tf_module(module_node), which already exists in the codebase and compares the full module identity (name, path, nested modules).

Fixes #7470

Test plan

  • New test test_module_output_edge_with_same_source_siblings passes with the fix
  • Same test fails without the fix ('Deny' != 'var.default_action')
  • All existing graph builder tests pass (49/49)
  • All variable rendering tests pass (205/205)

@pszypowicz
Copy link
Copy Markdown
Author

Why this works:

The bug is in _should_add_edge() at local_graph.py:845. The method decides which output vertex to connect an edge to when resolving module.<name>.<output> references.

The old second condition:

self.get_abspath(vertex.source_module_object.path) == self.get_abspath(module_node.path)

Only compared file paths. When modules "a" and "b" both use source ./mod_a, their output vertices live at the same path — so the first match wins (alphabetically), connecting to the wrong module instance.

The fix:

vertex.source_module_object == get_vertex_as_tf_module(module_node)

get_vertex_as_tf_module() (already used elsewhere in this file, line 416) constructs a TFModule from the vertex, which includes the module name, path, and nested module chain. This distinguishes module "a" from module "b" even when they share the same source.

@pszypowicz pszypowicz force-pushed the fix/module-output-edge-same-source-siblings branch from bcf546a to cb6c46e Compare March 17, 2026 17:49
When two module calls share the same source, _should_add_edge() matched
output vertices by path only, causing edges to connect to the wrong
module instance. This corrupted variable resolution for any third module
referencing one of their outputs.

Replace the loose path comparison with get_vertex_as_tf_module(), which
matches on full module identity (name, path, nested modules).

Fixes bridgecrewio#7470
…lution

Add test_module_output_edge_with_same_source_siblings to verify that
variable resolution works when two modules share the same source and a
third module references one of their outputs.

The test fixture uses a minimal reproduction: a variable-to-output
module (mod_a) instantiated twice, with the alphabetically-first
instance receiving the other's output, and a separate module (mod_c)
whose explicitly-passed variable must resolve correctly.
@pszypowicz pszypowicz force-pushed the fix/module-output-edge-same-source-siblings branch from cb6c46e to 8ad0421 Compare March 18, 2026 07:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Variable resolution fails when two module instances share the same source and a third module references one's output

1 participant