bug(misconf): Handle resources where pattern evaluation can return an unknown value

[simar7]

Discussed in #8789

^{Originally posted by simar7 April 29, 2025}

Description

In the following example since we don't know the value of the nested resource under evaluation, we are unable to evaluate the parent.

resource "aws_iam_role_policy" "ecs_firehose_delivery_role_policy" {
  name = "${local.iam_policy_name}"
  role = "${aws_iam_role.ecs_firehose_delivery_role.id}"
  
  policy = <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:GetLogEvents",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:put*",
                "s3:get*",
                "s3:list*"
            ],
            "Resource": "*"
        },
         {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStream",
                "kinesis:GetRecords"
            ],
            "Resource": [
                "${aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn}"
            ]
        }
    ]
}
EOF
}

Desired Behavior

Unclear of what the desired behaviour should be but maybe we could partially evaluate the resources that are known to us and ignore the unknown values out of it?

Actual Behavior

The entire parent block is ignored and not evaluated.

Reproduction Steps

1. trivy config main.tf
2. cat main.tf

resource "aws_iam_role_policy" "ecs_firehose_delivery_role_policy" {
  name = "${local.iam_policy_name}"
  role = "${aws_iam_role.ecs_firehose_delivery_role.id}"
  
  policy = <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:GetLogEvents",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:put*",
                "s3:get*",
                "s3:list*"
            ],
            "Resource": "*"
        },
         {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStream",
                "kinesis:GetRecords"
            ],
            "Resource": [
                "${aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn}"
            ]
        }
    ]
}
EOF
}

### Target

None

### Scanner

None

### Output Format

None

### Mode

None

### Debug Output

```bash
n/a

Operating System

all

Version

v0.61.1

Checklist

• Run trivy clean --all
• Read the troubleshooting

[nikpivkin]

I consider this to be a non-trivial task. If a template expression contains an unknown value, evaluating a TemplateExpr will also result in an unknown value.

Let's consider a simple example where var.test is unknown:

{
  "foo": "${var.test}"
}

This raises a key question: what should the value of foo be after processing? Should it default to an empty string, or should we substitute a special marker to indicate that this attribute is invalid or incomplete?

One possible approach is to wrap TemplateExpr by modifying the AST. This allows us to take full control over the evaluation process — regardless of how complex the expression may be.

Here's an implementation sketch:

func (a *Attribute) RewriteExpr(fn func(hclsyntax.Expression) hclsyntax.Expression) {
	a.hclAttribute.Expr = RewriteExpr(a.hclAttribute.Expr.(hclsyntax.Expression), fn)
}

We then walk the expression tree:

func RewriteExpr(expr hclsyntax.Expression, fn func(hclsyntax.Expression) hclsyntax.Expression) hclsyntax.Expression {
	if expr == nil {
		return nil
	}
	expr = fn(expr)
	switch e := expr.(type) {
	case *hclsyntax.BinaryOpExpr:
		e.LHS = RewriteExpr(e.LHS, fn)
		e.RHS = RewriteExpr(e.RHS, fn)
	case *hclsyntax.UnaryOpExpr:
		e.Val = RewriteExpr(e.Val, fn)
	case *hclsyntax.ConditionalExpr:
		e.Condition = RewriteExpr(e.Condition, fn)
		e.TrueResult = RewriteExpr(e.TrueResult, fn)
		e.FalseResult = RewriteExpr(e.FalseResult, fn)
	...
}

We define a wrapper around TemplateExpr:

const UnknownValuePrefix = "__UNRESOLVED__"

type wrappedTemplateExpr struct {
	*hclsyntax.TemplateExpr
}

func (e *wrappedTemplateExpr) Value(ctx *hcl.EvalContext) (cty.Value, hcl.Diagnostics) {
	parts := make([]hclsyntax.Expression, len(e.Parts))
	for i, part := range e.Parts {
		partVal, diags := part.Value(ctx)
		if diags.HasErrors() || !partVal.IsKnown() {
			parts[i] = &hclsyntax.LiteralValueExpr{
				Val:      cty.StringVal(UnknownValuePrefix),
				SrcRange: part.Range(),
			}
		} else {
			parts[i] = part
		}
	}
	newTemplate := &hclsyntax.TemplateExpr{
		Parts:    parts,
		SrcRange: e.SrcRange,
	}

	return newTemplate.Value(ctx)
}

When processing a TemplateExpr, it makes sense to replace unknown parts with a new AST node of type hclsyntax.LiteralValueExpr containing the value cty.StringVal("__UNRESOLVED__"). This aligns with the expectation that a template expression always produces a string, and inserting such a node maintains the AST structure without breaking it. By explicitly marking unresolved fragments as string literals, this approach simplifies later serialization and detection of incomplete values, while preserving the correctness and type consistency of the HCL.

Usage looks like this:

attr.RewriteExpr(func(e hclsyntax.Expression) hclsyntax.Expression {
	switch tn := e.(type) {
	case *hclsyntax.TemplateExpr:
		return &wrappedTemplateExpr{tn}
	default:
		return e
	}
})
res := attr.Value().AsString()

Given a template like the one above, this approach produces:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:GetLogEvents",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:put*",
                "s3:get*",
                "s3:list*"
            ],
            "Resource": "*"
        },
         {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStream",
                "kinesis:GetRecords"
            ],
            "Resource": [
                "__UNRESOLVED__"
            ]
        }
    ]
}

Next in Rego we can check if the value is resolvable:

deny contains res if {
  ...
  value := json.unmarshal(policy.document.value)
  statement.resource != "__UNRESOLVED__"
}

[simar7]

In my original example, if we don't have the value for ${aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn}" we also won't be able to evaluate the statement below:

 {
            "Effect": "Allow",
            "Action": [
                "kinesis:DescribeStream",
                "kinesis:GetRecords"
            ],
            "Resource": [
                "${aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn}"
            ]
        }

But regardless, we should still be able to evaluate the first two statements.

        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:GetLogEvents",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:put*",
                "s3:get*",
                "s3:list*"
            ],
            "Resource": "*"
        },

This raises a key question: what should the value of foo be after processing? Should it default to an empty string, or should we substitute a special marker to indicate that this attribute is invalid or incomplete?

This is the key of the problem as today an empty string could be intentional (actual misconfiguration) vs lack of being able to evaluate.

[nikpivkin]

if we don't have the value for "${aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn}" we also won't be able to evaluate the statement below:

Partially true, if we do not know aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn, then we cannot evaluate the "${aws_kinesis_stream.stepfunction_ecs_kinesis_stream.arn}" part of the pattern, resulting in an inability to evaluate the entire pattern.

we should still be able to evaluate the first two statements.

Each statement is not a separate expression, so we cannot consider them separately, but only the whole pattern.

This is the key of the problem as today an empty string could be intentional (actual misconfiguration) vs lack of being able to evaluate.

So I suggested inserting a special token ‘__UNRESOLVED__’ if the value is unknown.