nit: may be good to check if the cfn-guard is installed before this execution. Given the tool can be executed locally it might be good to throw an error if it is not installed.

Solution is to add something like

execSync('cfn-guard --version', { stdio: 'ignore' });

and then log it. Dont know if that would make much of a difference for local run.
In the Github action, its installed and built as 2 steps prior to running this tool

When we want to run locally, does yarn install will automatically install the cfn-guard or we should manually install similar to these steps in the Github action. If we need to install manually, would be good to update the readme for the cfn-guard installation in the local developement section.

I think it would be good to define as an interface for IAMStatement and use it here instead of using as any type.

Eg:

interface IAMStatement {
  Effect: ...;
  Principal?: {
    AWS?: ...;
    Service?: ...;
  };
  Action?: ...;
  Resource?: ...;
}

Problem is it will limit the pattern match to statements. Currently its for statements, we want to catch/ highlight if this pattern is used anywhere else (ie future proof). Let me know if you feel strongly about it.

I understand we are using the workingDir to store all the changed templates and run the cfnguard and intrinsic checks on this directory. However, I have a concern about file traceability. Currently, when files are copied to the working directory (./changed_templates), the mapping to their original paths is lost. This might make it difficult for developers to trace back the issues found by cfn-guard and intrinsic checks to the actual source files. For example, in a PR with multiple changed template files, developers might struggle to identify which specific template in their repository needs fixing.

I'm thinking a file mapping mechanism to maintain the relationship between original file paths and their copies in the working directory might help so the validation result can show the path of the original file path in the output.

Also another approach could be avoiding copying the changed templates to a separate directory and instead process the scan directly from the original file where we could able to track. However, this might not be feasible as cfn-guard's --data option may have limitations with processing multiple template files. I'm not sure about this.

Let me know your thoughts.

/ are replaced by _. Full path is given in the filename. Makes it an easier read except for large PRs. Currently I am deleting the changed templates. which maybe something we need to look at from local run perspective. let me think.

Discussed offline. This needs more deep dive and will work on a separate PR. Not a blocker for this PR.