A KICS scan of your repository passes, yet a Terraform file with a known misconfiguration produced no finding — what in KICS's report and defaults do you check?

## Treat the scan as a pipeline A green KICS job says only that nothing **counted** was found in what KICS **evaluated**. When a file you know is wrong produces no finding, the useful question is at which stage it fell out. KICS moves every file through the same stages — collect, parse, evaluate, resolve values, filter results, set the exit status — and each stage leaves evidence in the JSON report or the log. Rerunning with `-v --log-level DEBUG` and `-o` pointing at a scratch directory gives you both. Work from the first stage to the last: a file that was never collected cannot be fixed by tuning queries, and a finding that is in the report but did not fail the job is a gate problem, not a detection problem. ## Stage 1: was the file collected? Several defaults remove files before KICS even counts them: - **`.gitignore`.** Paths matched by the `.gitignore` at the root of the scanned path are excluded, and the log announces it. Generated directories and environment folders are often listed there. `--exclude-gitignore` turns this off. - **Configuration you did not type.** Flags come from the command line, then from `KICS_`-prefixed environment variables, then from a configuration file, in that order of precedence. A `kics.config` at the root of a single scanned path is loaded automatically, so an `exclude-paths` entry there applies to every run; when `-p` lists several paths it is not loaded unless `--config` names it. - **Size.** `--max-file-size` defaults to 5 MB. A larger file is skipped with a warning, not an error. - **Platform filters.** `-t, --type` or `--exclude-type` may have left Terraform out of the run. ## Stages 2 and 3: was it parsed and evaluated? | Report field | What a bad value means | |---|---| | `files_scanned` vs `files_parsed` | files that reached the parser but failed to parse, so no query saw them; the log names each one | | `queries_total` | fewer queries than a comparable unfiltered run means a `--type`, provider, include or exclude filter narrowed the library | | `queries_failed_to_execute` | queries that did not finish, typically after the per-query `--timeout` of 60 seconds | | `lines_ignored` | lines dropped by `kics-scan` comment directives | Also check the query itself: an `--include-queries` list that omits it, a `-q, --queries-path` that replaced the built-in library, an `--exclude-severities` value matching its severity, or an experimental query that needs `--experimental-queries`. At `DEBUG` level the log names each excluded query. ## Stage 4: could KICS see the value? KICS evaluates the source as written, with limited resolution: 1. **Variables.** Without help, KICS resolves only values from `terraform.tfvars` and `*.auto.tfvars` in the same directory, plus variable defaults. A value that lives in `envs/prod.tfvars` needs `--terraform-vars-path envs/prod.tfvars`, or a first-line comment `// kics_terraform_vars: envs/prod.tfvars` in the `.tf` file. 2. **Functions.** KICS does not evaluate Terraform functions or environment variables; an attribute built by a function stays a wrapped expression that a query may not recognise. 3. **Modules.** KICS understands only a list of official AWS registry modules kept in its `common.json` library and does not follow unofficial or custom modules. A dangerous value passed into a local module call is not joined to the resource inside the module, which is evaluated on its own with whatever default its variable carries. Scanning the Terraform plan JSON instead of the source sidesteps all three, at a cost that is its own decision. ## Stage 5: suppressed, or simply not gating? - A `kics-scan ignore-block` or `ignore-line` near the resource, or an `ignore` at the top of the file, removes its results; `lines_ignored` going up is the clue. - `-x, --exclude-results` drops specific findings by `similarity_id`, often from a list in a config file. - The finding may be **in the report** while the job stays green: `--fail-on` only counts the severities it lists, and `--ignore-on-exit results` or `all` returns 0 regardless. ## A quick triage order 1. Search the JSON report for the file name. If the finding is there, the problem is the gate, not detection. 2. Search the log for the file name: excluded, oversized or failed to parse. 3. Compare `queries_total` with a run using no selection flags. 4. Look for directives in the file and for `-x` entries in the configuration. 5. Check how the offending value reaches the resource: variable file, function or module.