> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/infrastructure-as-code-iac-misconfiguration-scanner/iac-misconfiguration-findings.md).

# IaC misconfiguration findings

To access IaC misconfiguration findings, under **Modules**, select **Application Security** → **Issues** → **IaC Misconfigurations** → **click the Findings tab**.

The Cortex Cloud Application Security **IaC misconfigurations** **Findings** table is a filtered view of the comprehensive **Findings** inventory, located at **Cases & Issues** → **Issues** → **Findings tab**.

This dedicated table exclusively displays findings that were detected during periodic scans. In contrast, the comprehensive **Findings** table unifies IaC misconfiguration findings from all sources, including periodic, pull request (PR), and continuous integration (CI) scans.

The Findings tab enables the following workflows:

* **Audit scanner coverage:** Review the full scope of IaC misconfigurations detected by the scanner to verify that detection rules are identifying the expected misconfiguration patterns across all monitored repositories and IaC frameworks.
* **Identify policy gaps:** Compare findings in the Findings tab against issues in the Issues tab to identify findings that are not covered by existing unified policies. Create new policies to promote high-risk findings to actionable issues.
* **Review excluded findings:** Investigate findings that were excluded by policy filters to confirm that exclusions are intentional and do not suppress critical IaC misconfigurations.
* **Validate detection rules:** Verify that detection rules are producing accurate findings and not generating excessive false positives for specific IaC frameworks or resource types.

{% hint style="info" %}

### Note

Findings in the Findings tab are raw scanner output and do not have resolution statuses, SLA tracking, or assignees. To track remediation for a specific finding, create or update a unified policy that matches the finding pattern to generate an actionable issue in the Issues tab.
{% endhint %}

#### Findings inventory

The **Findings** inventory includes the following exposed properties.

| Property    | Description                                                                                          |
| ----------- | ---------------------------------------------------------------------------------------------------- |
| Name        | The specific name or title of the finding (follows the name of the rule)                             |
| Asset Name  | The name of the asset (such as a repository) where the finding was identified                        |
| Repository  | The version control repository where the problematic code or configuration resides                   |
| Data Source | The system or integration from which the finding data was originally pulled (such as GitHub, GitLab) |
| Branch      | The specific branch within the repository where the finding was detected                             |
| File Path   | The exact path to the file within the repository's structure where the finding is located            |

#### Investigating findings details

Clicking on a finding in the inventory table opens the **Findings** side card which provides additional details about the finding.

* **Finding summary**: Found at the top of the card. Includes the finding name, ID and type (**Configuration** for IaC findings)
* **Description**: A description of the finding including its location
* **Timestamp**: When the finding was last updated
* **Asset details**: Includes **Asset** (The impacted asset. Clicking on the asset opens the asset side card without needing to navigate away to the asset section) and **Asset Type** (The specific asset type in which the IaC resource was identified)
* **Evidence**: Provides evidence and contextual details within your SDLC containing the IaC misconfiguration finding:
  * **Finding source**
    * **Data Source:** The system or integration from which the finding data was originally pulled (such as GitHub or a CI/CD pipeline). Click the icon next to the data source to navigate to the data source itself
    * **Run ID**: The unique identifier of the specific scan execution during which this finding was detected
    * **Collaborator**: The individual or team responsible for contributing to the code or configuration where the finding was identified
  * **Code context**
    * **Repository:** The name of the version control repository where the finding was located
    * **Branch:** The specific branch within the repository containing the finding
    * **File Path:** The exact location of the finding within the repository file structure
    * **First Hash:** The commit hash of the first commit where this specific finding was introduced or detected
    * **First Commit Date**: The date of the commit that introduced the problematic code or dependency into the repository. This helps understand how long an issue has existed and for prioritizing remediation efforts based on its age
  * **Scan metadata**
    * **Run ID:** The unique identifier of the specific scan execution during which this finding was detected


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/infrastructure-as-code-iac-misconfiguration-scanner/iac-misconfiguration-findings.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
