> 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/investigate-and-remediate-iac-misconfiguration-issues.md). # Investigate, prioritize, and remediate IaC misconfiguration issues To effectively manage IaC misconfigurations, follow this lifecycle, moving from an open backlog to a resolved and prevented issue. | Stage | Decision | Primary tenant surface | | --------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | **Assess** | How much capacity to commit, and to what | Urgency widget and SLA widget above the IaC Misconfigurations table | | **Prioritize** | Which misconfiguration to work on next | Insights widget above the IaC Misconfigurations table | | **Investigate** | Whether the template is deployed, what the blast radius is, and who owns the fix | Issue side panel | | **Remediate** | Which remediation path to apply | **Resolution** tab in the issue side panel | | **Prevent** | Which enforcement point blocks recurrence | Unified Application Security Policies | > **Important:** The remediation target for an IaC misconfiguration is always the template, never the deployed resource. Correcting the running resource without correcting the template leaves the misconfiguration in the source of truth, and the next apply reintroduces the misconfiguration as drift. *** ### Assess Before selecting an issue, read the shape of the backlog. Two widgets above the IaC Misconfigurations table answer that question, and neither is a work queue — each describes a distribution, so that you commit capacity against a measured posture rather than against the first issue you happen to open. The Urgency widget charts the count of open issues per Urgency level. Read the proportions rather than the absolute counts. | Shape | What the shape means | What to do | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | | A visible Top Urgent segment | Misconfigured templates have provisioned live, internet-exposed resources | Commit capacity to Top Urgent before anything else | | A backlog concentrated in Not Urgent and Not Applicable | Either templates that were never applied, or missing YOR traceability that suppresses the deployment metrics | Verify YOR tag coverage before trusting the shape. See When the backlog itself is unreliable | | A large Urgent middle | Deployed misconfigurations on internal resources | Plan scheduled remediation rather than an incident response | Select a segment to filter the table to that Urgency level. **The SLA widget — how much of the backlog is already late.** The SLA widget charts open issues by SLA status. An overdue population is a commitment already broken, independent of Urgency. Read the SLA widget alongside the Urgency widget: overdue issues at a low Urgency level are a process problem, while overdue issues at Top Urgent are an escalation. > **Note:** The Urgency widget and the SLA widget describe the backlog. The Insights widget builds the work queue and belongs to the next stage. ### Prioritize Prioritize by Urgency, and use Severity as the tie-breaker within an Urgency tier. Severity rates the insecure condition in isolation; Urgency rates the condition in your environment by adding whether the template was applied, how many resources the template provisioned, and whether those resources are internet-exposed. **Use the Insights widget.** Each insight card pairs an Urgency level with a second risk dimension and states how many issues satisfy both conditions. Selecting a card applies both filters to the IaC Misconfigurations table. Start with the cards that combine the highest Urgency level with either a committed remediation deadline or the largest affected asset count. **Filter on Is Fixable to build the throughput queue.** The **Is Fixable** column reports whether Cortex computed an automated fix for the issue. **Is Fixable** is hidden by default — display **Is Fixable** from the **Table Settings** menu, then filter **Is Fixable** to True within an Urgency tier, or sort on **Is Fixable** to group the fixable issues together. > **Important:** **Is Fixable** is set per detection rule and IaC framework. A rule that carries no automated remediation for the framework the template is written in returns **Is Fixable** as False even when the same rule is fixable in another framework. Treat False as "no generated fix for this template," not as "harder to fix." **When no card fits the objective,** sort the issue table by Urgency in descending order, then sort by Severity within each Urgency tier. **Sort by Affected Assets Count to find leverage.** One misconfigured module reused across environments provisions many live resources, and correcting the module resolves every resource at once. Sorting by **Affected Assets Count** in descending order identifies the template corrections with the highest resource-per-fix ratio, which is the IaC-specific throughput strategy. ### Investigate An Urgency level tells you an issue ranks highly. It does not tell you what the misconfiguration exposes, or what the correction will cost. Investigation answers three questions, and each answer changes the action you take. #### Is this misconfiguration live? A misconfiguration in a template that was never applied is a code defect. The same misconfiguration in an applied template is live exposure on running infrastructure. The **Urgency Details** section in the issue side panel supplies the deployment evidence: whether the template **Is Deployed**, the **Affected Assets Count** of live resources the template provisioned, and whether those resources are **Internet Exposed**. | Evidence | Consequence | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Deployed, internet-exposed, high affected asset count | The insecure condition is live and externally reachable across many resources. Treat as an incident and escalate | | Deployed, internet-exposed, single resource | The insecure condition is live and externally reachable. Remediate ahead of the SLA deadline | | Deployed, internal only | The insecure condition is live but reachable only from inside the network boundary. Remediate on the SLA schedule | | Not deployed | The template has not been applied. Confirm the gap is real and not a YOR traceability gap before deprioritizing | #### What is exposed if the misconfiguration is exploited? Blast radius determines the escalation level and how much capacity the issue justifies. The **Urgency Details** section reports the criticality and environment of the owning application, whether the affected resources hold privileged capabilities or access sensitive data, and the effectiveness of any compensating control already in place. The **Code-to-Cloud graph** shows the same exposure as a path — the template, the pipeline that applies the template, and every cloud resource the pipeline provisioned. A reusable module is the IaC-specific multiplier. One insecure default in a shared module propagates into every environment that instantiates the module, which is why two issues with the same detection rule and the same Severity can justify entirely different responses. An existing compensating control at the network or identity layer reduces the exposure but does not remove the insecure definition. Record the control, and keep the issue open against the template correction. #### Who owns the fix, and what does the fix cost? The **code evidence** names the repository, the branch, the template file path, and the commit that introduced the resource block, along with the commit author. That identifies the team to route the work to and the template to change. The relationship between the template and its deployed resources determines the cost. Correcting a template that provisions no live resources is a code change that merges and completes. Correcting a template that provisions live resources requires an apply against running infrastructure, which is change-managed, may interrupt service, and requires a maintenance window. Establish the deployment state during the investigation, because the deployment state — not the misconfiguration — drives the remediation timeline. > **Important:** The **Urgency Details** section is populated for issues from periodic scans. PR scan issues and CI scan issues have no deployment context, because unmerged templates have not been applied. For PR scan and CI scan issues, prioritize by Severity. ### Remediate **Procedure** 1. Navigate to **Application Security > Issues > IaC Misconfigurations**. 2. Select the issue row to open the issue side card. The issue side card displays the current SLA status of the issue. 3. Select the **Resolution** tab. 4. Select a fix card, then apply the fix. | Path | What the path does | Use when | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Automatic Pull Request** | Cortex has already computed the corrected resource block. Selecting **Create Fix PR** opens a pull request against the branch that contains the template, replacing the misconfigured block with the corrected block | The issue reports **Is Fixable** as **True**. This is the fastest path and the default choice | | **Infrastructure as Code** | Presents the corrected template code so that you apply the change yourself in the resource block that triggered the detection rule, then merge the change through your own review process | No automated fix exists for the rule and framework, or the generated fix conflicts with a local convention that your review process enforces | | **Manual Steps** | Presents the ordered remediation steps from the detection rule — the attribute to add or change and the value to set | The correction spans more than a single block, such as a shared module that every consumer instantiates, or the change requires a coordinated version bump | | **CLI** | Presents the commands that apply the change | You are correcting the resource through a command-line workflow rather than through a template edit | | **Cloud Console** | Presents the steps to change the setting in the cloud provider console | Used to stop live exposure while the template correction is in review. This path does not resolve the issue | > **Important:** **Automatic Pull Request** is offered only for issues from periodic scans. A PR scan issue or a CI scan issue presents the manual paths instead, because the branch the fix would target is the branch already under review. > **Caution:** A **Cloud Console** change corrects the running resource, not the template. The misconfiguration remains in the source of truth, and the next apply reintroduces the misconfiguration — as an IaC drift issue if the console change survives, or as the same misconfiguration if the apply overwrites the console change. Treat a **Cloud Console** change as a temporary control and keep the issue open against the template correction. **Sequence the queue by fix availability inside the Urgency tier.** Working the issues that report **Is Fixable** as True first inside a tier converts the tier into merged pull requests fastest. Between two issues that both carry an automated fix, correct the template that provisions live internet-exposed resources first — that correction removes real exposure, while correcting an unapplied template removes only future exposure. Escalate to a Case when the correction requires an apply against production infrastructure and a coordinated maintenance window. **Result:** The remediated issue moves to a resolved state and stops the SLA clock at its resolution timestamp. An **Automatic Pull Request** fix resolves the issue when the pull request merges and the next scan confirms the corrected block, not when the pull request opens. ### Prevent A corrected template that the next commit re-breaks has not been resolved. Close the loop with a Unified Application Security Policy that blocks the misconfiguration pattern at the earliest enforcement point. Select the trigger in shift-left order: a **PR Scan** trigger blocks the misconfiguration before the template merges, and a **CI Scan** trigger blocks the template before the apply stage. Align the policy grace period to the Urgency level — shorter grace periods for issues that reach Top Urgent, longer grace periods for issues that remain Not Urgent. **Match the framework to the scan type.** Selecting the `TERRAFORM` framework applies the detection rule to Terraform Plan scans, and selecting `KUBERNETES` applies the rule to Helm and Kustomize scans. A rule authored against the wrong framework does not evaluate at the enforcement point you intended. **Add a Compliance Standards condition to convert prevention into evidence.** Policies support a Compliance Standards condition filter for the IaC Misconfigurations finding type, which makes the enforcement point auditable against the standard rather than only against the rule. > **Note:** For policy triggers, actions, conditions, and grace period configuration, see Unified Application Security Policies. For authoring custom IaC rules across the supported frameworks, see Application Security rules. ### When the backlog itself is unreliable Incomplete YOR tag coverage suppresses the deployment-dependent Urgency metrics — **Is Deployed**, **Affected Assets Count**, and **Internet Exposed** — which pushes issues toward the Not Urgent and Not Applicable levels. The resulting backlog resembles low risk and is in fact reduced visibility. Without YOR trace tags, the Asset Lineage Graph cannot link a template resource to the cloud resource the template provisioned, so a live misconfiguration on an internet-exposed production resource is indistinguishable from a defect in a template that no one ever applied. Retrieve the Not Urgent issues whose templates report no deployment. For each issue, apply YOR trace tags to the IaC resources and verify CI/CD pipeline integration, then re-triage after the next periodic scan. Treat YOR coverage as a prerequisite to trusting the Urgency distribution across the IaC backlog. > **Note:** For YOR traceability and the Asset Lineage Graph, see Code to Cloud. --- # 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/investigate-and-remediate-iac-misconfiguration-issues.md?ask=&goal= ``` `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.