• Parse a new "arguments" keyword in new IaC v1.4 config #206 : 2 dependent PRs (#217 , #238 ) 👈 (View in Graphite)
• Add the queries-path flag to the scanner binary #205
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

🎯 Code Coverage (details)
• Patch Coverage: 28.57%
• Overall Coverage: 49.62% (-0.05%)

@codex review

@barbiergaspard While reviewing this change, I noticed a potential issue around how override arguments are resolved for aggregate rules. I used AI to help review this, so I may be missing some domain context; please treat this as something to validate rather than a definitive blocker.

Bug: single-override arguments are injected globally across all aggregate branches

The argument-lookup logic has a cross-contamination problem for aggregate rules with multiple overrides.

What happens today

lookupRuleArguments runs once, before Rego evaluation, resolves a single map[string]any, and injects it as input.arguments for the entire query. The relevant path for override-sourced arguments is lookupRuleConfigArgumentsForOverrideIDs:

// inspector.go ~785
if rc, found := lookupRuleConfig(ruleConfigs, *overrideID, ""); found && rc.Arguments != nil {
    if matched != nil {
        return nil, false, fmt.Errorf("multiple override argument configs match aggregated rule %s", queryID)
    }
    matched = rc.Arguments
}

When exactly one override ID has arguments in its rule config, those arguments are returned without error and injected globally. Every branch in the Rego evaluation — AWS, Azure, GCP, etc. — then sees the same input.arguments.

The overrideKey that identifies which branch produced a finding is only read after evaluation in vulnerability_builder.go (line ~160). By that point the cross-contamination has already occurred.

Concrete impact

Given an aggregate rule with overrides aws-sg-id and azure-nsg-id, and a rule config that attaches arguments: {allowed_ports: [443]} to aws-sg-id only:

1. lookupRuleConfigArgumentsForOverrideIDs matches on aws-sg-id → returns {allowed_ports: [443]}
2. That is injected as input.arguments for the whole evaluation
3. The Azure NSG branch also reads input.arguments.allowed_ports, even though no arguments were configured for it
4. Azure/GCP results are evaluated under AWS-specific arguments

The ambiguity guard doesn't help

The error on "multiple override argument configs" (line ~787) actually makes things worse: it prevents the correct fix (per-override arguments) while still silently allowing single-override cross-contamination.

Two clean remedies

Option A — restrict to aggregate-level only: Reject arguments configured under any individual override ID at lookup time and require them to be on the aggregate rule ID. Cross-contamination becomes impossible by construction.

Option B — key arguments by override: Instead of a flat input.arguments, inject input.arguments[overrideKey] so each Rego branch selects only its own arguments. Requires updating the Rego interface contract but is the most expressive fix.

@robertohuertasm-datadog Yes, this bug was a real issue. Looking into it, I have a better understanding of how overrides work, and if my understanding is correct, overrides should not contain arguments. so I removed my last commit, that was related to overrides. Just to be sure we are on the same page, here is my current understanding of the overrides :

• overrides are defined in the default rules repo and are linked to an override key
• the override key is returned in the result of the rego query when relevant
• the override is then processed by the scanner to produce findings

Since the override key depends on the result of the scan, and the result of the scan depends on arguments, we can't have arguments in the override or that would lead to circular dependancies. This is why I removed the override commit.

I also added a commit to fix some e2e tests

@codex review