-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
Confirmed, this bug appears to have been introduced in
|
WorkaroundAs 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
|
@AX2J-Bixal @jmcvetta can you share a file or files that reproduces the error? I'm not able to reproduce it. |
@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 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
|
@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. |
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! |
Not sure if it helps, but looking more closely at the error message, it suggests a type issue in 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) |
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 |
@andyjones I can confirm I'm observing the same behavior with that test case on my end. |
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. |
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 asmatrix.directory
), with some directories completing successfully while others fail with the failure illustrated below.Examples
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
Desktop (please complete the following information):
Linux-6.5.0-1025-azure-x86_64-with-glibc2.34
]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.The text was updated successfully, but these errors were encountered: