fix(filesystem): skip cache files by extension

[cx-laura-rodrigues]

Proposed Changes

• Skip files matching the .cache. extension/pattern during the filesystem walk, before they reach the parser.
• Added unit test coverage confirming .cache. files are excluded and no longer processed.

Jira: AST-170544

I submit this contribution under the Apache-2.0 license.

[stepsecurity-app]

✅ Resolved — a later workflow run passed this policy check.

Original alert (resolved)

Security Policy Alert: Secret Policy Violation

This workflow run has been blocked by StepSecurity's secrets policy because it accesses secrets and the workflow file differs from the default branch.

Secret references detected:

• secrets.KICS_BOT_PAT at line 98
• secrets.GITHUB_TOKEN at line 99

To approve this workflow, please add the workflows-approved label to this PR.

Note: The label must be added by someone other than the PR author (cx-laura-rodrigues) or automation bots to ensure proper security review.

After the label is added, you can re-run the blocked workflow to proceed.

This workflow will be automatically approved once merged into the default branch.

For more information, see StepSecurity's Secret Exfiltration Policy documentation.

[stepsecurity-app]

Security Policy Alert: Secret Policy Violation

This workflow run has been blocked by StepSecurity's secrets policy because it accesses secrets and the workflow file differs from the default branch.

Secret references detected:

• secrets.KICS_BOT_PAT at line 26

To approve this workflow, please add the workflows-approved label to this PR.

Note: The label must be added by someone other than the PR author (cx-laura-rodrigues) or automation bots to ensure proper security review.

After the label is added, you can re-run the blocked workflow to proceed.

This workflow will be automatically approved once merged into the default branch.

For more information, see StepSecurity's Secret Exfiltration Policy documentation.

[cx-artur-ribeiro]

Hi @cx-laura-rodrigues,
First of all, thanks for the contribution!

I believe the problem here is not catching .cache files, although I understand a similar solution was applied for terraform cache files on line 31 of pkg/engine/provider/filesystem.go.
The problem seems to be the misinterpretation of the files in question as belonging to the docker compose platform, when in fact they shouldn't be correlated to that platform.

KICS does not have an extension per se for docker compose files, so it goes through checkContent, which is used for json and yaml files that could belong to multiple platforms. Those files are then compared against multiple regexes to understand which platform the file content belongs to.

In this case, after scanning a file with the same content as your test files, I found that the problem is that the regex used for docker compose is too loose, causing it to match the content of a file that is not actually a docker compose file.
Below you can see the current regex compared to a file with similar content:

Additionally, if we had a different file name but the same content, we would still hit the same symptom your pull request addresses, since the file wouldn't be excluded by name.
For that reason, I would suggest making the regex more robust in analyzer.

For example, something along these lines:

dockerComposeServicesRegex                      = regexp.MustCompile(`(?m)^\s*"?services"?\s*:[\w\W]+^\s*"?(image|build)"?\s*:`)

After testing and adding a new test file for this specific case, which I can also provide for testing purposes, I got no regressions on the files we already have enough observability into to know that KICS supports and scans correctly. We don't lose any results we already have and we fortify our content analysis by applying a better regex for comparison.

[
  {
    "offer": "sample-webservices",
    "publisher": "checkmarx",
    "sku": "sku1",
    "urn": "checkmarx:sample-webservices:sku1:1.0.0",
    "version": "1.0.0"
  },
  {
    "offer": "sample-image",
    "publisher": "checkmarx",
    "sku": "sku2",
    "urn": "checkmarx:sample-image:sku2:1.0.0",
    "version": "1.0.0"
  }
]

Let me know what you think!
Thanks again for helping us improve kics! 🥳

[github-actions]

⚠️ Potential secret(s) detected (unverified)

@cx-laura-rodrigues — TruffleHog found 1 potential secret(s) in this PR (0 verified, 1 unverified).

Secret Type	Status	Commit	File Path	View
Box	⚠️ unverified	d610057226	.github/scripts/report/e2e-report	🔎 View secret

🛠 Guidelines to remediate hardcoded secrets

• Understand the implications of revoking this secret by investigating where it is used in your code.
• Immediately rotate/revoke the exposed secret. (https://howtorotate.com/docs/introduction/getting-started/)
• Remove it from git history ( a new "remove secret" commit is NOT enough e.g. with git-filter-repo).

To avoid such incidents in the future consider:

• Following the best practices for managing and storing secrets, including API keys and other credentials.
• Re-scan after cleanup before merging.

⚠️ These are unverified matches and do not block the merge — please review and confirm they are not real secrets.

[cx-artur-ribeiro]

LGTM