Skip to content

fix(query): fixs for a lot of cli query warnings when scanning 'assets' folder #8012

Draft
cx-andre-pereira wants to merge 2 commits intoCheckmarx:masterfrom
cx-andre-pereira:Fixs_for_scan_failures_and_warnings
Draft

fix(query): fixs for a lot of cli query warnings when scanning 'assets' folder #8012
cx-andre-pereira wants to merge 2 commits intoCheckmarx:masterfrom
cx-andre-pereira:Fixs_for_scan_failures_and_warnings

Conversation

@cx-andre-pereira
Copy link
Copy Markdown
Contributor

@cx-andre-pereira cx-andre-pereira commented Mar 24, 2026

Reason for Proposed Changes

  • Currently running a scan on the "assets" folder along the lines of:
go run <path_to_kics_folder>\cmd\console\main.go scan -p '<path_to_kics_folder>\assets' -v --experimental-queries 
  • Will raise a large ammount of warnings, almost all related to "searchKey" values that are not functional :
 WRN Failed to detect line associated with identified result in file positive5.yaml
  • The engine will, in all these cases, just use the "searchLine" value to determine the line the query should flag, but both "search" values should be valid regardless of this.

Proposed Changes

  • Major rework to the ansible/azure/azure_instance_using_basic_authentication query, the current implementation does not seem to align with the metadata's description

    • Case handling support for the plethora of scenarios possible in a given sample is lacking, the supported cases are for when "ssh_password_enabled" and "linux_config.disable_password_authentication" are both set to a value that is not false (presumably true) or both missing since that would be != false. The fact of the matter is, the query wants to ensure the "azure_rm_virtualmachine" uses "SSH Key instead of basic authentication", and yet we are checking that "disable_password_authentication" is false rather than checking if it is true.
    • Updated the query to support multiple tasks defined through a "tasks" field that is stored as an array in the final payload, additionally the following scenarios were considered and included (test case added for each):
      • Both "ssh_password_enabled" and "linux_config" undefined
      • "ssh_password_enabled" undefined with "linux_config" missing "disable_password_authentication" field
      • "ssh_password_enabled" undefined with "linux_config.disable_password_authentication" set to false
      • "ssh_password_enabled" set to true, "linux_config" undefined
      • "ssh_password_enabled" set to true with "linux_config" missing "disable_password_authentication" field
      • "ssh_password_enabled" set to true with "linux_config.disable_password_authentication" set to false
  • For most other queries were only the "searchKey" value suffered changes a common issue was the use of square brackets to select fields inside a given object from the payload, turns out something like "resources[%s].properties" and similar references often does not work, i suspect this is due to the use of the dot right after the brackets, regardless changing these to exclusively use dot notation fixed the issues: ("resources.%s.properties").

  • With these changes a little over half the warnings are gone, the ones still in place are almost all terraform queries where the warning will not show itself when scanning the test samples associated with each query only. This is likely due to issues searching the target resource in the (large) resulting payload from the full assets scan. (a scan on assets/queries/terrafom will have a similar effect)

  • TODO : research more details on remaining warnings and whether they can also be fixed relatively easily

  • TODO : details on changes to crossplane/aws/rds_db_instance_publicly_accessible

I submit this contribution under the Apache-2.0 license.

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.

1 participant