Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checkov (>3.2.341) check crashes with TypeError: 'int' object is not subscriptable #6930

Closed
AX2J-Bixal opened this issue Jan 2, 2025 · 10 comments
Labels

Comments

@AX2J-Bixal
Copy link

Describe the issue
We are facing an issue with Checkov scans executed through a GitHub Action (not using the third-party action). The following error occurs: TypeError: 'int' object is not subscriptable. The scan targets all our Terraform directories in our repository (denoted in the example below as matrix.directory), with some directories completing successfully while others fail with the failure illustrated below.

Examples

 - name: Run Checkov Scanning
        run: |
          directory=${{ matrix.directory }}
          echo -e "\033[0;31m:::Checkov Scanning::: $directory directory...\033[0m"
          export LOG_LEVEL=DEBUG
          checkov --directory $directory --output cli --framework terraform --quiet --compact --download-external-modules true

Expected Outcome: This should only fail if the scan detects a security or compliance issue. Detailing where the issue is from the scan results.

Exception Trace

2025-01-02 19:17:03,651 [MainThread  ] [DEBUG]  Created definitions context
Error: -02 19:17:03,651 [MainThread  ] [ERROR]  Exception traceback:
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/site-packages/checkov/main.py", line 522, in run
    self.scan_reports = runner_registry.run(
  File "/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/site-packages/checkov/common/runners/runner_registry.py", line 126, in run
    self.runners[0].run(root_folder, external_checks_dir=external_checks_dir, files=files,
  File "/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/site-packages/checkov/terraform/runner.py", line 134, in run
    self.check_tf_definition(report, root_folder, runner_filter, collect_skip_comments)
  File "/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/site-packages/checkov/terraform/runner.py", line 228, in check_tf_definition
    self.push_skipped_checks_down_from_modules(self.context)
  File "/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/site-packages/checkov/terraform/runner.py", line 254, in push_skipped_checks_down_from_modules
    self.push_skipped_checks_down(definition_context, skipped_checks, resolved_paths)
  File "/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/site-packages/checkov/terraform/runner.py", line 293, in push_skipped_checks_down
    resource_config["skipped_checks"] += skipped_checks
TypeError: 'int' object is not subscriptable
Error: Process completed with exit code 2.

Desktop (please complete the following information):

  • OS: [Linux-6.5.0-1025-azure-x86_64-with-glibc2.34]
  • Checkov Version [3.2.346]

Additional context
We have pinned the version to 3.2.341, as it is the latest version verified to avoid this error. It appears that a change introduced in subsequent versions is causing this issue.

@jmcvetta
Copy link

jmcvetta commented Jan 3, 2025

Confirmed, this bug appears to have been introduced in 3.2.342.

$ for v in 3.2.34{1..2}; do echo $v; asdf install checkov $v > /dev/null; asdf shell checkov $v; checkov --framework=terraform -d organizations/dev/ >/dev/null 2>&1 && echo success || echo failure; done
3.2.341
success
3.2.342
failure

@jmcvetta
Copy link

jmcvetta commented Jan 4, 2025

Workaround

As a temporary workaround, one can pin the Checkov action in GHA to the last version of Checkov before this bug was introduced:

      - name: Checkov static analysis
        id: checkov
        # FIXME: Remove pinned version when https://github.com/bridgecrewio/checkov/issues/6930 is resolved
        uses: bridgecrewio/checkov-action@63fbdab56e22a18bbc16fdc5208c0d30a71f3a24
        #        uses: bridgecrewio/checkov-action@master

@tsmithv11
Copy link
Collaborator

@AX2J-Bixal @jmcvetta can you share a file or files that reproduces the error? I'm not able to reproduce it.

@AX2J-Bixal
Copy link
Author

AX2J-Bixal commented Jan 6, 2025

@jmcvetta TY for the feedback we are also implementing version pinning as a workaround.

@tsmithv11 The traceback actually doesn’t indicate the exact configuration that is causing the error. However in my investigation I noticed that running checkov against the files individually did not produce the error, only when the -d flag was used with the root directory path (or current the path — i.e using -d . or -d {path}) did the error produce.

I used the following script in my testing to check the files individually:

echo "Testing checkov version: 3.2.347"
pip install --quiet checkov==3.2.347

echo "Running checkov scan on individual files in the current directory..."
for file in $(find . -type f -name "*.tf"); do
  echo "Scanning $file..."
  checkov --framework=terraform --quiet -f "$file"
  if [ $? -eq 0 ]; then # eval bad error code
    echo "No issues found in $file"
  else
    echo "Issues found in $file"
  fi

done

@tsmithv11
Copy link
Collaborator

@AX2J-Bixal if you can share more about reproducing the issue, I'd appreciate it.

In the meantime, we're going to roll back the commit that appears to have caused this. However, we would love to bring it back (error free, of course), so anything to help us reproduce it would be very helpful.

@AX2J-Bixal
Copy link
Author

Thank you for rolling back the commit—we appreciate the quick action @tsmithv11 . We'll investigate further on our end to pinpoint the issue and identify steps to reproduce it. We’ll share any findings as soon as we have them to ensure the fix can be reintroduced smoothly and error-free. Your collaboration on this is greatly appreciated!

@AX2J-Bixal
Copy link
Author

AX2J-Bixal commented Jan 7, 2025

Not sure if it helps, but looking more closely at the error message, it suggests a type issue in checkov/terraform/runners.py, specifically within the push_skipped_checks_down function. The logic assumes that all resource_config values are dictionaries, but some are integers or other non-subscriptable types (I assume?), leading to the TypeError.

Anecdotally, I managed to get this working by modifying the function. However, I’m not entirely confident about its effectiveness in the broader context, as I’m not an expert on this stack (definitely some tunnel vision coding here). I thought I’d share the updated function in case it’s helpful to the collaborators, given how awesome this tool is, I'd like to give back in anyway possible 👍 .

possible fix?
def push_skipped_checks_down(
        self,
        definition_context: dict[TFDefinitionKey, dict[str, Any]],
        skipped_checks: list[_SkippedCheck],
        resolved_paths: list[TFDefinitionKey],
    ) -> None:
        if not skipped_checks or not resolved_paths:
            return

        for ind, definition in enumerate(resolved_paths):
            for block_type, block_configs in definition_context.get(
                    definition, {}).items():
                # Skip if block type is not a Terraform resource
                if block_type not in CHECK_BLOCK_TYPES:
                    continue

                if block_type == "module":
                    if not self.definitions:
                        # No need to proceed if definitions are not available
                        continue

                    # Modules don't have a type, just a name
                    for module_name, module_config in block_configs.items():
                        if not isinstance(module_config, dict):
                            print(
                                f"Skipping invalid module_config: {module_config}")
                            continue
                        module_config.setdefault(
                            "skipped_checks", []).extend(skipped_checks)

                        module_context = next(
                            (
                                m
                                for m in self.definitions.get(resolved_paths[ind], {}).get(block_type, [])
                                if module_name in m
                            ),
                            None,
                        )
                        if module_context:
                            recursive_resolved_paths = module_context.get(
                                module_name, {}).get(RESOLVED_MODULE_ENTRY_NAME, [])
                            self.push_skipped_checks_down(
                                definition_context, skipped_checks, recursive_resolved_paths)
                else:
                    # Handle resource types like aws_bucket, etc.
                    for resource_configs in block_configs.values():
                        if not isinstance(resource_configs, dict):
                            print(
                                f"Skipping invalid resource_configs: {resource_configs}")
                            continue
                        for resource_config in resource_configs.values():
                            if not isinstance(resource_config, dict):
                                print(
                                    f"Skipping invalid resource_config: {resource_config}")
                                continue
                            resource_config.setdefault(
                                "skipped_checks", []).extend(skipped_checks)

@andyjones
Copy link

I think the crash happens when there is a skip on a module that contains a terraform block.

I can reproduce it with the following:

main.tf:

terraform {}

module "tf-module" {
  #checkov:skip=CKV2_AWS_30:We have performance insights instead of query logging enabled
  source = "./tf-module"
}

tf-module/versions.tf:

terraform {}

and then running checkov -d . --framework terraform. Starts crashing in checkov 3.2.342 and no longer crashes in checkov 3.2.348. I'm installing checkov via pip and on a mac just in case that helps.

@AX2J-Bixal
Copy link
Author

@andyjones I can confirm I'm observing the same behavior with that test case on my end.

@tsmithv11
Copy link
Collaborator

Thank you, @andyjones! For now, we've removed the offending commit. With this to debug, we'll look to add it back in the future, so I really appreciate it. I'll close this Issue, but if you run into a related error, feel free to reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants