fix(query): resolve false positive on Hardcoded AWS Access Key In Lambda

[cx-prathmesh-borle]

Closes #7074

Reason for Proposed Changes

• The KICS query 2564172f-c92b-4261-9acd-464aed511696 (Hardcoded AWS Access Key In Lambda) produces false positives on CloudFormation templates because the Rego logic uses overly broad regex patterns that match ANY 20-character uppercase alphanumeric string ([A-Z0-9]{20}) or ANY 40-character base64-like string ([A-Za-z0-9/+=]{40}), regardless of the variable name;
• This caused Lambda environment variables like foo: "12345678901234567890" or DATA_HASH: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" to be flagged as HIGH severity findings even though the variable names are not sensitive;
• The Terraform variant of this query already uses the correct AWS-specific prefix pattern (A3T[A-Z0-9]|AKIA|ASIA)[A-Z0-9]{16} which reliably detects AWS access key IDs by their distinctive prefixes (AKIA for permanent keys, ASIA for temporary STS keys);
• AWS secret access keys lack a distinctive prefix, so they require both pattern matching (40-character base64-like string) AND variable name validation to avoid false positives;

Proposed Changes

• Replaced the single generic rule with two targeted rules in query.rego:
  • Rule 1 - AWS Access Key ID detection: Uses regex (A3T[A-Z0-9]|AKIA|ASIA)[A-Z0-9]{16} to detect AWS access key IDs by their distinctive prefix (no variable name check needed);
  • Rule 2 - AWS Secret Key detection: Uses regex ^[A-Za-z0-9/+=]{40}$ (anchored to match exactly 40 characters) gated behind a case-insensitive variable name pattern (?i)(access.?key|secret.?key|aws.?(key|secret|token|credential)|credential|secret.?access) to only flag 40-character values when the variable name suggests it contains credentials;
• Kept searchKey in the original format Resources.<name>.Properties.Environment.Variables (without specific variable names) to maintain backward compatibility with existing scan results and suppression rules;
• Added searchLine for accurate line number resolution showing the exact variable that triggered the finding;
• Added common_lib import to support the build_search_line function;
• Added 2 new negative test files to validate the fix:
  • negative3.yaml - YAML format with non-sensitive variable names (foo, DATA_HASH) that should NOT be flagged;
  • negative4.json - JSON format with the same non-sensitive patterns;
• Updated 4 existing positive test files (positive1-4) to use realistic AWS credential variable names and values;
• Updated positive_expected_result.json with correct line numbers for each test case;

Note

• The searchKey format is preserved unchanged to ensure existing scan results remain valid and users do not need to update suppression lists;
• Existing true positives (AKIA-prefixed access key IDs) remain detected; some findings with non-sensitive variable names will no longer trigger (by design);
• Cross-platform check: Terraform variant already uses correct pattern; Ansible variant checks specifically-named aws_access_key field (lower FP risk, no change needed);

I submit this contribution under the Apache-2.0 license.